[
https://issues.jboss.org/browse/WFLY-962?page=com.atlassian.jira.plugin.s...
]
Stuart Douglas resolved WFLY-962.
---------------------------------
Resolution: Won't Fix
The underlying cause of this issue is that exclusions will not exclude a module if it is
not a direct dependency but is instead being exported from another module.
Unfortunatly the amount of engineering effort required to fix this is significant, and
would require fairly invasive changes to how jboss-modules works, and as such I can't
see this getting fixed any time soon.
In Wildfly this will be less of an issue, as we are trying to reduce the usage of exported
dependencies.
Unable to combine Resource Archive (RAR) <dependencies> and
<exclusions> directives in jboss-deployment-structure.xml without <exclusions>
being ignored
--------------------------------------------------------------------------------------------------------------------------------------------------------
Key: WFLY-962
URL:
https://issues.jboss.org/browse/WFLY-962
Project: WildFly
Issue Type: Bug
Components: Class Loading
Environment: Linux (CentOS 6.3), JDK 1.6.0_37
Reporter: Matthew White
Assignee: Stuart Douglas
Attachments: jbossas-bugexample.zip
I have an EAR file where for a WAR sub-deployment I want to declare a startup dependency
on another Resource Archive (RAR) deployment (in my application's case, the WebSphere
MQ RAR - but I have recreated this with other Resource Archives) and also have a module
exclusion (in this case, on the org.apache.log4j module so that my application can use
internally defined Log4J configuration).
The jboss-deployment-structure.xml for the EAR looks like this :-
{code:xml}
<jboss-deployment-structure>
<sub-deployment name="application.war">
<dependencies>
<module name="deployment.wmq.jmsra.rar" />
</dependencies>
<exclusions>
<module name="org.apache.log4j" />
</exclusions>
</sub-deployment>
</jboss-deployment-structure>
{code}
When I startup the EAR, the <dependencies> directive for the sub-deployment takes
effect - the WAR is not started until the WebSphere MQ RAR is available. However, my
<exclusions> directive is ignored and the application Log4J configuration is not
used.
If I restructure the jboss-deployment-structure.xml and remove the <dependencies>
directive from the sub-deployment :-
{code:xml}
<jboss-deployment-structure>
<sub-deployment name="application.war">
<exclusions>
<module name="org.apache.log4j" />
</exclusions>
</sub-deployment>
</jboss-deployment-structure>
{code}
The <exclusions> directive is interpreted correctly and the application Log4J
configuration is used.
Also, if I go the other way and remove the <exclusions> directive and put the the
<dependencies> directive back :-
{code:xml}
<jboss-deployment-structure>
<sub-deployment name="application.war">
<dependencies>
<module name="deployment.wmq.jmsra.rar" />
</dependencies>
</sub-deployment>
</jboss-deployment-structure>
{code}
The <dependencies> continues to be interpreted correctly and the WAR does not start
until the dependency is available.
It would just seem that I can't combine the two directives and have them both be
interpreted correctly. I have tried changing the order of defining them in the file but
that (unsurprisingly) didn't make a lot of difference.
I have also tried this with the dependency being any other type of deployment - EAR, WAR,
JAR, etc - and in those cases everything works correctly. It seems to only be an issue if
the dependency is a Resource Archive.
I've also given it a go on a recent 7.2.0 Nightly (3 Jan 2013) and it is also
exhibiting the same behaviour.
I have attached a sample application to replicate this behaviour. It uses the Apache
Jackrabbit RAR (since the WebSphere MQ one is not distributable) as the Resource Archive
dependency and creates 2 EAR files that are trying to use log4j to log to a file - one
with just the <exclusions> directive and one with both the <dependencies> and
<exclusions> directives. See the README file in the zip for more details.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira