[JBoss JIRA] (WFCORE-763) Persisting an empty list [] gets read as a list with empty string [""] resulting in IllegalArgumentException
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-763?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFCORE-763:
----------------------------------
Fix Version/s: 1.0.0.CR7
2.0.0.Alpha5
> Persisting an empty list [] gets read as a list with empty string [""] resulting in IllegalArgumentException
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-763
> URL: https://issues.jboss.org/browse/WFCORE-763
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.CR6, 2.0.0.Alpha4
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Minor
> Fix For: 1.0.0.CR7, 2.0.0.Alpha5
>
>
> In short, the default AttributeParser/AttributeMarshaller for list attributes do not handle empty lists in a symmetric fashion.
> e.g. if I persist an empty list to xml, and read it back again, using the default parser/marshaller, I should get back an empty list. Instead I get back a list of size 1 containing an empty string.
> Affects at least infinispan aliases and modcluster proxies...
> (20:09:22) rhusar: pferraro: https://gist.github.com/rhusar/5eef22d7a6479f042a5d#file-gistfile1-txt-L23
> (20:09:34) rhusar: pferraro: if i write an empy list, read it back -> empty list
> (20:09:57) rhusar: pferraro: if i use the default writeAttribute, reload, read it back and i have a list of size 1 containing empty String..
> (20:23:23) rhusar: pferraro: alright, this is also "broken" in the infiinispan subsystem aliases
> (20:23:24) rhusar: pferraro: 20:22:55,775 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 40) WFLYCTL0013: Operation ("add") failed - address: ([
> (20:23:24) rhusar: ("subsystem" => "infinispan"),
> (20:23:24) rhusar: ("cache-container" => "hibernate")
> (20:23:24) rhusar: ]): java.lang.IllegalArgumentException: Empty name segment is not allowed for infinispan
> (20:23:24) rhusar: at org.jboss.msc.service.ServiceName.of(ServiceName.java:90)
> (20:23:24) rhusar: at org.jboss.msc.service.ServiceName.append(ServiceName.java:117)
> (20:23:24) rhusar: at org.wildfly.clustering.infinispan.spi.service.CacheContainerServiceName$1.getServiceName(CacheContainerServiceName.java:35)
> (20:23:24) rhusar: at org.jboss.as.clustering.infinispan.subsystem.CacheContainerBuilder.build(CacheContainerBuilder.java:79)
> (20:23:24) rhusar: at org.jboss.as.clustering.infinispan.subsystem.CacheContainerAddHandler.installRuntimeServices(CacheContainerAddHandler.java:165)
> (20:23:24) rhusar: at org.jboss.as.clustering.infinispan.subsystem.CacheContainerAddHandler.performRuntime(CacheContainerAddHandler.java:82)
> (20:23:24) rhusar: at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:309)
> (20:23:24) rhusar: at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:130)
> (20:23:24) rhusar: at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:822)
> (20:23:24) rhusar: at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:620)
> (20:23:24) rhusar: at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:373)
> (20:23:24) rhusar: at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:349)
> (20:23:24) rhusar: at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359)
> (20:23:24) rhusar: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> (20:23:24) rhusar: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> (20:23:24) rhusar: at java.lang.Thread.run(Thread.java:745)
> (20:23:24) rhusar: at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (JGRP-1927) RELAY2: Delays during shutdown
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1927?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1927:
---------------------------
Description:
Say we have 2 clusters connected via RELAY2, AB and CD. A is the site master of AB, C is the site master of CD, and A is the coordinator of the bridge cluster.
When node A is stopped, it first leaves the AB cluster, and then the bridge cluster. When B receives the new B view, it tries to join the bridge cluster. But because RELAY2 hasn't yet finished stopping the relay channel on A, B still sees A as the coordinator of the bridge channel, and sends the JOIN_REQ message to it.
The bridge channel stops on A before receiving B's join response, so B won't receive any response and will eventually time out. If the user tries to stop node B, it will block waiting for the JChannel lock:
{noformat}
"testng@1" prio=5 tid=0x1 nid=NA waiting for monitor entry
java.lang.Thread.State: BLOCKED
waiting for Incoming-1,NodeB@2894 to release lock on <0xd26> (a org.jgroups.JChannel)
at org.jgroups.JChannel.close(JChannel.java:385)
at org.jgroups.util.Util.close(Util.java:408)
at org.jgroups.protocols.relay.Relayer$Bridge.stop(Relayer.java:256)
at org.jgroups.protocols.relay.Relayer.stop(Relayer.java:109)
at org.jgroups.protocols.relay.RELAY2.stop(RELAY2.java:280)
at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
at org.jgroups.JChannel.stopStack(JChannel.java:1003)
at org.jgroups.JChannel.disconnect(JChannel.java:373)
- locked <0xd54> (a org.jgroups.JChannel)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.stop(JGroupsTransport.java:262)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
"Incoming-1,B@2894" prio=5 tid=0x2f nid=NA runnable
java.lang.Thread.State: RUNNABLE
blocks testng@1
at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:114)
at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:44)
at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1084)
at org.jgroups.protocols.FlowControl.down(FlowControl.java:353)
at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
at org.jgroups.protocols.RSVP.down(RSVP.java:153)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038)
at org.jgroups.JChannel.down(JChannel.java:791)
at org.jgroups.JChannel._connect(JChannel.java:564)
at org.jgroups.JChannel.connect(JChannel.java:294)
- locked <0xd26> (a org.jgroups.JChannel)
at org.jgroups.JChannel.connect(JChannel.java:279)
at org.jgroups.protocols.relay.Relayer$Bridge.start(Relayer.java:250)
at org.jgroups.protocols.relay.Relayer.start(Relayer.java:86)
at org.jgroups.protocols.relay.RELAY2.startRelayer(RELAY2.java:681)
at org.jgroups.protocols.relay.RELAY2.handleView(RELAY2.java:663)
at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:416)
at org.jgroups.protocols.RSVP.up(RSVP.java:201)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:394)
at org.jgroups.protocols.tom.TOA.up(TOA.java:121)
at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:732)
- locked <0xd2e> (a org.jgroups.protocols.pbcast.GMS)
at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:146)
{noformat}
Ideally, I'd like B to realize that the coordinator of the bridge cluster has the same site id, and delay sending the join request until C becomes the coordinator. Failing that, maybe {{JChannel.stop}} could interrupt the thread doing the join?
was:
Say we have 2 clusters connected via RELAY2, AB and CD. A is the site master of AB, C is the site master of CD, and A is the coordinator of the bridge cluster.
When node A is stopped, it first leaves the AB cluster, and then the bridge cluster. When B receives the new AB view, it tries to join the bridge cluster. But because RELAY2 hasn't yet finished stopping the relay channel on A, B still sees A as the coordinator of the bridge channel, and sends the JOIN_REQ message to it.
The bridge channel stops on A before receiving B's join response, so B won't receive any response and will eventually time out. If the user tries to stop node B, it will block waiting for the JChannel lock:
{noformat}
"testng@1" prio=5 tid=0x1 nid=NA waiting for monitor entry
java.lang.Thread.State: BLOCKED
waiting for Incoming-1,NodeB@2894 to release lock on <0xd26> (a org.jgroups.JChannel)
at org.jgroups.JChannel.close(JChannel.java:385)
at org.jgroups.util.Util.close(Util.java:408)
at org.jgroups.protocols.relay.Relayer$Bridge.stop(Relayer.java:256)
at org.jgroups.protocols.relay.Relayer.stop(Relayer.java:109)
at org.jgroups.protocols.relay.RELAY2.stop(RELAY2.java:280)
at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
at org.jgroups.JChannel.stopStack(JChannel.java:1003)
at org.jgroups.JChannel.disconnect(JChannel.java:373)
- locked <0xd54> (a org.jgroups.JChannel)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.stop(JGroupsTransport.java:262)
at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
"Incoming-1,B@2894" prio=5 tid=0x2f nid=NA runnable
java.lang.Thread.State: RUNNABLE
blocks testng@1
at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:114)
at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:44)
at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1084)
at org.jgroups.protocols.FlowControl.down(FlowControl.java:353)
at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
at org.jgroups.protocols.RSVP.down(RSVP.java:153)
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038)
at org.jgroups.JChannel.down(JChannel.java:791)
at org.jgroups.JChannel._connect(JChannel.java:564)
at org.jgroups.JChannel.connect(JChannel.java:294)
- locked <0xd26> (a org.jgroups.JChannel)
at org.jgroups.JChannel.connect(JChannel.java:279)
at org.jgroups.protocols.relay.Relayer$Bridge.start(Relayer.java:250)
at org.jgroups.protocols.relay.Relayer.start(Relayer.java:86)
at org.jgroups.protocols.relay.RELAY2.startRelayer(RELAY2.java:681)
at org.jgroups.protocols.relay.RELAY2.handleView(RELAY2.java:663)
at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:416)
at org.jgroups.protocols.RSVP.up(RSVP.java:201)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
at org.jgroups.protocols.FlowControl.up(FlowControl.java:394)
at org.jgroups.protocols.tom.TOA.up(TOA.java:121)
at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:732)
- locked <0xd2e> (a org.jgroups.protocols.pbcast.GMS)
at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:146)
{noformat}
Ideally, I'd like B to realize that the coordinator of the bridge cluster has the same site id, and delay sending the join request until C becomes the coordinator. Failing that, maybe {{JChannel.stop}} could interrupt the thread doing the join?
> RELAY2: Delays during shutdown
> ------------------------------
>
> Key: JGRP-1927
> URL: https://issues.jboss.org/browse/JGRP-1927
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.6.2
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Fix For: 3.6.4
>
>
> Say we have 2 clusters connected via RELAY2, AB and CD. A is the site master of AB, C is the site master of CD, and A is the coordinator of the bridge cluster.
> When node A is stopped, it first leaves the AB cluster, and then the bridge cluster. When B receives the new B view, it tries to join the bridge cluster. But because RELAY2 hasn't yet finished stopping the relay channel on A, B still sees A as the coordinator of the bridge channel, and sends the JOIN_REQ message to it.
> The bridge channel stops on A before receiving B's join response, so B won't receive any response and will eventually time out. If the user tries to stop node B, it will block waiting for the JChannel lock:
> {noformat}
> "testng@1" prio=5 tid=0x1 nid=NA waiting for monitor entry
> java.lang.Thread.State: BLOCKED
> waiting for Incoming-1,NodeB@2894 to release lock on <0xd26> (a org.jgroups.JChannel)
> at org.jgroups.JChannel.close(JChannel.java:385)
> at org.jgroups.util.Util.close(Util.java:408)
> at org.jgroups.protocols.relay.Relayer$Bridge.stop(Relayer.java:256)
> at org.jgroups.protocols.relay.Relayer.stop(Relayer.java:109)
> at org.jgroups.protocols.relay.RELAY2.stop(RELAY2.java:280)
> at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
> at org.jgroups.JChannel.stopStack(JChannel.java:1003)
> at org.jgroups.JChannel.disconnect(JChannel.java:373)
> - locked <0xd54> (a org.jgroups.JChannel)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.stop(JGroupsTransport.java:262)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> "Incoming-1,B@2894" prio=5 tid=0x2f nid=NA runnable
> java.lang.Thread.State: RUNNABLE
> blocks testng@1
> at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:114)
> at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:44)
> at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1084)
> at org.jgroups.protocols.FlowControl.down(FlowControl.java:353)
> at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> at org.jgroups.protocols.RSVP.down(RSVP.java:153)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038)
> at org.jgroups.JChannel.down(JChannel.java:791)
> at org.jgroups.JChannel._connect(JChannel.java:564)
> at org.jgroups.JChannel.connect(JChannel.java:294)
> - locked <0xd26> (a org.jgroups.JChannel)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at org.jgroups.protocols.relay.Relayer$Bridge.start(Relayer.java:250)
> at org.jgroups.protocols.relay.Relayer.start(Relayer.java:86)
> at org.jgroups.protocols.relay.RELAY2.startRelayer(RELAY2.java:681)
> at org.jgroups.protocols.relay.RELAY2.handleView(RELAY2.java:663)
> at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:416)
> at org.jgroups.protocols.RSVP.up(RSVP.java:201)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:394)
> at org.jgroups.protocols.tom.TOA.up(TOA.java:121)
> at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:732)
> - locked <0xd2e> (a org.jgroups.protocols.pbcast.GMS)
> at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:146)
> {noformat}
>
> Ideally, I'd like B to realize that the coordinator of the bridge cluster has the same site id, and delay sending the join request until C becomes the coordinator. Failing that, maybe {{JChannel.stop}} could interrupt the thread doing the join?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (DROOLS-820) During the compilation of a KieModule with dependencies the pom is parsed multiple times
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-820?page=com.atlassian.jira.plugin... ]
Mario Fusco updated DROOLS-820:
-------------------------------
Priority: Critical (was: Major)
> During the compilation of a KieModule with dependencies the pom is parsed multiple times
> ----------------------------------------------------------------------------------------
>
> Key: DROOLS-820
> URL: https://issues.jboss.org/browse/DROOLS-820
> Project: Drools
> Issue Type: Enhancement
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Critical
>
> When a KieModule has dependencies we have a big inefficiency because its pom is parsed multiple times. In particular the parsing happens:
> 1. When the KieBuilder creates the pom model:
> {code}
> java.lang.Thread.State: RUNNABLE
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:39)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:35)
> at org.kie.scanner.MavenPomModelGenerator.parse(MavenPomModelGenerator.java:19)
> at org.drools.compiler.kproject.xml.PomModel$Parser.parse(PomModel.java:64)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildPomModel(KieBuilderImpl.java:407)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.init(KieBuilderImpl.java:116)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:149)
> at org.kie.scanner.AbstractKieCiTest.createKieJarWithDependencies(AbstractKieCiTest.java:47)
> at org.kie.scanner.KieRepositoryScannerTest.testKScannerWithDependencies(KieRepositoryScannerTest.java:104)
> {code}
> 2. In a for-loop once for each of the direct dependencies (this is particularly bad)
> {code}
> java.lang.Thread.State: RUNNABLE
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:39)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:35)
> at org.kie.scanner.ArtifactResolver.getResolverFor(ArtifactResolver.java:112)
> at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:95)
> - locked <0x10b6> (a org.kie.scanner.KieRepositoryScannerImpl)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.loadKieModuleFromMavenRepo(KieRepositoryImpl.java:113)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:99)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.init(KieBuilderImpl.java:130) <-- IN A FOR-LOOP !!!
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:149)
> at org.kie.scanner.AbstractKieCiTest.createKieJarWithDependencies(AbstractKieCiTest.java:47)
> at org.kie.scanner.KieRepositoryScannerTest.testKScannerWithDependencies(KieRepositoryScannerTest.java:104)
> {code}
> 3. When creating the ClassLoader for the KieProject
> {code}
> java.lang.Thread.State: RUNNABLE
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:21)
> at org.kie.scanner.embedder.MavenProjectLoader.loadMavenProject(MavenProjectLoader.java:67)
> - locked <0x647> (a java.lang.Class)
> at org.kie.scanner.Aether.<init>(Aether.java:46)
> at org.kie.scanner.Aether.getAether(Aether.java:56)
> - locked <0x15d8> (a java.lang.Class)
> at org.kie.scanner.MavenRepository.getMavenRepository(MavenRepository.java:73)
> - locked <0x15d7> (a java.lang.Class)
> at org.kie.scanner.ArtifactResolver.getPomFileForGAV(ArtifactResolver.java:118)
> at org.kie.scanner.ArtifactResolver.getResolverFor(ArtifactResolver.java:84)
> at org.kie.scanner.MavenClassLoaderResolver.getClassLoader(MavenClassLoaderResolver.java:55)
> at org.drools.compiler.kie.builder.impl.KieModuleKieProject.<init>(KieModuleKieProject.java:53)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:171)
> at org.kie.scanner.AbstractKieCiTest.createKieJarWithDependencies(AbstractKieCiTest.java:47)
> {code}
> The main reason of this inefficiency is caused by the fact that the product of this pom parsing process are maven/aether classes that cannot be referenced in drools-compiler and then are recreated every time the compiler invokes kie-ci.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (DROOLS-820) During the compilation of a KieModule with dependencies the pom is parsed multiple times
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-820:
----------------------------------
Summary: During the compilation of a KieModule with dependencies the pom is parsed multiple times
Key: DROOLS-820
URL: https://issues.jboss.org/browse/DROOLS-820
Project: Drools
Issue Type: Enhancement
Reporter: Mario Fusco
Assignee: Mario Fusco
When a KieModule has dependencies we have a big inefficiency because its pom is parsed multiple times. In particular the parsing happens:
1. When the KieBuilder creates the pom model:
{code}
java.lang.Thread.State: RUNNABLE
at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:39)
at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:35)
at org.kie.scanner.MavenPomModelGenerator.parse(MavenPomModelGenerator.java:19)
at org.drools.compiler.kproject.xml.PomModel$Parser.parse(PomModel.java:64)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildPomModel(KieBuilderImpl.java:407)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.init(KieBuilderImpl.java:116)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:149)
at org.kie.scanner.AbstractKieCiTest.createKieJarWithDependencies(AbstractKieCiTest.java:47)
at org.kie.scanner.KieRepositoryScannerTest.testKScannerWithDependencies(KieRepositoryScannerTest.java:104)
{code}
2. In a for-loop once for each of the direct dependencies (this is particularly bad)
{code}
java.lang.Thread.State: RUNNABLE
at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:39)
at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:35)
at org.kie.scanner.ArtifactResolver.getResolverFor(ArtifactResolver.java:112)
at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:95)
- locked <0x10b6> (a org.kie.scanner.KieRepositoryScannerImpl)
at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.loadKieModuleFromMavenRepo(KieRepositoryImpl.java:113)
at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:99)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.init(KieBuilderImpl.java:130) <-- IN A FOR-LOOP !!!
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:149)
at org.kie.scanner.AbstractKieCiTest.createKieJarWithDependencies(AbstractKieCiTest.java:47)
at org.kie.scanner.KieRepositoryScannerTest.testKScannerWithDependencies(KieRepositoryScannerTest.java:104)
{code}
3. When creating the ClassLoader for the KieProject
{code}
java.lang.Thread.State: RUNNABLE
at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:21)
at org.kie.scanner.embedder.MavenProjectLoader.loadMavenProject(MavenProjectLoader.java:67)
- locked <0x647> (a java.lang.Class)
at org.kie.scanner.Aether.<init>(Aether.java:46)
at org.kie.scanner.Aether.getAether(Aether.java:56)
- locked <0x15d8> (a java.lang.Class)
at org.kie.scanner.MavenRepository.getMavenRepository(MavenRepository.java:73)
- locked <0x15d7> (a java.lang.Class)
at org.kie.scanner.ArtifactResolver.getPomFileForGAV(ArtifactResolver.java:118)
at org.kie.scanner.ArtifactResolver.getResolverFor(ArtifactResolver.java:84)
at org.kie.scanner.MavenClassLoaderResolver.getClassLoader(MavenClassLoaderResolver.java:55)
at org.drools.compiler.kie.builder.impl.KieModuleKieProject.<init>(KieModuleKieProject.java:53)
at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:171)
at org.kie.scanner.AbstractKieCiTest.createKieJarWithDependencies(AbstractKieCiTest.java:47)
{code}
The main reason of this inefficiency is caused by the fact that the product of this pom parsing process are maven/aether classes that cannot be referenced in drools-compiler and then are recreated every time the compiler invokes kie-ci.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month
[JBoss JIRA] (WFCORE-761) Not possible to overlay non existing file in WAR
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-761?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski updated WFCORE-761:
--------------------------------------
Component/s: Server
> Not possible to overlay non existing file in WAR
> ------------------------------------------------
>
> Key: WFCORE-761
> URL: https://issues.jboss.org/browse/WFCORE-761
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Server
> Reporter: Bartosz Baranowski
> Priority: Minor
>
> It is either bug in how deployments are treated or how overlay/vfs work.
> Steps to reproduce:
> 1. deploy undexploded war with jar inside
> 2. add overlay that will add non existing file in jar
> Result: exception:
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt
> Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}}
> at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67)
> at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37)
> at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76)
> at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67)
> Expectation:
> should work. It actually does work, if war is really exploded or
> 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
11 years, 1 month