[JBoss JIRA] (WFLY-6297) Identify problems introduced with new JDK9 versioning scheme
by Richard Opalka (JIRA)
[ https://issues.jboss.org/browse/WFLY-6297?page=com.atlassian.jira.plugin.... ]
Richard Opalka edited comment on WFLY-6297 at 3/1/16 5:25 AM:
--------------------------------------------------------------
After source code review we identified problems with new JDK9 versioning scheme in these classes:
modules/system/layers/base/org/eclipse/jdt/ecj/main/ecj-4.4.2.jar', class 'org/eclipse/jdt/internal/compiler/apt/util/EclipseFileManager', contains string [java.version]
modules/system/layers/base/org/eclipse/jdt/ecj/main/ecj-4.4.2.jar', class 'org/eclipse/jdt/internal/compiler/tool/EclipseFileManager', contains string [java.version]
modules/system/layers/base/org/apache/cxf/main/cxf-core-3.1.4.jar', class 'org/apache/cxf/common/util/ClassHelper', contains string [java.version]
modules/system/layers/base/org/apache/commons/beanutils/main/commons-beanutils-1.9.2.jar', class 'org/apache/commons/beanutils/MethodUtils', contains string [java.specification.version]
modules/system/layers/base/org/apache/commons/lang/main/commons-lang-2.6.jar', class 'org/apache/commons/lang/SystemUtils', contains strings [java.version]
modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-jboss-logmanager-1.1.2.Final.jar', class 'org/apache/log4j/helpers/Loader', contains string [java.version]
was (Author: ropalka):
After source code review we identified problems with new JDK9 versioning scheme in these classes:
jboss-modules.jar', class 'org/jboss/modules/Main', contains string [java.specification.version]
modules/system/layers/base/org/eclipse/jdt/ecj/main/ecj-4.4.2.jar', class 'org/eclipse/jdt/internal/compiler/apt/util/EclipseFileManager', contains string [java.version]
modules/system/layers/base/org/eclipse/jdt/ecj/main/ecj-4.4.2.jar', class 'org/eclipse/jdt/internal/compiler/tool/EclipseFileManager', contains string [java.version]
modules/system/layers/base/org/apache/cxf/main/cxf-core-3.1.4.jar', class 'org/apache/cxf/common/util/ClassHelper', contains string [java.version]
modules/system/layers/base/org/apache/commons/beanutils/main/commons-beanutils-1.9.2.jar', class 'org/apache/commons/beanutils/MethodUtils', contains string [java.specification.version]
modules/system/layers/base/org/apache/commons/lang/main/commons-lang-2.6.jar', class 'org/apache/commons/lang/SystemUtils', contains strings [java.version]
modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-jboss-logmanager-1.1.2.Final.jar', class 'org/apache/log4j/helpers/Loader', contains string [java.version]
> Identify problems introduced with new JDK9 versioning scheme
> ------------------------------------------------------------
>
> Key: WFLY-6297
> URL: https://issues.jboss.org/browse/WFLY-6297
> Project: WildFly
> Issue Type: Sub-task
> Components: Build System
> Affects Versions: 10.0.0.Final
> Reporter: Richard Opalka
> Assignee: Richard Opalka
>
> JDK9 will introduce new versioning scheme described here:
> http://openjdk.java.net/projects/verona/
> We need to identify WildFly components that are realying on
> these properties.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-5795) HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5795?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-5795:
-----------------------------------
I've opened ARTEMIS-425 to report the issue in Artemis codebase.
> HA JMS Topic Subscriber of Colocated life backup symmetrical 2 nodes cluster violates Publish-Subscribe pattern.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5795
> URL: https://issues.jboss.org/browse/WFLY-5795
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Environment: 2 node symmetrical colocated life backup cluster (domain mode). Configuration (domain.xml, host.xml) provided as attachment.
> Reporter: Michal Sudra
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 10.0.0.Final
>
> Attachments: ClusteredTopicTest.java, domain.xml, domain.xml, host-slave.xml, host.xml, host.xml, master.log, slave.log
>
>
> Test Client is producing 10 messages on topic on node 1 and 2 consumers connected to node 1 and the other to node 2 are then consuming the messages.
> Expectation: Every consumer receives 10 Messages.
> Result of test: Consumer connected to node 1 is only getting every second message. Consumer connected to node 2 is receiving all 10 messages:
> Output of test program:
> Sent message: This is text message 0
> Sent message: This is text message 1
> Sent message: This is text message 2
> Sent message: This is text message 3
> Sent message: This is text message 4
> Sent message: This is text message 5
> Sent message: This is text message 6
> Sent message: This is text message 7
> Sent message: This is text message 8
> Sent message: This is text message 9
> 0 Recieved message: This is text message 0 from node 0 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 2 from node 0 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 4 from node 0 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 6 from node 0 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 8 from node 0 from java:/jms/topic/ClusterStateTopic
> 5 error receiving message from node 0
> 6 error receiving message from node 0
> 7 error receiving message from node 0
> 8 error receiving message from node 0
> 9 error receiving message from node 0
> 0 Recieved message: This is text message 0 from node 1 from java:/jms/topic/ClusterStateTopic
> 1 Recieved message: This is text message 1 from node 1 from java:/jms/topic/ClusterStateTopic
> 2 Recieved message: This is text message 2 from node 1 from java:/jms/topic/ClusterStateTopic
> 3 Recieved message: This is text message 3 from node 1 from java:/jms/topic/ClusterStateTopic
> 4 Recieved message: This is text message 4 from node 1 from java:/jms/topic/ClusterStateTopic
> 5 Recieved message: This is text message 5 from node 1 from java:/jms/topic/ClusterStateTopic
> 6 Recieved message: This is text message 6 from node 1 from java:/jms/topic/ClusterStateTopic
> 7 Recieved message: This is text message 7 from node 1 from java:/jms/topic/ClusterStateTopic
> 8 Recieved message: This is text message 8 from node 1 from java:/jms/topic/ClusterStateTopic
> 9 Recieved message: This is text message 9 from node 1 from java:/jms/topic/ClusterStateTopic
> The test program is added and the 2 node names are given as parameters for main.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6269) connector-service resource does not define a module for the classes to load
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6269?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-6269:
-----------------------------------
I've created WFLY-6301 to apply the "global" solution of adding an optional module to WFLY 10.
> connector-service resource does not define a module for the classes to load
> ---------------------------------------------------------------------------
>
> Key: WFLY-6269
> URL: https://issues.jboss.org/browse/WFLY-6269
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> The connector-service resource has only a factory-class attribute and does not specify from which module the class should be loaded.
> {noformat}
> <connector-service name="b"
> factory-class="bar.foo">
> <param name="foo"
> value="${connector.value:bar}"/>
> <param name="bar"
> value="2"/>
> </connector-service>
> {noformat}
> This means that the module defining the class must be a dependency of the org.apache.activemq.artemis module since it's Artemis that currently loads it.
> A module attribute should be added so that the class could be loaded from any module.
> The messaging-activemq subsystem would then be able to load it and pass it to Artemis's ServiceRegistry (similarly to the interceptors).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6301) Add an optional module for classes loaded by ActiveMQ
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6301?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-6301:
------------------------------
Summary: Add an optional module for classes loaded by ActiveMQ (was: An an optional module for classes loaded by ActiveMQ)
> Add an optional module for classes loaded by ActiveMQ
> -----------------------------------------------------
>
> Key: WFLY-6301
> URL: https://issues.jboss.org/browse/WFLY-6301
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Minor
>
> ActiveMQ Artemis configuration accepts some class definitions for user-specified behaviour (eg connector-services, interceptors, transformers).
> To work in a modular environment, WildFly requires to load the classes from a module and pass it to Artemis (using their ServiceRegistry).
> Not all these resources have been updated to specify such a module (eg transformers and connector-services configuration only specify a class attribute and not a module).
> Currently, the user must modify the org.apache.activemq.artemis module definition to add dependency to the module defining these classes. This breaks patching as the module definition has been manually edited and it is up to the user to undo his changes and reapply them after patching in overlays...
> Adding a module attribute to these resources is a significant management change (adding a new version, new XSD, transformers to previous versions) and should happen on a WFLY minor changes (eg for WFLY 11.x).
> However, we can work around this limitation by adding an _optional_ module (eg named org.apache.activemq.artemis.addons) to the org.apache.activemq.artemis module definition.
> This optional module does not exist by default but it can be created by the user and any classes required by Artemis configuration can be put in it.
> This has the advantage that the org.apache.activemq.artemis module definition is _no longer modified_ if the users needs such classes and patching will work as expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6301) An an optional module for classes loaded by ActiveMQ
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-6301:
---------------------------------
Summary: An an optional module for classes loaded by ActiveMQ
Key: WFLY-6301
URL: https://issues.jboss.org/browse/WFLY-6301
Project: WildFly
Issue Type: Enhancement
Components: JMS
Affects Versions: 10.0.0.Final
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Priority: Minor
ActiveMQ Artemis configuration accepts some class definitions for user-specified behaviour (eg connector-services, interceptors, transformers).
To work in a modular environment, WildFly requires to load the classes from a module and pass it to Artemis (using their ServiceRegistry).
Not all these resources have been updated to specify such a module (eg transformers and connector-services configuration only specify a class attribute and not a module).
Currently, the user must modify the org.apache.activemq.artemis module definition to add dependency to the module defining these classes. This breaks patching as the module definition has been manually edited and it is up to the user to undo his changes and reapply them after patching in overlays...
Adding a module attribute to these resources is a significant management change (adding a new version, new XSD, transformers to previous versions) and should happen on a WFLY minor changes (eg for WFLY 11.x).
However, we can work around this limitation by adding an _optional_ module (eg named org.apache.activemq.artemis.addons) to the org.apache.activemq.artemis module definition.
This optional module does not exist by default but it can be created by the user and any classes required by Artemis configuration can be put in it.
This has the advantage that the org.apache.activemq.artemis module definition is _no longer modified_ if the users needs such classes and patching will work as expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6269) connector-service resource does not define a module for the classes to load
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6269?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil edited comment on WFLY-6269 at 3/1/16 4:12 AM:
-----------------------------------------------------------
There is a global solution that would work in all cases: add an optional module dependency to org.apache.activemq.artemis module (eg named "org.apache.activemq.artemis.addons").
Since it is an optional module, it does not require to exist. If users wants to specify specific classes in Artemis, they could create this module and add the classes to it so that Artemis could load them.
This also make sure that the user does not have to edit org.apache.activemq.artemis own module definition (which prevents patching to work).
Ideally, all the resources that requires to load classes should define both a class name and a module. In practice, this is important for the transformers of the divert and bridge resources and the connector-services. This is less important for the connector/acceptor (the implementations are so complex, I've never see anybody specifying something other than Artemis own implementations) and connection-load-balancing-policy-class-name.
Changing these resource definitions is more involving (it requires new management versions, XSD, transformers, etc.) and would be better addressed in WFLY 11.x.
The global solution of adding an optional module can be done in WFLY 10.x timeframe and will not prevent refining the resources later on.
was (Author: jmesnil):
There is a global solution that would work in all cases: add an optional module dependency to org.apache.activemq.artemis module (eg named "org.apache.activemq.artemis.addons").
Since it is an optional module, it does not require to exist. If users wants to specify specific classes in Artemis, they could create this module and add the classes to it so that Artemis could load them.
This also make sure that the user does not have to edit org.apache.activemq.artemis own module definition (which prevents patching to work).
Ideally, all the resources that requires to load classes should define both a class name and a module. In practice, this is important for the transformers of the divert and bridge resources. This is less important for the connector/acceptor (the implementations are so complex, I've never see anybody specifying something other than Artemis own implementations) and connection-load-balancing-policy-class-name.
Changing these resource definitions is more involving (it requires new management versions, XSD, transformers, etc.) and would be better addressed in WFLY 11.x.
The global solution of adding an optional module can be done in WFLY 10.x timeframe and will not prevent refining the resources later on.
> connector-service resource does not define a module for the classes to load
> ---------------------------------------------------------------------------
>
> Key: WFLY-6269
> URL: https://issues.jboss.org/browse/WFLY-6269
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> The connector-service resource has only a factory-class attribute and does not specify from which module the class should be loaded.
> {noformat}
> <connector-service name="b"
> factory-class="bar.foo">
> <param name="foo"
> value="${connector.value:bar}"/>
> <param name="bar"
> value="2"/>
> </connector-service>
> {noformat}
> This means that the module defining the class must be a dependency of the org.apache.activemq.artemis module since it's Artemis that currently loads it.
> A module attribute should be added so that the class could be loaded from any module.
> The messaging-activemq subsystem would then be able to load it and pass it to Artemis's ServiceRegistry (similarly to the interceptors).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-6269) connector-service resource does not define a module for the classes to load
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6269?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-6269:
-----------------------------------
There is a global solution that would work in all cases: add an optional module dependency to org.apache.activemq.artemis module (eg named "org.apache.activemq.artemis.addons").
Since it is an optional module, it does not require to exist. If users wants to specify specific classes in Artemis, they could create this module and add the classes to it so that Artemis could load them.
This also make sure that the user does not have to edit org.apache.activemq.artemis own module definition (which prevents patching to work).
Ideally, all the resources that requires to load classes should define both a class name and a module. In practice, this is important for the transformers of the divert and bridge resources. This is less important for the connector/acceptor (the implementations are so complex, I've never see anybody specifying something other than Artemis own implementations) and connection-load-balancing-policy-class-name.
Changing these resource definitions is more involving (it requires new management versions, XSD, transformers, etc.) and would be better addressed in WFLY 11.x.
The global solution of adding an optional module can be done in WFLY 10.x timeframe and will not prevent refining the resources later on.
> connector-service resource does not define a module for the classes to load
> ---------------------------------------------------------------------------
>
> Key: WFLY-6269
> URL: https://issues.jboss.org/browse/WFLY-6269
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> The connector-service resource has only a factory-class attribute and does not specify from which module the class should be loaded.
> {noformat}
> <connector-service name="b"
> factory-class="bar.foo">
> <param name="foo"
> value="${connector.value:bar}"/>
> <param name="bar"
> value="2"/>
> </connector-service>
> {noformat}
> This means that the module defining the class must be a dependency of the org.apache.activemq.artemis module since it's Artemis that currently loads it.
> A module attribute should be added so that the class could be loaded from any module.
> The messaging-activemq subsystem would then be able to load it and pass it to Artemis's ServiceRegistry (similarly to the interceptors).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (DROOLS-1074) Kie-spring read resources on EAP not working
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1074?page=com.atlassian.jira.plugi... ]
Petr Široký updated DROOLS-1074:
--------------------------------
Component/s: integration
> Kie-spring read resources on EAP not working
> --------------------------------------------
>
> Key: DROOLS-1074
> URL: https://issues.jboss.org/browse/DROOLS-1074
> Project: Drools
> Issue Type: Bug
> Components: integration
> Affects Versions: 6.4.0.Beta2
> Reporter: David virgil naranjo
> Assignee: Petr Široký
>
> had to touch little bit the Kie-Spring to get the resources correctly. This is the only class I had to touch:
> https://gist.github.com/dvirgiln/0f65d184c2004127b1db#file-gistfile1-txt-...
> getClass().getResource("/") is failing on EAP, it returns null
> This code needs to get the path of the kie-spring.jar. This is the only way I found to get the containing jar path.
> This code is working. Maybe you know another way.
> ClassLoader cl = getClass().getClassLoader();
> URL url = getClass().getProtectionDomain().getCodeSource().getLocation();
> configFilePath = url.getPath();
> if (configFilePath.endsWith("!/")) {
> configFilePath = configFilePath.substring(0, configFilePath.length() - 2);
> }
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (JGRP-2022) XSD schemas do not properly validate
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2022?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2022 at 3/1/16 1:46 AM:
--------------------------------------------------------
I ran all schemas listed above through IntelliJ IDEA's XML validator, and they all passed with 0 errors. I don't have access to Oxygen as I don't want to register. Any other tool I could use for validation?
was (Author: belaban):
I ran all schemas listed above through IntelliJ IDEA's XML validator, and they all passed with 0 errors. I don't have access to Oxygen as I don't ant to register. Any other tool I could use for validation?
> XSD schemas do not properly validate
> ------------------------------------
>
> Key: JGRP-2022
> URL: https://issues.jboss.org/browse/JGRP-2022
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.8
> Reporter: Manuel Dominguez Sarmiento
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.0
>
>
> Affected resources:
> - jgroups.xsd
> - relay.xsd
> - fork-stacks.xsd
> Paste these files into an Eclipse project, or run them through Oxygen XML or any other XML / XSD validator, you will get errors relating to src-resolve.4.1
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months