[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-12486:
-----------------------------------------
[~ehugonnet] Nice. :) . Please change the description on that PR to include a link to this one so we'll resolve it when we merge.
> Memory leak in OpenTracing when deployment is redeployed multiple times
> -----------------------------------------------------------------------
>
> Key: WFLY-12486
> URL: https://issues.redhat.com/browse/WFLY-12486
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final
> Reporter: Jan Stourac
> Assignee: Emmanuel Hugonnet
> Priority: Blocker
> Attachments: memory-leak-bad.png, memory-leak-good.png
>
>
> There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue.
> Test and deployment is same as is described in WFLY-10991.
> Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations.
> I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious.
> Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via:
> {code}
> /subsystem=microprofile-opentracing-smallrye:remove()
> {code}
> the memory leak is still present. This is kind of confusing to me.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFWIP-218) server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/WFWIP-218?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka commented on WFWIP-218:
----------------------------------------
Ok, after time of investigation I was able to reproduce the issue in standalone (non-kubernetes) setup (it happened to be a little bit complicated - at least for me - to understand what's happening here). The updated testcase is at:
https://gitlab.mw.lab.eng.bos.redhat.com/ochaloup/tests-transactions/comm...
the way to run is e.g.
{code}
export JBOSS_HOME=...
mvn clean verify -am -pl jbossts -DfailIfNoTests=false -Djbossts.noJTS -Dtest=TxPropagationJMSCrashRecoveryTestCase#injectRmfailAtServerCommit
{code}
The issue is caused by the fact that he recovery `commit` call has no information about the file system. The top-down-recovery runs with {{AtomicActionRecoveryModule}} which has no notion about {{XA}} specifics of the {{XAResource}}. The module just takes the serialized version of the resource and run commit on it. When the read of the serialized resource is done there is only information about the remote resource and thus the commit may succeed. The removal of the file of xa-recovery happens only at the second periodic recovery attempt when bottom-up {{XAResourceRecoveryModule}} calls {{recover}} and removes the record.
This is a trouble when the remote server is already away (as it's for the scaledown) and the recover call keeps failing. That way there is no way for the WFTC to remove data on the second round of recovery during the {{XAResource.recover()}} call. The recover call fails forever and the WFTC xa recovery records resides at the place forever as well.
> server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited
> --------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-218
> URL: https://issues.redhat.com/browse/WFWIP-218
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Simka
> Assignee: Ondrej Chaloupka
> Priority: Major
>
> this follows up on WFWIP-206
> While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful
> Scenario:
> *ejb client* (app tx-client, pod tx-client-0):
> * EJB business method
> ** lookup remote EJB
> ** enlist XA resource 1 to transaction
> ** enlist XA resource 2 to transaction
> ** call remote EJB
> *ejb server* (app tx-server, pod tx-server-0):
> * EJB business method
> ** enlist XA resource 1 to transaction
> ** enlist XA resource 2 to transaction
> *testTxStatelessServerSecondCommitThrowRmFail*
> ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}}
> Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client and transactions on client aren't commited.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet commented on WFLY-12486:
------------------------------------------
Seems to be fixed with the integration PR for WFLY-12758
> Memory leak in OpenTracing when deployment is redeployed multiple times
> -----------------------------------------------------------------------
>
> Key: WFLY-12486
> URL: https://issues.redhat.com/browse/WFLY-12486
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final
> Reporter: Jan Stourac
> Assignee: Emmanuel Hugonnet
> Priority: Blocker
> Attachments: memory-leak-bad.png, memory-leak-good.png
>
>
> There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue.
> Test and deployment is same as is described in WFLY-10991.
> Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations.
> I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious.
> Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via:
> {code}
> /subsystem=microprofile-opentracing-smallrye:remove()
> {code}
> the memory leak is still present. This is kind of confusing to me.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-1124) Unble to provision errors when creating KieContainor from KieServices in the Vert.X verticle
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-1124?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-1124.
---------------------------------
Resolution: Explained
See https://docs.jboss.org/drools/release/7.25.0.Final/drools-docs/html_singl...
> Unble to provision errors when creating KieContainor from KieServices in the Vert.X verticle
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-1124
> URL: https://issues.redhat.com/browse/DROOLS-1124
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.4.0.CR2
> Environment: OS: MacOX and 10.10.5
> Vert.X: 3.2.1
> Reporter: xiaodong wang
> Assignee: Mario Fusco
> Priority: Major
> Attachments: Evaluation.zip, MavenTest.zip, MavenTest.zip
>
>
> WARN Sisu - Error injecting: org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> com.google.inject.ProvisionException: Unable to provision, see the following errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> 1 error
> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1018)
> at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1044)
> at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:54)
> at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:113)
> at org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
> at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:122)
> at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
> at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:46)
> at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1066)
> at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1009)
> at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1059)
> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1005)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:263)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:255)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:249)
> at org.kie.scanner.embedder.PlexusComponentProvider.lookup(PlexusComponentProvider.java:42)
> at org.kie.scanner.embedder.MavenEmbedder.buildMavenExecutionRequest(MavenEmbedder.java:119)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:90)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:81)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:75)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:42)
> at org.kie.scanner.embedder.MavenProjectLoader.loadMavenProject(MavenProjectLoader.java:96)
> at org.kie.scanner.Aether.<init>(Aether.java:62)
> at org.kie.scanner.Aether.getAether(Aether.java:74)
> at org.kie.scanner.MavenRepository.getMavenRepository(MavenRepository.java:80)
> at org.kie.scanner.ArtifactResolver.<init>(ArtifactResolver.java:53)
> at org.kie.scanner.KieRepositoryScannerImpl.getArtifactResolver(KieRepositoryScannerImpl.java:102)
> at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:119)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.loadKieModuleFromMavenRepo(KieRepositoryImpl.java:130)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:116)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:93)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:115)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:111)
> at com.cyngn.soothsayer.application.Server.init(Server.java:83)
> at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$163(DeploymentManager.java:427)
> at io.vertx.core.impl.ContextImpl.lambda$wrapTask$18(ContextImpl.java:335)
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
> at java.lang.Thread.run(Thread.java:745)
> 14:22:39.388 [vert.x-eventloop-thread-1] ERROR o.kie.scanner.embedder.MavenEmbedder - Unable to build MavenEmbedder
> org.codehaus.plexus.component.repository.exception.ComponentLookupException: com.google.inject.ProvisionException: Unable to provision, see the following errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via modules: org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via modules: org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.apache.maven.execution.MavenExecutionRequestPopulator
> 1 error
> role: org.apache.maven.execution.MavenExecutionRequestPopulator
> roleHint:
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:267)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:255)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:249)
> at org.kie.scanner.embedder.PlexusComponentProvider.lookup(PlexusComponentProvider.java:42)
> at org.kie.scanner.embedder.MavenEmbedder.buildMavenExecutionRequest(MavenEmbedder.java:119)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:90)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:81)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:75)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:42)
> at org.kie.scanner.embedder.MavenProjectLoader.loadMavenProject(MavenProjectLoader.java:96)
> at org.kie.scanner.Aether.<init>(Aether.java:62)
> at org.kie.scanner.Aether.getAether(Aether.java:74)
> at org.kie.scanner.MavenRepository.getMavenRepository(MavenRepository.java:80)
> at org.kie.scanner.ArtifactResolver.<init>(ArtifactResolver.java:53)
> at org.kie.scanner.KieRepositoryScannerImpl.getArtifactResolver(KieRepositoryScannerImpl.java:102)
> at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:119)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.loadKieModuleFromMavenRepo(KieRepositoryImpl.java:130)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:116)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:93)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:115)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:111)
> at com.cyngn.soothsayer.application.Server.init(Server.java:83)
> at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$163(DeploymentManager.java:427)
> at io.vertx.core.impl.ContextImpl.lambda$wrapTask$18(ContextImpl.java:335)
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (WFCORE-4763) interface "any" tag not working as expected
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFCORE-4763?page=com.atlassian.jira.plug... ]
Brian Stansberry reassigned WFCORE-4763:
----------------------------------------
Assignee: Brian Stansberry
Resolution: Explained
> interface "any" tag not working as expected
> -------------------------------------------
>
> Key: WFCORE-4763
> URL: https://issues.redhat.com/browse/WFCORE-4763
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Environment: Ubuntu 18.02
> Reporter: Yann Le Tallec
> Assignee: Brian Stansberry
> Priority: Major
>
> The {{<any>}} tag in the {{interface}} configuration of {{standalone.xml}} should accept any connection that matches ANY of the provided rules. This is not the case as demonstrated by the example below.
> This configuration allows to run {{jboss-cli.sh -c}} from the machine where wildfly is running as expected:
> {code:xml}
> <interfaces>
> <interface name="management">
> <any>
> <inet-address value="127.0.0.1"/>
> </any>
> </interface>
> </interfaces>
> {code}
> But if I add another (VALID) IP address inside the any tag, I can't connect any more:
> {code:xml}
> <interfaces>
> <interface name="management">
> <any>
> <inet-address value="127.0.0.1"/>
> <inet-address value="10.20.230.26"/>
> </any>
> </interface>
> </interfaces>
> {code}
> With the latter configuration, {{connect}} fails with the following error:
> {noformat}
> >The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: Connection refused
> {noformat}
> Note: to easily reproduce the problem from the cli, starting from a fresh standalone install:
> {code:bash}
> connect
> /interface=management:undefine-attribute(name=inet-address)
> /interface=management:undefine-attribute(name=any)
> /interface=management:write-attribute(name=any,value={inet-address=[127.0.0.1]})
> reload
> /interface=management:write-attribute(name=any,value={inet-address=[127.0.0.1,10.20.230.26]})
> reload
> {code}
> Notes:
> - 10.20.230.26 must be a reachable IP - if I use a random one I can connect normally.
> - if I use {{subnet-match}} I get the same issue
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-1124) Unble to provision errors when creating KieContainor from KieServices in the Vert.X verticle
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-1124?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-1124:
--------------------------------
Sprint: 2019 Week 50-52 (from Dec 9)
> Unble to provision errors when creating KieContainor from KieServices in the Vert.X verticle
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-1124
> URL: https://issues.redhat.com/browse/DROOLS-1124
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.4.0.CR2
> Environment: OS: MacOX and 10.10.5
> Vert.X: 3.2.1
> Reporter: xiaodong wang
> Assignee: Mario Fusco
> Priority: Major
> Attachments: Evaluation.zip, MavenTest.zip, MavenTest.zip
>
>
> WARN Sisu - Error injecting: org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> com.google.inject.ProvisionException: Unable to provision, see the following errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> 1 error
> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1018)
> at com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1044)
> at org.eclipse.sisu.space.AbstractDeferredClass.get(AbstractDeferredClass.java:48)
> at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:86)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:54)
> at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
> at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:113)
> at org.eclipse.sisu.bean.BeanScheduler$Activator.onProvision(BeanScheduler.java:176)
> at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:122)
> at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:68)
> at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:46)
> at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1066)
> at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1009)
> at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1059)
> at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1005)
> at org.eclipse.sisu.inject.LazyBeanEntry.getValue(LazyBeanEntry.java:82)
> at org.eclipse.sisu.plexus.LazyPlexusBean.getValue(LazyPlexusBean.java:51)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:263)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:255)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:249)
> at org.kie.scanner.embedder.PlexusComponentProvider.lookup(PlexusComponentProvider.java:42)
> at org.kie.scanner.embedder.MavenEmbedder.buildMavenExecutionRequest(MavenEmbedder.java:119)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:90)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:81)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:75)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:42)
> at org.kie.scanner.embedder.MavenProjectLoader.loadMavenProject(MavenProjectLoader.java:96)
> at org.kie.scanner.Aether.<init>(Aether.java:62)
> at org.kie.scanner.Aether.getAether(Aether.java:74)
> at org.kie.scanner.MavenRepository.getMavenRepository(MavenRepository.java:80)
> at org.kie.scanner.ArtifactResolver.<init>(ArtifactResolver.java:53)
> at org.kie.scanner.KieRepositoryScannerImpl.getArtifactResolver(KieRepositoryScannerImpl.java:102)
> at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:119)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.loadKieModuleFromMavenRepo(KieRepositoryImpl.java:130)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:116)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:93)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:115)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:111)
> at com.cyngn.soothsayer.application.Server.init(Server.java:83)
> at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$163(DeploymentManager.java:427)
> at io.vertx.core.impl.ContextImpl.lambda$wrapTask$18(ContextImpl.java:335)
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
> at java.lang.Thread.run(Thread.java:745)
> 14:22:39.388 [vert.x-eventloop-thread-1] ERROR o.kie.scanner.embedder.MavenEmbedder - Unable to build MavenEmbedder
> org.codehaus.plexus.component.repository.exception.ComponentLookupException: com.google.inject.ProvisionException: Unable to provision, see the following errors:
> 1) No implementation for org.apache.maven.repository.RepositorySystem was bound.
> while locating org.apache.maven.execution.DefaultMavenExecutionRequestPopulator
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via modules: org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
> at ClassRealm[maven, parent: ClassRealm[maven-parent, parent: null]] (via modules: org.eclipse.sisu.wire.WireModule -> org.eclipse.sisu.plexus.PlexusBindingModule)
> while locating org.apache.maven.execution.MavenExecutionRequestPopulator
> 1 error
> role: org.apache.maven.execution.MavenExecutionRequestPopulator
> roleHint:
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:267)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:255)
> at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:249)
> at org.kie.scanner.embedder.PlexusComponentProvider.lookup(PlexusComponentProvider.java:42)
> at org.kie.scanner.embedder.MavenEmbedder.buildMavenExecutionRequest(MavenEmbedder.java:119)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:90)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:81)
> at org.kie.scanner.embedder.MavenEmbedder.<init>(MavenEmbedder.java:75)
> at org.kie.scanner.embedder.MavenProjectLoader.parseMavenPom(MavenProjectLoader.java:42)
> at org.kie.scanner.embedder.MavenProjectLoader.loadMavenProject(MavenProjectLoader.java:96)
> at org.kie.scanner.Aether.<init>(Aether.java:62)
> at org.kie.scanner.Aether.getAether(Aether.java:74)
> at org.kie.scanner.MavenRepository.getMavenRepository(MavenRepository.java:80)
> at org.kie.scanner.ArtifactResolver.<init>(ArtifactResolver.java:53)
> at org.kie.scanner.KieRepositoryScannerImpl.getArtifactResolver(KieRepositoryScannerImpl.java:102)
> at org.kie.scanner.KieRepositoryScannerImpl.loadArtifact(KieRepositoryScannerImpl.java:119)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.loadKieModuleFromMavenRepo(KieRepositoryImpl.java:130)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:116)
> at org.drools.compiler.kie.builder.impl.KieRepositoryImpl.getKieModule(KieRepositoryImpl.java:93)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:115)
> at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:111)
> at com.cyngn.soothsayer.application.Server.init(Server.java:83)
> at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$163(DeploymentManager.java:427)
> at io.vertx.core.impl.ContextImpl.lambda$wrapTask$18(ContextImpl.java:335)
> at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4070) Improve service discovery/wiring to allow defining the order of alternative services
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4070?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-4070:
--------------------------------
Description: At the moment if you have 2 or more different implementations of a service on the classpath, the service discovery/wiring mechanism randomly chooses one of them (the one that comes first in the classpath). It is required to provide a way to explicitly configure a priority among these services. (was: At the moment if you have 2 different implementations of a service on the classpath, the service discovery/wiring mechanism randomly chooses one of the two (the one that comes first in the classpath). )
> Improve service discovery/wiring to allow defining the order of alternative services
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-4070
> URL: https://issues.redhat.com/browse/DROOLS-4070
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Critical
>
> At the moment if you have 2 or more different implementations of a service on the classpath, the service discovery/wiring mechanism randomly chooses one of them (the one that comes first in the classpath). It is required to provide a way to explicitly configure a priority among these services.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months
[JBoss JIRA] (DROOLS-4070) Improve service discovery/wiring to allow defining the order of alternative services
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4070?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-4070:
--------------------------------
Description: At the moment if you have 2 different implementations of a service on the classpath, the service discovery/wiring mechanism randomly chooses one of the two (the one that comes first in the classpath). (was: At the moment if you have 2 different implementations of a service )
> Improve service discovery/wiring to allow defining the order of alternative services
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-4070
> URL: https://issues.redhat.com/browse/DROOLS-4070
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Critical
>
> At the moment if you have 2 different implementations of a service on the classpath, the service discovery/wiring mechanism randomly chooses one of the two (the one that comes first in the classpath).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 5 months