[JBoss JIRA] (DROOLS-1219) ClassObjectTypes are not all correctly rewired during a packages merge
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1219:
-----------------------------------
Summary: ClassObjectTypes are not all correctly rewired during a packages merge
Key: DROOLS-1219
URL: https://issues.jboss.org/browse/DROOLS-1219
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Mario Fusco
Assignee: Mario Fusco
As demonstrated by the following not all ClassObjectTypes are correctly rewired during a package merge. In that case R2 doesn't fire because the ClassObjectType used by the from pattern is not rewired to the new Class instance created by the second ProjectClassLoader.
{code}
@Test
public void testWiringClassOnPackageMerge() throws Exception {
String drl_init =
"package init;\n" +
"import org.kie.test.TestObject\n" +
"rule RInit when\n" +
"then\n" +
" TestObject obj1 = new TestObject();\n" +
" TestObject obj2 = new TestObject();" +
" obj1.add(obj2);" +
" insert(obj1);\n" +
"end";
String drl1 =
"package p1;\n" +
"import org.kie.test.TestObject\n" +
"global java.util.List list;\n" +
"rule R1 when\n" +
" $obj : TestObject( $objs : objects )\n" +
" $s : Object() from $objs\n" +
"then\n" +
" list.add(\"R1\");\n" +
"end";
String drl2 =
"package p2;\n" +
"import org.kie.test.TestObject\n" +
"global java.util.List list;\n" +
"rule R2 when\n" +
" $obj : TestObject( $objs : objects )\n" +
" $s : TestObject() from $objs\n" +
"then\n" +
" list.add(\"R2\");\n" +
"end";
String javaSrc =
"package org.kie.test;\n" +
"import java.util.*;\n" +
"\n" +
"public class TestObject {\n" +
" private final List<TestObject> objects = new ArrayList<TestObject>();\n" +
"\n" +
" public List<TestObject> getObjects() {\n" +
" return objects;\n" +
" }\n" +
" public void add(TestObject obj) {\n" +
" objects.add(obj);" +
" }" +
"}\n";
String path = "org/kie/test/MyRuleUnit";
KieServices ks = KieServices.Factory.get();
KieFileSystem kfs = ks.newKieFileSystem();
kfs.writeKModuleXML(ks.newKieModuleModel().toXML())
.write("src/main/resources/a.drl", drl_init)
.write("src/main/resources/b.drl", drl1)
.write("src/main/resources/c.drl", drl2)
.write("src/main/java/org/kie/test/TestObject.java", javaSrc);
ks.newKieBuilder( kfs ).buildAll();
KieContainer kcontainer = ks.newKieContainer(ks.getRepository().getDefaultReleaseId());
KieSession kSession = kcontainer.newKieSession();
List<String> list = new ArrayList<String>();
kSession.setGlobal( "list", list );
kSession.fireAllRules();
assertEquals( 2, list.size() );
assertTrue( list.contains( "R1" ) );
assertTrue( list.contains( "R2" ) );
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)
by Fedor Gavrilov (JIRA)
[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ]
Fedor Gavrilov reopened WFLY-6402:
----------------------------------
> EJBs accessible too early (spec violation)
> ------------------------------------------
>
> Key: WFLY-6402
> URL: https://issues.jboss.org/browse/WFLY-6402
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Fedor Gavrilov
> Labels: downstream_dependency
> Attachments: auto-test-reproducer.zip
>
>
> {code}
> EJB 3.1 spec, section 4.8.1:
> "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application.
> {code}
> Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1609) Allow static definition of the product module slot
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1609?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1609:
------------------------------------------
A quick design note on this: instead of passing in the slot and still having ProductConfig read a module to get the necessary data, I could have put in a mechanism to just directly pass in the data. But I wanted to do the minimum quickly here, keep the overall mechanism as much like the standard one as possible and try to avoid bugs, confusion or unintended uses that arise from bigger differences. But the other approach can be considered in the future if it makes sense.
> Allow static definition of the product module slot
> --------------------------------------------------
>
> Key: WFCORE-1609
> URL: https://issues.jboss.org/browse/WFCORE-1609
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.2.0.CR4, 3.0.0.Alpha3
>
>
> The way a WildFly Core based distribution is able to control metadata such as the reported product name and version is by packaging an org.jboss.as.product:xxx module and then including a bin/product.conf file with a properties file that includes property slot=xxx. The ProductConfig class looks for bin/product.conf and reads it from the filesystem.
> This does not work for WildFly Swarm, which is not based on an expanded filesystem. There is no bin/product.conf file, not even a bin dir.
> This RFE is to have ProductConfig allow the slot name to be directly passed in, skipping the property file reading, with SelfContainerContainer (used by swarm) passing in a static value of "main". So swarm can package a org.jboss.as.product:main module and use it to control the product settings.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1619) Bad artifact resolution in wildfly-logging module
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1619?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1619:
-------------------------------------
Component/s: Logging
> Bad artifact resolution in wildfly-logging module
> -------------------------------------------------
>
> Key: WFCORE-1619
> URL: https://issues.jboss.org/browse/WFCORE-1619
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Test Suite
> Reporter: Carlo de Wolf
> Assignee: Tomaz Cerar
>
> The test doesn't use project artifact resolution, but global artifact resolution. While the project hasn't been published yet.
> {noformat}
> Tests run: 14, Failures: 0, Errors: 6, Skipped: 3, Time elapsed: 21.024 sec <<< FAILURE! - in org.jboss.as.logging.LoggingSubsystemTestCase
> testTransformersEAP620(org.jboss.as.logging.LoggingSubsystemTestCase) Time elapsed: 8.508 sec <<< ERROR!
> java.lang.RuntimeException: org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact org.wildfly.core:wildfly-subsystem-test-framework:jar:2.1.6.Final-redhat-SNAPSHOT in product-repository (https://maven.repository.redhat.com/nexus/content/groups/product-techprev...)
> at org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:39)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)
> at org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:138)
> at org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:839)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:724)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:691)
> at org.jboss.as.logging.LoggingSubsystemTestCase.testEapTransformer(LoggingSubsystemTestCase.java:281)
> at org.jboss.as.logging.LoggingSubsystemTestCase.testTransformersEAP620(LoggingSubsystemTestCase.java:130)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-6402:
-----------------------------------------------
Fedor Gavrilov <fgavrilo(a)redhat.com> changed the Status of [bug 1310908|https://bugzilla.redhat.com/show_bug.cgi?id=1310908] from ON_QA to POST
> EJBs accessible too early (spec violation)
> ------------------------------------------
>
> Key: WFLY-6402
> URL: https://issues.jboss.org/browse/WFLY-6402
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Fedor Gavrilov
> Labels: downstream_dependency
> Attachments: auto-test-reproducer.zip
>
>
> {code}
> EJB 3.1 spec, section 4.8.1:
> "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application.
> {code}
> Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1619) Bad artifact resolution in wildfly-logging module
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1619?page=com.atlassian.jira.plugi... ]
Carlo de Wolf commented on WFCORE-1619:
---------------------------------------
As a work-around you can use: mvn install
But that pollutes your cache.
> Bad artifact resolution in wildfly-logging module
> -------------------------------------------------
>
> Key: WFCORE-1619
> URL: https://issues.jboss.org/browse/WFCORE-1619
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Carlo de Wolf
> Assignee: Tomaz Cerar
>
> The test doesn't use project artifact resolution, but global artifact resolution. While the project hasn't been published yet.
> {noformat}
> Tests run: 14, Failures: 0, Errors: 6, Skipped: 3, Time elapsed: 21.024 sec <<< FAILURE! - in org.jboss.as.logging.LoggingSubsystemTestCase
> testTransformersEAP620(org.jboss.as.logging.LoggingSubsystemTestCase) Time elapsed: 8.508 sec <<< ERROR!
> java.lang.RuntimeException: org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact org.wildfly.core:wildfly-subsystem-test-framework:jar:2.1.6.Final-redhat-SNAPSHOT in product-repository (https://maven.repository.redhat.com/nexus/content/groups/product-techprev...)
> at org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:39)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355)
> at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581)
> at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
> at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)
> at org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:138)
> at org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:839)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:724)
> at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:691)
> at org.jboss.as.logging.LoggingSubsystemTestCase.testEapTransformer(LoggingSubsystemTestCase.java:281)
> at org.jboss.as.logging.LoggingSubsystemTestCase.testTransformersEAP620(LoggingSubsystemTestCase.java:130)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1619) Bad artifact resolution in wildfly-logging module
by Carlo de Wolf (JIRA)
Carlo de Wolf created WFCORE-1619:
-------------------------------------
Summary: Bad artifact resolution in wildfly-logging module
Key: WFCORE-1619
URL: https://issues.jboss.org/browse/WFCORE-1619
Project: WildFly Core
Issue Type: Bug
Components: Test Suite
Reporter: Carlo de Wolf
Assignee: Tomaz Cerar
The test doesn't use project artifact resolution, but global artifact resolution. While the project hasn't been published yet.
{noformat}
Tests run: 14, Failures: 0, Errors: 6, Skipped: 3, Time elapsed: 21.024 sec <<< FAILURE! - in org.jboss.as.logging.LoggingSubsystemTestCase
testTransformersEAP620(org.jboss.as.logging.LoggingSubsystemTestCase) Time elapsed: 8.508 sec <<< ERROR!
java.lang.RuntimeException: org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact org.wildfly.core:wildfly-subsystem-test-framework:jar:2.1.6.Final-redhat-SNAPSHOT in product-repository (https://maven.repository.redhat.com/nexus/content/groups/product-techprev...)
at org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:39)
at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355)
at org.eclipse.aether.util.concurrency.RunnableErrorForwarder$1.run(RunnableErrorForwarder.java:67)
at org.eclipse.aether.connector.basic.BasicRepositoryConnector$DirectExecutor.execute(BasicRepositoryConnector.java:581)
at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get(BasicRepositoryConnector.java:249)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads(DefaultArtifactResolver.java:520)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:421)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)
at org.jboss.as.model.test.MavenUtil.createMavenGavURL(MavenUtil.java:138)
at org.jboss.as.model.test.ChildFirstClassLoaderBuilder.addMavenResourceURL(ChildFirstClassLoaderBuilder.java:197)
at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.install(SubsystemTestDelegate.java:839)
at org.jboss.as.subsystem.test.SubsystemTestDelegate$LegacyKernelServiceInitializerImpl.access$700(SubsystemTestDelegate.java:724)
at org.jboss.as.subsystem.test.SubsystemTestDelegate$KernelServicesBuilderImpl.build(SubsystemTestDelegate.java:691)
at org.jboss.as.logging.LoggingSubsystemTestCase.testEapTransformer(LoggingSubsystemTestCase.java:281)
at org.jboss.as.logging.LoggingSubsystemTestCase.testTransformersEAP620(LoggingSubsystemTestCase.java:130)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1499) logging custom-handler does not load module with slot
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1499?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-1499:
-------------------------------------------------
Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1349223|https://bugzilla.redhat.com/show_bug.cgi?id=1349223] from NEW to ASSIGNED
> logging custom-handler does not load module with slot
> -----------------------------------------------------
>
> Key: WFCORE-1499
> URL: https://issues.jboss.org/browse/WFCORE-1499
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Erwan Lacoste
> Assignee: James Perkins
> Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> Tested on EAP 6.4
> when creating a module for a custom *loghandler*, everything works fine if the module is package in default main slot, e.g.
> my/loghandler/main
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler">
> {code}
> Nevertheless I want to version the module, therefore package my module with a given slot:
> my/loghandler/1.0
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler:1.0">
> {code}
> But this fails with following stacktrace:
> {code}
> 11:53:50,458 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
> ("subsystem" => "logging"),
> ("custom-handler" => "4H")
> ]): java.lang.IllegalArgumentException: JBAS011532: Failed to load module 'my.loghandler:1.0' for handler '4H'
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:320) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.performRuntime(HandlerOperations.java:255) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.LoggingOperations$LoggingAddOperationStepHandler$1.execute(LoggingOperations.java:206) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:702) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:537) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1144) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:416) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:355) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:330) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
> Caused by: org.jboss.modules.ModuleNotFoundException: my.loghandler:1.0:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240) [jboss-modules.jar:1.3.6.Final-redhat-1]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:295) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 13 more
> {code}
> why is the module not found being *my.loghandler:1.0:main* ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6655) When creating JMS bridge management API should pass bridge name to JMS broker
by Tom Ross (JIRA)
[ https://issues.jboss.org/browse/WFLY-6655?page=com.atlassian.jira.plugin.... ]
Tom Ross commented on WFLY-6655:
--------------------------------
Hi Chen,
No, this is not enough. There two places where changes are needed. One is Artemis code and the other is Wildly code.
This JIRA is for the wildly code change i.e. in JMSBridgeAdd class. Another is in artemis itself, but it's more extensie than just adding name to constructor. I'll submit PR today for all the changes.
> When creating JMS bridge management API should pass bridge name to JMS broker
> -----------------------------------------------------------------------------
>
> Key: WFLY-6655
> URL: https://issues.jboss.org/browse/WFLY-6655
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Environment: JBoss EAP 7.0
> Reporter: Tom Ross
> Assignee: Chen Maoqian
>
> In situations where there are multiple JMS bridges being created it woudl help if bridge name is logged in the server name. This helps with recognising which JMS bridge is having problems.
> For this to work the JBoss messaging API layer has to pass bridge name to the JMS broker.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months