[JBoss JIRA] (JBEE-191) JAXB API loading default impl fails in Java 9
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBEE-191?page=com.atlassian.jira.plugin.s... ]
David Lloyd updated JBEE-191:
-----------------------------
Fix Version/s: (was: jboss-jaxb-api_2.2_spec-1.0.5.Final)
> JAXB API loading default impl fails in Java 9
> ---------------------------------------------
>
> Key: JBEE-191
> URL: https://issues.jboss.org/browse/JBEE-191
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-jaxb-api
> Affects Versions: jboss-jaxb-api_2.3_spec-1.0.1.Final
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: jboss-jaxb-api_2.3_spec-1.0.2.Final
>
>
> The platform default provider is instantiated with a null class loader, which is not likely to work since the JDK will be linking against the wrong API. In addition, these classes are private in Java 9+ so even if it did link correctly, the instantiation would fail due to the non-exported package.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBEE-191) JAXB API loading default impl fails in Java 9
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBEE-191?page=com.atlassian.jira.plugin.s... ]
David Lloyd updated JBEE-191:
-----------------------------
Affects Version/s: (was: jboss-jaxb-api_2.2_spec-1.0.4.Final)
> JAXB API loading default impl fails in Java 9
> ---------------------------------------------
>
> Key: JBEE-191
> URL: https://issues.jboss.org/browse/JBEE-191
> Project: JBoss JavaEE Spec APIs
> Issue Type: Bug
> Components: jboss-jaxb-api
> Affects Versions: jboss-jaxb-api_2.3_spec-1.0.1.Final
> Reporter: David Lloyd
> Assignee: David Lloyd
> Fix For: jboss-jaxb-api_2.3_spec-1.0.2.Final
>
>
> The platform default provider is instantiated with a null class loader, which is not likely to work since the JDK will be linking against the wrong API. In addition, these classes are private in Java 9+ so even if it did link correctly, the instantiation would fail due to the non-exported package.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (JBEE-191) JAXB API loading default impl fails in Java 9
by David Lloyd (JIRA)
David Lloyd created JBEE-191:
--------------------------------
Summary: JAXB API loading default impl fails in Java 9
Key: JBEE-191
URL: https://issues.jboss.org/browse/JBEE-191
Project: JBoss JavaEE Spec APIs
Issue Type: Bug
Components: jboss-jaxb-api
Affects Versions: jboss-jaxb-api_2.2_spec-1.0.4.Final, jboss-jaxb-api_2.3_spec-1.0.1.Final
Reporter: David Lloyd
Assignee: David Lloyd
Fix For: jboss-jaxb-api_2.2_spec-1.0.5.Final, jboss-jaxb-api_2.3_spec-1.0.2.Final
The platform default provider is instantiated with a null class loader, which is not likely to work since the JDK will be linking against the wrong API. In addition, these classes are private in Java 9+ so even if it did link correctly, the instantiation would fail due to the non-exported package.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFLY-8620) wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-8620?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-8620:
-----------------------------------
OK thanks.
> wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-8620
> URL: https://issues.jboss.org/browse/WFLY-8620
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Amos Feng
> Assignee: David Lloyd
> Priority: Critical
> Labels: Java9
>
> {noformat}
> Running org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.467 sec <<< FAILURE! - in org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> testSpecificProviderCanBeConfiguredInValidationXml(org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase) Time elapsed: 0.283 sec <<< ERROR!
> javax.validation.ValidationException: HV000100: Unable to parse META-INF/validation.xml.
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:292)
> at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:508)
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:194)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:405)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:33)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:19)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:219)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:127)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:88)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:393)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:476)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:309)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.initFactory(LazyValidatorFactory.java:81)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getDelegate(LazyValidatorFactory.java:58)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:73)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase.testSpecificProviderCanBeConfiguredInValidationXml(LazyValidatorFactoryTestCase.java:70)
> {noformat}
> It could need to add the java.xml modules
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFLY-8620) wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-8620?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned WFLY-8620:
---------------------------------
Assignee: David Lloyd (was: Amos Feng)
> wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-8620
> URL: https://issues.jboss.org/browse/WFLY-8620
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Amos Feng
> Assignee: David Lloyd
> Priority: Critical
> Labels: Java9
>
> {noformat}
> Running org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.467 sec <<< FAILURE! - in org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> testSpecificProviderCanBeConfiguredInValidationXml(org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase) Time elapsed: 0.283 sec <<< ERROR!
> javax.validation.ValidationException: HV000100: Unable to parse META-INF/validation.xml.
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:292)
> at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:508)
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:194)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:405)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:33)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:19)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:219)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:127)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:88)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:393)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:476)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:309)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.initFactory(LazyValidatorFactory.java:81)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getDelegate(LazyValidatorFactory.java:58)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:73)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase.testSpecificProviderCanBeConfiguredInValidationXml(LazyValidatorFactoryTestCase.java:70)
> {noformat}
> It could need to add the java.xml modules
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFLY-8620) wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/WFLY-8620?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on WFLY-8620:
---------------------------------
[~dmlloyd] I'm not working on this issue.
> wildfly-bean-validation LazyValidatorFactoryTestCase test failed when running with JDK9
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-8620
> URL: https://issues.jboss.org/browse/WFLY-8620
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Amos Feng
> Assignee: Amos Feng
> Priority: Critical
> Labels: Java9
>
> {noformat}
> Running org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.467 sec <<< FAILURE! - in org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase
> testSpecificProviderCanBeConfiguredInValidationXml(org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase) Time elapsed: 0.283 sec <<< ERROR!
> javax.validation.ValidationException: HV000100: Unable to parse META-INF/validation.xml.
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:533)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:186)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:476)
> at java.base/java.lang.Class.forName0(Native Method)
> at java.base/java.lang.Class.forName(Class.java:292)
> at javax.xml.bind.ContextFinder.safeLoadClass(ContextFinder.java:508)
> at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:194)
> at javax.xml.bind.ContextFinder.find(ContextFinder.java:405)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:618)
> at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:565)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:33)
> at org.hibernate.validator.internal.util.privilegedactions.NewJaxbContext.run(NewJaxbContext.java:19)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.run(ValidationXmlParser.java:219)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.unmarshal(ValidationXmlParser.java:127)
> at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:88)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.getBootstrapConfiguration(ConfigurationImpl.java:393)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:476)
> at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:309)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.initFactory(LazyValidatorFactory.java:81)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getDelegate(LazyValidatorFactory.java:58)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:73)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactoryTestCase.testSpecificProviderCanBeConfiguredInValidationXml(LazyValidatorFactoryTestCase.java:70)
> {noformat}
> It could need to add the java.xml modules
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFLY-10155) Missing message JMS bridge with DUPS_OK quality of service
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-10155:
----------------------------------
Summary: Missing message JMS bridge with DUPS_OK quality of service
Key: WFLY-10155
URL: https://issues.jboss.org/browse/WFLY-10155
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Miroslav Novak
Assignee: Jeff Mesnil
There is missing one message in scenario where JMS bridge (with DUPS_OK) resending messages from one server to another. Durint resending target server is killed and bridge does failover to backup.
After failover in server logs there are lots of warns/errors:
{code}
05:39:01,697 WARN [org.apache.activemq.artemis.jms.bridge] (Thread-144) AMQ342009: JMS Bridge N/A failed to send + acknowledge batch, closing JMS objects: javax.jms.JMSException: Duplicate message detected - me
ssage will not be routed. Message information:LargeServerMessage[messageID=2147485500,durable=true,userID=d8ea8e0a-326b-11e8-b74b-fa163e64a220,priority=4, timestamp=Wed Mar 28 05:39:01 EDT 2018,expiration=0, dur
able=true, address=jms.queue.OutQueue,size=410263,properties=TypedProperties[__AMQ_CID=bd95a355-326b-11e8-b74b-fa163e64a220,_AMQ_ROUTING_TYPE=1,AMQ_BRIDGE_MSG_ID_LIST=ID:c13a41dc-326b-11e8-949b-fa163e64a220,JMSX
DeliveryCount=10,count=989,color=RED,counter=990,_AMQ_DUPL_ID=fde672e0-e858-4c50-a148-a0b7a4a223591522229901951,_AMQ_LARGE_SIZE=409615]]@1304406481
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:423) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:319) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.simpleCommit(ActiveMQSessionContext.java:381) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.commit(ClientSessionImpl.java:862) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.commit(ClientSessionImpl.java:835) [artemis-core-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.jms.client.ActiveMQSession.commit(ActiveMQSession.java:231) [artemis-jms-client-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.sendBatchNonTransacted(JMSBridgeImpl.java:1338) [artemis-jms-server-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.sendBatch(JMSBridgeImpl.java:1298) [artemis-jms-server-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$1700(JMSBridgeImpl.java:74) [artemis-jms-server-2.5.0.jar:2.5.0]
at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$SourceReceiver.run(JMSBridgeImpl.java:1694) [artemis-jms-server-2.5.0.jar:2.5.0]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_162]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_162]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_162]
Caused by: ActiveMQDuplicateIdException[errorType=DUPLICATE_ID_REJECTED message=Duplicate message detected - message will not be routed. Message information:LargeServerMessage[messageID=2147485500,durable=true,u
serID=d8ea8e0a-326b-11e8-b74b-fa163e64a220,priority=4, timestamp=Wed Mar 28 05:39:01 EDT 2018,expiration=0, durable=true, address=jms.queue.OutQueue,size=410263,properties=TypedProperties[__AMQ_CID=bd95a355-326b
-11e8-b74b-fa163e64a220,_AMQ_ROUTING_TYPE=1,AMQ_BRIDGE_MSG_ID_LIST=ID:c13a41dc-326b-11e8-949b-fa163e64a220,JMSXDeliveryCount=10,count=989,color=RED,counter=990,_AMQ_DUPL_ID=fde672e0-e858-4c50-a148-a0b7a4a2235915
22229901951,_AMQ_LARGE_SIZE=409615]]@1304406481]
... 13 more
05:39:01,699 WARN [org.apache.activemq.artemis.core.server] (Thread-23 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@2076a02)) AMQ222149: Message Reference[3056]:RELIABLE:Co
reMessage[messageID=3056,durable=true,userID=c1347573-326b-11e8-949b-fa163e64a220,priority=4, timestamp=Wed Mar 28 05:38:21 EDT 2018,expiration=0, durable=true, address=jms.queue.InQueue,size=10673,properties=Ty
pedProperties[__AMQ_CID=be528a5c-326b-11e8-949b-fa163e64a220,_AMQ_ROUTING_TYPE=1,count=980,counter=981,_AMQ_DUPL_ID=13adf1ec-581f-42e4-835b-0e6e33a4e1191522229901913,color=GREEN]]@511432790 has reached maximum d
elivery attempts, sending it to Dead Letter Address jms.queue.DLQ from jms.queue.InQueue
05:39:01,700 WARN [org.apache.activemq.artemis.core.server] (Thread-23 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@2076a02)) AMQ222149: Message Reference[3058]:RELIABLE:CoreMessage[messageID=3058,durable=true,userID=c1349c84-326b-11e8-949b-fa163e64a220,priority=4, timestamp=Wed Mar 28 05:38:21 EDT 2018,expiration=0, durable=true, address=jms.queue.InQueue,size=20914,properties=TypedProperties[__AMQ_CID=be528a5c-326b-11e8-949b-fa163e64a220,_AMQ_ROUTING_TYPE=1,count=981,counter=982,_AMQ_DUPL_ID=6feb66cd-8616-4dff-8775-3f85a4b9bdbb1522229901914,color=RED]]@1150646585 has reached maximum delivery attempts, sending it to Dead Letter Address jms.queue.DLQ from jms.queue.InQueue
....
05:39:01,706 WARN [org.apache.activemq.artemis.core.server] (Thread-23 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@2076a02)) AMQ222149: Message Reference[3082]:RELIABLE:CoreMessage[messageID=3082,durable=true,userID=c13d4f1d-326b-11e8-949b-fa163e64a220,priority=4, timestamp=Wed Mar 28 05:38:21 EDT 2018,expiration=0, durable=true, address=jms.queue.InQueue,size=10673,properties=TypedProperties[__AMQ_CID=be528a5c-326b-11e8-949b-fa163e64a220,_AMQ_ROUTING_TYPE=1,count=990,counter=991,_AMQ_DUPL_ID=f802f4b7-e0a1-4dee-acc7-0b11963bec401522229901971,color=GREEN]]@2708478 has reached maximum delivery attempts, sending it to Dead Letter Address jms.queue.DLQ from jms.queue.InQueue
{code}
So the missing message ended up in DLQ as it could not be delivered to target queue. It looks like that _AMQ_DUPL_ID might trigger dup message detection in target queueu however such message did not get there.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (WFLY-10154) Lost message when MDB is resending messages under high load
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-10154:
----------------------------------
Summary: Lost message when MDB is resending messages under high load
Key: WFLY-10154
URL: https://issues.jboss.org/browse/WFLY-10154
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Miroslav Novak
Assignee: Martyn Taylor
Priority: Blocker
Test scenario:
* Start cluster A of nodes node-1, node-3
* Start cluster B of nodes node-2, node-4
* Send messages to queue on node-1
* Deploy mdbs to servers in cluster A. This mdb reads messages from local queue, sends them to remote queue on cluster B and inserts them into database
* Deploy mdbs to servers in cluster B. This mdb reads messages from local queue and inserts them into database
* Cause CPU overload (for 5 min) on server node-2 when mdbs on cluster1 and 2 are processing mesages
* Restart failed server
* Let MDBs to process remaining messages
Pass Criteria: Number of sent message is equal number of records(lines) in database and messages in
Actual Result:
Sometimes happens that one record is missing in database which means that one message was not processed be MDB in cluster 2.
This looks like broker related regression against Artemis 1.5.
Wildfly: https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (06c878a313d3cad323889d017e60fd5533204d1a)
Artemis tag 2.5.0.Final
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months