[JBoss JIRA] (JGRP-2334) TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses
by Falco Thiel (Jira)
[ https://issues.jboss.org/browse/JGRP-2334?page=com.atlassian.jira.plugin.... ]
Falco Thiel updated JGRP-2334:
------------------------------
Description:
We want to discuss a change in the TCPPing module.
We plan to run wildfly instances in a container orchestration system. In the system which we want to use, the node discovery over multicast is not working.
The other solution is to use TCPPing with initial_hosts set. But now we have to solve the following problems:
* the initial_hosts property is not very dynamic
* the ip addresses will/can change if a container is restarted
* the host names are dynamically generated
At this point it seems the node discovery can not be done with TCPPing, at least not in an easy way.
The main problem: How to find out all running nodes for a server group?
Now we investigate our orchestration system and find a solution to solve the problem. Our orchestration system (and we think others will have this too) has an internal DNS service.
Over this service all containers for a dns name can be resolved with a nslookup request.
Example:
We have a scalable wildfly service. We name it "wildfly-server". If a container under this service is started then the container gets a host name like "wildfly-server-0" and a dynamic ip address.
After starting one or more container we can do a nslookup with the service name:
>nslookup wildfly-server
Name: wildfly-server
Address 1: 10.42.2.139 wildfly-server-1.wildfly-server
Address 2: 10.42.1.198 wildfly-server-0.wildfly-server
Address 3: 10.42.0.161 wildfly-server-2.wildfly-server
The service name has multiple A-Records registered. If an instance is started or stopped then the DNS Records are updated. Now we tried to use this service name for the initial_hosts property.
initial_hosts=wildfly-server[7600]
Sometimes it worked and sometimes it doesn't. The reason was that only the first InetAddress entry was used in the org.jgroups.util.Util class (method parseCommaDelimitedHosts). After we changed it a bit (see [https://github.com/Sternwald-Systems/JGroups/commit/db0b899f9c67348a0cb07...] ) it worked as expected. What we do is to call InetAddress.getAllByName(host) and loop over the result array, instead of just using the first array element.
There is only one limitation if the domain mode with more than one server group is used. Here the same port offset for all servers of one server group must be set.
*Conclusion*
There are different orchestration systems available on the market. The worst case will be to write a custom discovery service for jgroups for each of them.
For instance for the kubernetes system there already exists such a service (jgroups-kubernetes).
But if an orchestration system already has an internal DNS service to resolve a dns name to get all running containers TCPPing (with our changes) could be used out of the box.
Additionally there is a second method in the org.jgroups.util.Util class called parseCommaDelimitedHosts2 which does nearly the same but for the TCPGossip protocol.
We think it would make sense to change this method too, otherwise there are different behaviors. I you don't mind, we would apply the changes to this method too, before creating a pull request.
It is also important to document this well so other people can find this information if they have the same problem.
was:
We want to discuss a change in the TCPPing module.
We plan to run wildfly instances in a container orchestration system. In the system which we want to use, the node discovery over multicast is not working.
The other solution is to use TCPPing with initial_hosts set. But now we have to solve the following problems:
* the initial_hosts property is not very dynamic
* the ip addresses will/can change if a container is restarted
* the host names are dynamically generated
At this point it seems the node discovery can not be done with TCPPing, at least not in an easy way.
The main problem: How to find out all running nodes for a server group?
Now we investigate our orchestration system and find a solution to solve the problem. Our orchestration system (and we think others will have this too) has an internal DNS service.
Over this service all containers for a dns name can be resolved with a nslookup request.
Example:
We have a scalable wildfly service. We name it "wildfly-server". If a container under this service is started then the container gets a host name like "wildfly-server-0" and a dynamic ip address.
After starting one or more container we can do a nslookup with the service name:
>nslookup wildfly-server
Name: wildfly-server
Address 1: 10.42.2.139 wildfly-server-1.wildfly-server
Address 2: 10.42.1.198 wildfly-server-0.wildfly-server
Address 3: 10.42.0.161 wildfly-server-2.wildfly-server
The service name has multiple A-Records registered. If an instance is started or stopped then the DNS Records are updated. Now we tried to use this service name for the initial_hosts property.
initial_hosts=wildfly-server[7600]
Sometimes it worked and sometimes it doesn't. The reason was that only the first InetAddress entry was used in the org.jgroups.util.Util class (method parseCommaDelimitedHosts). After we changed it a bit (see [https://github.com/Sternwald-Systems/JGroups/commit/db0b899f9c67348a0cb07...] ) it worked as expected. What we do is to call InetAddress.getAllByName(host) and loop over the result array, instead of just using the first array element.
There is only one limitation if the domain mode with more than one server group is used. Here the same port offset for all servers of one server group must be set.
*Conclusion*
There are different orchestration systems available on the market. The worst case will be to write a custom discovery service for jgroups for each of them.
For instance for the kubernetes system there already exists such a service (jgroups-kubernetes).
But if an orchestration system already has an internal DNS service to resolve a dns name to get all running containers TCPPing (with our changes) could be used out of the box.
Additionally there is a second method in the org.jgroups.util.Util class called parseCommaDelimitedHosts2 which does nearly the same but for the TCPGossip protocol.
We think it would make sense to change this method too, otherwise there are different behaviors. I you don't mind, we would apply the changes to this method too, before creating a pull request.
It is also important to document this well so other people can find this information if they have the same problem.
> TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses
> -----------------------------------------------------------------------------
>
> Key: JGRP-2334
> URL: https://issues.jboss.org/browse/JGRP-2334
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.19
> Reporter: Falco Thiel
> Assignee: Bela Ban
> Priority: Major
>
> We want to discuss a change in the TCPPing module.
> We plan to run wildfly instances in a container orchestration system. In the system which we want to use, the node discovery over multicast is not working.
> The other solution is to use TCPPing with initial_hosts set. But now we have to solve the following problems:
> * the initial_hosts property is not very dynamic
> * the ip addresses will/can change if a container is restarted
> * the host names are dynamically generated
> At this point it seems the node discovery can not be done with TCPPing, at least not in an easy way.
> The main problem: How to find out all running nodes for a server group?
> Now we investigate our orchestration system and find a solution to solve the problem. Our orchestration system (and we think others will have this too) has an internal DNS service.
> Over this service all containers for a dns name can be resolved with a nslookup request.
> Example:
> We have a scalable wildfly service. We name it "wildfly-server". If a container under this service is started then the container gets a host name like "wildfly-server-0" and a dynamic ip address.
> After starting one or more container we can do a nslookup with the service name:
> >nslookup wildfly-server
> Name: wildfly-server
> Address 1: 10.42.2.139 wildfly-server-1.wildfly-server
> Address 2: 10.42.1.198 wildfly-server-0.wildfly-server
> Address 3: 10.42.0.161 wildfly-server-2.wildfly-server
> The service name has multiple A-Records registered. If an instance is started or stopped then the DNS Records are updated. Now we tried to use this service name for the initial_hosts property.
> initial_hosts=wildfly-server[7600]
> Sometimes it worked and sometimes it doesn't. The reason was that only the first InetAddress entry was used in the org.jgroups.util.Util class (method parseCommaDelimitedHosts). After we changed it a bit (see [https://github.com/Sternwald-Systems/JGroups/commit/db0b899f9c67348a0cb07...] ) it worked as expected. What we do is to call InetAddress.getAllByName(host) and loop over the result array, instead of just using the first array element.
> There is only one limitation if the domain mode with more than one server group is used. Here the same port offset for all servers of one server group must be set.
> *Conclusion*
> There are different orchestration systems available on the market. The worst case will be to write a custom discovery service for jgroups for each of them.
> For instance for the kubernetes system there already exists such a service (jgroups-kubernetes).
> But if an orchestration system already has an internal DNS service to resolve a dns name to get all running containers TCPPing (with our changes) could be used out of the box.
> Additionally there is a second method in the org.jgroups.util.Util class called parseCommaDelimitedHosts2 which does nearly the same but for the TCPGossip protocol.
> We think it would make sense to change this method too, otherwise there are different behaviors. I you don't mind, we would apply the changes to this method too, before creating a pull request.
> It is also important to document this well so other people can find this information if they have the same problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (JGRP-2334) TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses
by Falco Thiel (Jira)
Falco Thiel created JGRP-2334:
---------------------------------
Summary: TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses
Key: JGRP-2334
URL: https://issues.jboss.org/browse/JGRP-2334
Project: JGroups
Issue Type: Feature Request
Affects Versions: 4.0.19
Reporter: Falco Thiel
Assignee: Bela Ban
We want to discuss a change in the TCPPing module.
We plan to run wildfly instances in a container orchestration system. In the system which we want to use, the node discovery over multicast is not working.
The other solution is to use TCPPing with initial_hosts set. But now we have to solve the following problems:
* the initial_hosts property is not very dynamic
* the ip addresses will/can change if a container is restarted
* the host names are dynamically generated
At this point it seems the node discovery can not be done with TCPPing, at least not in an easy way.
The main problem: How to find out all running nodes for a server group?
Now we investigate our orchestration system and find a solution to solve the problem. Our orchestration system (and we think others will have this too) has an internal DNS service.
Over this service all containers for a dns name can be resolved with a nslookup request.
Example:
We have a scalable wildfly service. We name it "wildfly-server". If a container under this service is started then the container gets a host name like "wildfly-server-0" and a dynamic ip address.
After starting one or more container we can do a nslookup with the service name:
>nslookup wildfly-server
Name: wildfly-server
Address 1: 10.42.2.139 wildfly-server-1.wildfly-server
Address 2: 10.42.1.198 wildfly-server-0.wildfly-server
Address 3: 10.42.0.161 wildfly-server-2.wildfly-server
The service name has multiple A-Records registered. If an instance is started or stopped then the DNS Records are updated. Now we tried to use this service name for the initial_hosts property.
initial_hosts=wildfly-server[7600]
Sometimes it worked and sometimes it doesn't. The reason was that only the first InetAddress entry was used in the org.jgroups.util.Util class (method parseCommaDelimitedHosts). After we changed it a bit (see [https://github.com/Sternwald-Systems/JGroups/commit/db0b899f9c67348a0cb07...] ) it worked as expected. What we do is to call InetAddress.getAllByName(host) and loop over the result array, instead of just using the first array element.
There is only one limitation if the domain mode with more than one server group is used. Here the same port offset for all servers of one server group must be set.
*Conclusion*
There are different orchestration systems available on the market. The worst case will be to write a custom discovery service for jgroups for each of them.
For instance for the kubernetes system there already exists such a service (jgroups-kubernetes).
But if an orchestration system already has an internal DNS service to resolve a dns name to get all running containers TCPPing (with our changes) could be used out of the box.
Additionally there is a second method in the org.jgroups.util.Util class called parseCommaDelimitedHosts2 which does nearly the same but for the TCPGossip protocol.
We think it would make sense to change this method too, otherwise there are different behaviors. I you don't mind, we would apply the changes to this method too, before creating a pull request.
It is also important to document this well so other people can find this information if they have the same problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-3784) Increase the advanced user productivity when he creates a new Data Type
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3784?page=com.atlassian.jira.plugi... ]
Michael Anstis reassigned DROOLS-3784:
--------------------------------------
Assignee: Guilherme Carreiro (was: Michael Anstis)
> Increase the advanced user productivity when he creates a new Data Type
> -----------------------------------------------------------------------
>
> Key: DROOLS-3784
> URL: https://issues.jboss.org/browse/DROOLS-3784
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor
> Affects Versions: 7.18.0.Final
> Reporter: Donato Marrazzo
> Assignee: Guilherme Carreiro
> Priority: Minor
> Labels: drools-tools
> Attachments: type-selector.png
>
>
> The Data Type editor could be improved in terms of productivity and usability.
> Ideally, the user should be able to create a complex type minimizing the mouse usage.
> 1) Saving the node is an overhead for basic data type (e.g. age: number)
> 2) Some actions in the kebab menu should be more visible and available even before saving the type (as standalone icon / buttons). Especially, insert nested, delete.
> 3) Select type in the selector by typing the name of the type (see screenshot): it already works but it consider just the first letter typed. Since, by convention, all custom types starts with `t` letter, it would be better consider at least 2 letters.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-3136) DMN Validation Decision Table Analysis
by Matteo Mortari (Jira)
[ https://issues.jboss.org/browse/DROOLS-3136?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-3136:
-----------------------------------
Description:
· Table completeness (no gaps in the rules)
· Table consistency (overlaps properly handled by hit policy)
· Subsumption (rules that could be combined)
· Rule masking (in P tables where some rule is never the top priority)
· First normal form violation (no hit policy F or O; no duplicate rules)
· Second normal form violation (all inputs relevant to the rule)
· Third normal form violation (all inputs independent)
Added/optionals(?)
· "Misleading rules" in P tables
was:
· Table completeness (no gaps in the rules)
· Table consistency (overlaps properly handled by hit policy)
· Subsumption (rules that could be combined)
· Rule masking (in P tables where some rule is never the top priority)
· First normal form violation (no hit policy F or O; no duplicate rules)
· Second normal form violation (all inputs relevant to the rule)
· Third normal form violation (all inputs independent)
> DMN Validation Decision Table Analysis
> --------------------------------------
>
> Key: DROOLS-3136
> URL: https://issues.jboss.org/browse/DROOLS-3136
> Project: Drools
> Issue Type: Epic
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> · Table completeness (no gaps in the rules)
> · Table consistency (overlaps properly handled by hit policy)
> · Subsumption (rules that could be combined)
> · Rule masking (in P tables where some rule is never the top priority)
> · First normal form violation (no hit policy F or O; no duplicate rules)
> · Second normal form violation (all inputs relevant to the rule)
> · Third normal form violation (all inputs independent)
> Added/optionals(?)
> · "Misleading rules" in P tables
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-3784) Increase the advanced user productivity when he creates a new Data Type
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3784?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3784:
--------------------------------
Tester: Jozef Marko
> Increase the advanced user productivity when he creates a new Data Type
> -----------------------------------------------------------------------
>
> Key: DROOLS-3784
> URL: https://issues.jboss.org/browse/DROOLS-3784
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor
> Affects Versions: 7.18.0.Final
> Reporter: Donato Marrazzo
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Attachments: type-selector.png
>
>
> The Data Type editor could be improved in terms of productivity and usability.
> Ideally, the user should be able to create a complex type minimizing the mouse usage.
> 1) Saving the node is an overhead for basic data type (e.g. age: number)
> 2) Some actions in the kebab menu should be more visible and available even before saving the type (as standalone icon / buttons). Especially, insert nested, delete.
> 3) Select type in the selector by typing the name of the type (see screenshot): it already works but it consider just the first letter typed. Since, by convention, all custom types starts with `t` letter, it would be better consider at least 2 letters.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-3784) Increase the advanced user productivity when he creates a new Data Type
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3784?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3784:
--------------------------------
Labels: drools-tools (was: )
> Increase the advanced user productivity when he creates a new Data Type
> -----------------------------------------------------------------------
>
> Key: DROOLS-3784
> URL: https://issues.jboss.org/browse/DROOLS-3784
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor
> Affects Versions: 7.18.0.Final
> Reporter: Donato Marrazzo
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools
> Attachments: type-selector.png
>
>
> The Data Type editor could be improved in terms of productivity and usability.
> Ideally, the user should be able to create a complex type minimizing the mouse usage.
> 1) Saving the node is an overhead for basic data type (e.g. age: number)
> 2) Some actions in the kebab menu should be more visible and available even before saving the type (as standalone icon / buttons). Especially, insert nested, delete.
> 3) Select type in the selector by typing the name of the type (see screenshot): it already works but it consider just the first letter typed. Since, by convention, all custom types starts with `t` letter, it would be better consider at least 2 letters.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-3784) Increase the advanced user productivity when he creates a new Data Type
by Donato Marrazzo (Jira)
Donato Marrazzo created DROOLS-3784:
---------------------------------------
Summary: Increase the advanced user productivity when he creates a new Data Type
Key: DROOLS-3784
URL: https://issues.jboss.org/browse/DROOLS-3784
Project: Drools
Issue Type: Epic
Components: DMN Editor
Affects Versions: 7.18.0.Final
Reporter: Donato Marrazzo
Assignee: Michael Anstis
Attachments: type-selector.png
The Data Type editor could be improved in terms of productivity and usability.
Ideally, the user should be able to create a complex type minimizing the mouse usage.
1) Saving the node is an overhead for basic data type (e.g. age: number)
2) Some actions in the kebab menu should be more visible and available even before saving the type (as standalone icon / buttons). Especially, insert nested, delete.
3) Select type in the selector by typing the name of the type (see screenshot): it already works but it consider just the first letter typed. Since, by convention, all custom types starts with `t` letter, it would be better consider at least 2 letters.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (DROOLS-3778) Receiving error InvocationTargetException on jdk11
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3778?page=com.atlassian.jira.plugi... ]
Jozef Marko edited comment on DROOLS-3778 at 3/21/19 5:44 AM:
--------------------------------------------------------------
[~jfomin] thank you for reporting this, it can be solved by getting rid of powermockito. The powermockito specific methods can be replaced by using methods from the general mockito library.
was (Author: jomarko):
[~jfomin] thank you for reporting this, it can be solved by getting rid of powermockito.
It means the test that currently mock static methods will change to
{code:java}
@Test
public void testGetHasTypeRefs() {
final Expression expression = mock(Expression.class);
final InformationItem parameter = mock(InformationItem.class);
final HasTypeRef hasTypeRef1 = mock(HasTypeRef.class);
final HasTypeRef hasTypeRef2 = mock(HasTypeRef.class);
final HasTypeRef hasTypeRef3 = mock(HasTypeRef.class);
final HasTypeRef hasTypeRef4 = mock(HasTypeRef.class);
doReturn(expression).when(binding).getExpression();
doReturn(Arrays.asList(hasTypeRef1, hasTypeRef2)).when(expression).getHasTypeRefs();
doReturn(parameter).when(binding).getParameter();
doReturn(Arrays.asList(hasTypeRef3, hasTypeRef4)).when(parameter).getHasTypeRefs();
final List<HasTypeRef> actualHasTypeRefs = binding.getHasTypeRefs();
final List<HasTypeRef> expectedHasTypeRefs = asList(hasTypeRef1, hasTypeRef2, hasTypeRef3, hasTypeRef4);
assertEquals(expectedHasTypeRefs, actualHasTypeRefs);
}
{code}
> Receiving error InvocationTargetException on jdk11
> --------------------------------------------------
>
> Key: DROOLS-3778
> URL: https://issues.jboss.org/browse/DROOLS-3778
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.20.0.Final
> Environment: * jdk11
> * Apache Maven 3.5.4 (Red Hat 3.5.4-4)
> Reporter: Yevgeniy Fomin
> Assignee: Yevgeniy Fomin
> Priority: Major
> Labels: drools-tools, jdk11
> Attachments: Error log powermock.txt
>
>
> There is InvocationTargetException on test classes if they are run on jdk11. The tests can be found in [module|https://github.com/kiegroup/kie-wb-common/tree/master/kie-wb-commo...]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months
[JBoss JIRA] (WFLY-5966) Validate requirement for modules previously exported by javax.ejb.api
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFLY-5966?page=com.atlassian.jira.plugin.... ]
Yeray Borges updated WFLY-5966:
-------------------------------
Description:
The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
{code}
<!-- TODO validate the need for these and remove if not needed.
Prior to WFLY-5922 they were exported by javax.ejb.api. -->
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.xml.rpc.api"/>
<module name="javax.rmi.api"/>
<module name="org.omg.api"/>
{code}
If a module already had a dep on one of those, it's not in the block.
This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
Affected modules:
-feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml
jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml
was:
The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
{code}
<!-- TODO validate the need for these and remove if not needed.
Prior to WFLY-5922 they were exported by javax.ejb.api. -->
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.xml.rpc.api"/>
<module name="javax.rmi.api"/>
<module name="org.omg.api"/>
{code}
If a module already had a dep on one of those, it's not in the block.
This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
Affected modules:
-feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml
-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
-feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml
jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml
jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml
jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml
The following modules were fixed or verified as correct (moved from the first list):
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml
feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml
> Validate requirement for modules previously exported by javax.ejb.api
> ---------------------------------------------------------------------
>
> Key: WFLY-5966
> URL: https://issues.jboss.org/browse/WFLY-5966
> Project: WildFly
> Issue Type: Task
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Yeray Borges
> Priority: Major
>
> The WFLY-5922 fix removed the exporting of a number of modules from javax.ejb.api. That introduced some problems with modules that depended on those exported packages no longer having visibility to needed classes, so to prevent problems I blindly added a commit to the module.xml for each module that depended upon javax.ejb.api to add a dependency set like this:
> {code}
> <!-- TODO validate the need for these and remove if not needed.
> Prior to WFLY-5922 they were exported by javax.ejb.api. -->
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> <module name="javax.xml.rpc.api"/>
> <module name="javax.rmi.api"/>
> <module name="org.omg.api"/>
> {code}
> If a module already had a dep on one of those, it's not in the block.
> This task is to check each of these modules and replace that block with normal dependency declarations for any that are truly needed.
> Affected modules:
> -feature-pack/src/main/resources/modules/system/layers/base/javax/management/j2ee/api/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jsr77/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/webservices/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/weld/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ejb3/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/iiop-client/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/appclient/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/metadata/ejb/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/compensations/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/narayana/txframework/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/weld/core/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/org/jboss/ws/common/main/module.xml
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/xts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/wildfly/extension/rts/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/main/module.xml-
> -feature-pack/src/main/resources/modules/system/layers/base/org/jboss/as/jpa/spi/main/module.xml-
> feature-pack/src/main/resources/modules/system/layers/base/javaee/api/main/module.xml
> The following modules were indirectly affected via their dependency on javaee.api, which in turn exports javax.ejb.api:
> feature-pack/src/main/resources/modules/system/layers/base/org/jberet/jberet-core/main/module.xml
> jsf/multi-jsf-installer/src/main/resources/mojarra-impl-module.xml
> jsf/multi-jsf-installer/src/main/resources/myfaces-impl-module.xml
> feature-pack/src/main/resources/modules/system/layers/base/com/sun/jsf-impl/main/module.xml
> jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/main/module.xml
> jsf/subsystem/src/test/resources/modules/com/sun/jsf-impl/myfaces/module.xml
> jsf/subsystem/src/test/resources/modules2/com/sun/jsf-impl/myfaces2/module.xml
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 3 months