10 Replies Latest reply on Dec 1, 2016 6:27 PM by juan_a_velez

Two modules can not see META-INF content of each other

robertobeeman Jul 16, 2013 3:43 AM

HI All,

I have a scenario where I want have created a Spring module (Which works properly) the spring module is as following:

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.springframework.spring" slot="main">
  <resources>
    <resource-root path="spring-aop-3.0.6.RELEASE.jar"/>
    <resource-root path="spring-asm-3.0.6.RELEASE.jar"/>
    <resource-root path="spring-beans-3.0.6.RELEASE.jar"/>
    <resource-root path="spring-context-3.0.6.RELEASE.jar">
            <filter>
                <include path="META-INF**" />
                <include path="org**" />
            </filter>
        </resource-root>
    <resource-root path="spring-context-support-3.0.6.RELEASE.jar">
            <filter>
                <include path="META-INF**" />
                <include path="org**" />
            </filter>
        </resource-root>
    <resource-root path="spring-core-3.0.6.RELEASE.jar"/>
    <resource-root path="spring-expression-3.0.6.RELEASE.jar"/>
    <resource-root path="spring-jdbc-3.0.6.RELEASE.jar"/>
    <resource-root path="spring-jms-3.0.6.RELEASE.jar"/>
    <resource-root path="spring-oxm-3.0.6.RELEASE.jar"/>
    <resource-root path="spring-test-3.0.6.RELEASE.jar"/>
    <resource-root path="spring-tx-3.0.6.RELEASE.jar"/>
    <resource-root path="spring-web-3.0.6.RELEASE.jar"/>
    <resource-root path="spring-webmvc-3.0.6.RELEASE.jar"/>
  </resources>
  <dependencies>
         <module name="org.apache.commons.logging"/>
         <module name="javax.api" export="true"/>
           <module name="javax.servlet.api" export="true"/>
           <module name="com.sun.xml.bind" export="true"/>
         <module name="org.jboss.vfs"/> 
           <module name="javax.el.api" export="true"/>
  </dependencies>
</module>

- The Spring based Application can access this properly using the following kind of "WEB-INF/jboss-deployment-structure.xml"

<jboss-deployment-structure>
          <deployment>
              <dependencies>
                    <module name="org.springframework.spring" slot="main" export="true" meta-inf="export"/>
              </dependencies>
          </deployment>
</jboss-deployment-structure>

So far everything is Good if the above configuration is used....

Now the problemetic Scenario:

========================

Now if i create a custom module "test" as following (Which simply refers to the "" module as following:)

<module xmlns="urn:jboss:module:1.1" name="test" slot="main">
    <dependencies>
            <module name="org.springframework.spring" slot="main" export="true"/>
    </dependencies>
</module>

And then if my spring based application refers to the module "test" using the "WEB-INF/jboss-deployment-structure.xml" file then it throws exception while initializing the spring context:

<jboss-deployment-structure>
          <deployment>
               <dependencies>
                      <module name="test" slot="main" export="true" meta-inf="export"/>
                </dependencies>
          </deployment>
</jboss-deployment-structure>

Now at the time of application deployment we see the following exception:

12:48:50,150 ERROR [org.springframework.web.context.ContextLoader] (ServerService Thread Pool -- 53) Context initialization failed: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/context]
Offending resource: ServletContext resource [/WEB-INF/testSpringContext.xml]

          at org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:80) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.error(BeanDefinitionParserDelegate.java:284) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1335) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:124) [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:93) [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130) [spring-context-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:467) [spring-context-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:397) [spring-context-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:282) [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:204) [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47) [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
          at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
          at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
          at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
          at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
          at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
          at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
          at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
          at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
          at org.jboss.threads.JBossThread.run(JBossThread.java:122)


12:48:50,163 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/DemoJSF]] (ServerService Thread Pool -- 53) JBWEB000287: Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/context]
Offending resource: ServletContext resource [/WEB-INF/testSpringContext.xml]

          at org.springframework.beans.factory.parsing.FailFastProblemReporter.error(FailFastProblemReporter.java:68) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:85) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.parsing.ReaderContext.error(ReaderContext.java:80) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.error(BeanDefinitionParserDelegate.java:284) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1335) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:334) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:302) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:143) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:178) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.beans.factory.support.AbstractBeanDefinitionReader.loadBeanDefinitions(AbstractBeanDefinitionReader.java:149) [spring-beans-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:124) [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.web.context.support.XmlWebApplicationContext.loadBeanDefinitions(XmlWebApplicationContext.java:93) [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:130) [spring-context-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:467) [spring-context-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:397) [spring-context-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:282) [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:204) [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47) [spring-web-3.0.6.RELEASE.jar:3.0.6.RELEASE]
          at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
          at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
          at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
          at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
          at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
          at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
          at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
          at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
          at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
          at org.jboss.threads.JBossThread.run(JBossThread.java:122)

Which indicates that One module's "META-INF" contents are not exported to another module iun JBoss AS7.2....

Is that the expected behaviour ?

Usecase:

=======

Suppose if some one has 10 different modules and if he wants to add only one consolidates module (which includes the dependencies to those 10 different modules) then it is better to add only that single consolidated module inside the "jboss-deployment-structure.xml" which will make the application maintenance easier.

1. Re: Two modules can not see META-INF content of each other

dmlloyd Jul 16, 2013 9:37 AM (in response to robertobeeman)

Modules will always export all paths by default - however they will currently not import the META-INF path without a special filter on the import. Inside the dependency element whose META-INF you want to bring in, add a <imports> section, and include an import for the META-INF path.

In terms of your use case - it is possible do create something which we informally call an "aggregate module", which simply imports and re-exports a set of other modules and does not contain any resources of its own. In the WildFly distribution we prefer this approach because it allows us to isolate each JAR in a component set, which in turn lets us do things like substitute dependencies for specific components. The "javaee.api" module is one example.
Actions
2. Re: Two modules can not see META-INF content of each other

robertobeeman Jul 16, 2013 11:04 AM (in response to dmlloyd)

Hi David,

     I am using JBossAS 7.2 and already tried using <filter> <include> poption as following inside the module.xml file:

        <resource-root path="spring-context-3.0.6.RELEASE.jar">             <filter>                 <include path="META-INF**" />                 <include path="org**" />             </filter>         </resource-root>

     I also tried using the filters inside the "jboss-deployment-structure.xml" as following still i am getting the same exception: (Notice: the custom module "test" is already including the sepring dependencies in it)
<jboss-deployment-structure>
       <deployment>
             <dependencies>
                     <module name="test" slot="main" export="true" meta-inf="export" >
                           <imports>
                               <include path="META-INF**" />
                               <include path="org**" />
                           </imports>
                      </module>
                </dependencies>
          </deployment>
</jboss-deployment-structure>

But if i use the Spring dependency directly then it works as following:

<jboss-deployment-structure>
       <deployment>
             <dependencies>
                       <module name="org.springframework" slot="main" export="true" meta-inf="export">
                           <imports>
                               <include path="META-INF**" />
                               <include path="org**" />
                           </imports>
                      </module>
                      <module name="org.springframework.spring-context" slot="main" export="true" meta-inf="export">
                           <imports>
                               <include path="META-INF**" />
                               <include path="org**" />
                           </imports>
                      </module>
                </dependencies>
       </deployment>
</jboss-deployment-structure>

So is there a way that using custom module "test" only my spring based application can access the META-INF** informations via "aggregate module"
Actions
3. Re: Two modules can not see META-INF content of each other

dmlloyd Jul 16, 2013 11:31 AM (in response to robertobeeman)

Your <include> filter syntax is invalid. Your path should be "META-INF/**" (you can leave off "org/**" because it will already be included). Also, "slot" is optional, and you should not "export" unless you want importers of your module to get everything you import as well (you can filter down the exports using <exports> if you want to only export some things).
Actions

4. Re: Two modules can not see META-INF content of each other

robertobeeman Jul 16, 2013 10:19 PM (in response to dmlloyd)

Hi David,

Thank you again for your help.

Actually i want to add only the "test" module (Which is just an "aggregate module") inside my "WEB-INF/jboss-deployment-structure.xml" as my test module contains some additional module dependencies like following:

<module xmlns="urn:jboss:module:1.1" name="test" slot="main"> <dependencies> <module name="org.springframework.spring" export="true"/>
<module name="aaa.bbb" /> <module name="ccc.ddd"/> <module name="eee.fff"/> <module name="ggg.hhh"/> </dependencies> </module>

So in this case I am facing the problem that even if i am using the META-INF/** import on Spring module "org.springframework.spring" as mentioned in my previous comment ... still the Web Application is not able to access the META-INF info from the spring module .... Via "test" module using "jboss-deployment-structure.xml"

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.springframework.spring" slot="main">
  <resources>
        <resource-root path="spring-aop-3.0.6.RELEASE.jar"/>
        <resource-root path="spring-asm-3.0.6.RELEASE.jar"/>
        <resource-root path="spring-beans-3.0.6.RELEASE.jar"/>
        <resource-root path="spring-context-3.0.6.RELEASE.jar">
            <filter>
                <include path="META-INF/**" />
                <include path="org/**" />
            </filter>
        </resource-root>
        <resource-root path="spring-context-support-3.0.6.RELEASE.jar">
            <filter>
                <include path="META-INF/**" />
                <include path="org/**" />
            </filter>
        </resource-root>
                .
                .

                .

                .
  <dependencies>
           <module name="org.apache.commons.logging"/>
           <module name="javax.api" export="true"/>
           <module name="javax.servlet.api" export="true"/>
           <module name="com.sun.xml.bind" export="true"/>
           <module name="org.jboss.vfs"/> 
           <module name="javax.el.api" export="true"/>
  </dependencies>
</module>

Question: In the above scenario Is it possible to accesss the "META-INF/**" resources of "org.springframework.spring" module from the aggrigator module "test" ? Means I just want to add the <dependencies> to "test" module from my webApplication using "WEB-INF/jboss-deployment-structure.xml" inside my WebApplication. (I Do not want to add the "org.springframework.spring" module separately inside the dependencies section in my WEB-INF/jboss-deployment-structure.xml)

<jboss-deployment-structure>
          <deployment>
               <dependencies>
                      <module name="test" slot="main" meta-inf="export"/>
                </dependencies>
          </deployment>
</jboss-deployment-structure>

I Know the workaround is to use the "WEB-INF/jboss-deployment-structure.xml" as folllowing (Which works for me, BUT i want to add only dependencies to "test" module as mentioned above and still want to achieve the same.. Is that possible)

<jboss-deployment-structure>
       <deployment>
             <dependencies>
                       <module name="org.springframework.spring" slot="main" meta-inf="export">
                           <imports>
                               <include path="META-INF/**" />
                           </imports>
                      </module>
                </dependencies>
       </deployment>
</jboss-deployment-structure>

5. Re: Two modules can not see META-INF content of each other

dmlloyd Jul 17, 2013 10:32 PM (in response to robertobeeman)
The rules are simple:
By default <resource-root> imports everything, so unless you want to add an <exclude>, do not filter it.
By default <dependencies> imports everything *except* for META-INF and its child paths, and exports nothing. If you want META-INF you have to explicitly include it; if you want to export the dependency you must also explicitly do so. Use export="true" and meta-inf="export" on each <module> tag. You should not need any nested filters for this case.
Actions
6. Re: Two modules can not see META-INF content of each other

jaikiran Jul 19, 2013 10:38 AM (in response to dmlloyd)
Like David says, the algorithm/rules are really simple. You don't need filters for what you are trying to achieve and from what you have posted here, you are missing an important thing in the module.xml of the custom module. You should have:

The module.xml of custom module:

<module xmlns="urn:jboss:module:1.1" name="custom" slot="main"> <dependencies> <module name="org.springframework.spring" slot="main" export="true" meta-inf="export"/> </dependencies> </module>

(notice that I've added meta-inf="export" in there)

The jboss-deployment-structure.xml of the application:

<jboss-deployment-structure> <deployment> <dependencies> <module name="custom" slot="main" export="true" meta-inf="export"/> <dependencies> </deployment> </jboss-deployment-structure>

(this one too needs the meta-inf="export")
Actions
7. Re: Two modules can not see META-INF content of each other

slrslr Sep 4, 2013 12:06 PM (in response to jaikiran)

The meta-inf="export" is not an option supported in the module.xml file. The filters must be used. See :
Module descriptors - JBoss Modules - Project Documentation Editor
Actions
8. Re: Two modules can not see META-INF content of each other

anshumanpurohit Dec 12, 2013 1:44 PM (in response to dmlloyd)

David - In your previous post (Dt: Jul 16) you mentioned "Modules will always export all paths by default". Can you please elaborate? Thanks.
Actions
9. Re: Two modules can not see META-INF content of each other

dmlloyd Dec 12, 2013 9:01 PM (in response to anshumanpurohit)

Sure. There are two parts in this statement. First, by "all paths", I'm referring to the linkage algorithm in JBoss Modules which operates on a granularity of directory paths (or packages, which are functionally equivalent to directory paths). Secondly, in a module dependency relationship there are two participants: the dependency (which exports) and the dependent (which imports). The export side by default includes all paths always unless overridden with a different policy (this is what I mean by "export all paths by default"). The import side by default excludes "META-INF" and its subdirectories unless overridden with a different policy.

Hope this clarifies things.
Actions
10. Re: Two modules can not see META-INF content of each other

juan_a_velez Dec 1, 2016 6:27 PM (in response to dmlloyd)
Please help me understand the following: I have an ear (my.ear). Within that ear I have two sub-deployments: a.jar and b.war.

Also, a.jar has a dependency on dynamic module c:

<module xmlns="urn:jboss:module:1.1" name="c" slot="main"> <resources>     <resource-root path="third-party.jar"/> </resources> </module>

Since both a.jar and b.war depend on module c, I have added a jboss-deployement-descriptor.xml

<jboss-deployment-structure> <deployment>     <dependencies>       <module name="c" slot="main"/>     <dependencies> </deployment> </jboss-deployment-structure>

You have said that all paths are exported by default. How come that neither a.jar nor b.war can see the classes on third.party unless in the dependnecies section the module has export="true".

Also I have another issue where module d which a.jar and b.war also depend upon:

<module xmlns="urn:jboss:module:1.1" name="d" slot="main"> <resources>     <resource-root path="application.properties"/> </resources> </module>

but in this case

<jboss-deployment-structure> <deployment>     <dependencies>       <module name="d" slot="main"/>     <dependencies> </deployment> </jboss-deployment-structure>

a.jar and b.war can indeed see application.properties w/o the export="true" set on the module declaration for the dependencies.
Actions

Go to original post