Thanks Jaikiran, unfortunately there seems to be one issue also with the nested <filters> element. In the docs it's mentioned
as <filters>, however in the .xsd it's <filter>

However, testing with <filter> as per .xsd, produces an issue on the <filter> ending tag.

<module name="deployment.mylog4j" >
 
    <resources>
      <resource-root  path="log4j-1.2.16.jar">
          <filter>
          <include path="org/apache/log4j" /> 
        </filter>
      </resource-root>
    </resources>
  </module>

Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[51,9]
Message: Unexpected content of type 'element end' named 'filter'

Regards,
Francesco

2011/7/19 Jaikiran Pai <jpai@redhat.com>
Fixed the example in that document. It should have been <resources> and not <resource-roots>. I also added a reference to the xsd, in that document.

-Jaikiran

On Tuesday 19 July 2011 01:36 PM, Francesco Marchioni wrote:
Hi all !
talking about Classloading docs, I've noticed an issue when defining new deployments with jboss-deployment-structure.xml.

For example: I'm re-exporting the org.apache.log4j container module into a new module (deployment.mylog4j) excluding the package org/apache/log4j/chainsaw which is loaded somewhere else through a dependency.

<module name="deployment.mylog4j" >
<resource-roots>
<resource-root path="log4j-1.2.16.jar" >
<filters>
<exclude path="org/apache/log4j/chainsaw" />
</filters>
</resource-root>
</resource-roots>
</module>

The AS reports:

eam.XMLStreamException: ParseError at [row,col]:[34,5]
Message: Unexpected content of type 'element start' named 'resource-roots'
       at org.jboss.as.server.deployment.module.DeploymentStructureDescriptorParser.unexpectedContent(DeploymentStructureDescriptorParser.java:483)
       at org.jboss.as.server.deployment.module.DeploymentStructureDescriptorParser.parseModuleStructureSpec(DeploymentStructureDescriptorParser.java:695)
       at org.jboss.as.server.deployment.module.DeploymentStructureDescriptorParser.parseModule(DeploymentStructureDescriptorParser.java:660)
       at org.jboss.as.server.deployment.module.DeploymentStructureDescriptorParser.parseStructureContents(DeploymentStructureDescriptorParser.java:581)
       at org.jboss.as.server.deployment.module.DeploymentStructureDescriptorParser.parseDocument(DeploymentStructureDescriptorParser.java:510)
       at org.jboss.as.server.deployment.module.DeploymentStructureDescriptorParser.parse(DeploymentStructureDescriptorParser.java:396)


Is it an issue with documentation or with .xsd ??
Thanks
kind regards
Francesco
2011/7/19 Jaikiran Pai <jpai@redhat.com <mailto:jpai@redhat.com>>


   The document has been updated
   https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7 .
   Thanks
   for pointing out the discrepancy and let us know if there are any more
   changes that you would like to see.

   -Jaikiran
   On Tuesday 19 July 2011 10:28 AM, Jaikiran Pai wrote:
   > Sure, will do.
   >
   > -Jaikiran
   > On Tuesday 19 July 2011 10:25 AM, Vimal Kansal wrote:
   >> Thanks a lot Jaikiran. Also can you please
   elaborating/rephrasing the
   >> content in doco using the descriprion from .xsd, I think the
   one in .xsd
   >> is more clear.
   >>
   >> On 19/07/2011 2:47 PM, Jaikiran Pai wrote:
   >>> That looks like a typo in that Classloading doc. The
   jboss-ee.xsd is
   >>> correct. I'll fix the doc later today when I've fully woken up.
   >>>
   >>> -Jaikiran
   >>> On Tuesday 19 July 2011 10:11 AM, Vimal Kansal wrote:
   >>>> Hi,
   >>>>
   >>>> It appears that EAR classloading documentation at
   >>>>
   https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7 is in
   >>>> contradiction with what "jboss-ee.xsd describes :
   >>>>
   >>>> AS7 Doc version
   >>>> ==============
   >>>>
   >>>> <subsystem xmlns="urn:jboss:domain:ee:1.0">
   >>>> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
   >>>> </subsystem>
   >>>>
   >>>> By default this is set to true, which means that sub
   deployments will be
   >>>> able to see other non-war sub-deployments classes by default
   (i.e. a war
   >>>> deployment's module will have a dependency on all other ejb-jar
   >>>> sub-deployments, however it will not have a module dependency
   on any
   >>>> other war deployments).
   >>>>
   >>>> If this is set to false then no automatic dependencies are
   set up, they
   >>>> must be setup manually with Class-Path entries, or by setting up
   >>>> explicit module dependencies. This means that WARs (and other
   EJB jars)
   >>>> do not have access to classes defined in an EJB jar unless an
   explicit
   >>>> dependency is defined. The Java EE specification says that
   portable
   >>>> applications should not rely on sub deployments having access
   to other
   >>>> sub deployments that they do not have a Class-Path entry on,
   so portable
   >>>> applications should always use Class-Path entry's to
   explicitly state
   >>>> their dependencies.
   >>>>
   >>>> jboss-ee.xsd version
   >>>> ==================
   >>>> Flag indicating whether each of the subdeployments within a
   .ear can
   >>>> access classes belonging to
   >>>>                          another subdeployment within the
   same .ear. Setting
   >>>> this to false, allows the subdeployments to
   >>>>                          see classes belonging to other
   subdeployments
   >>>> within the .ear.
   >>>>                          For example:
   >>>>                          myapp.ear
   >>>>                           |
   >>>>                           |--- web.war
   >>>>                           |
   >>>>                           |--- ejb1.jar
   >>>>                           |
   >>>>                           |--- ejb2.jar
   >>>>
   >>>>                          If the ear-subdeployments-isolated
   is set to false,
   >>>> then the classes in web.war can access classes
   >>>>                          belonging to ejb1.jar and ejb2.jar.
   Similarly,
   >>>> classes from ejb1.jar can access classes from ejb2.jar
   >>>>                          (and vice-versa).
   >>>>
   >>>>                          *Note that this flag, has no effect
   on the isolated
   >>>> classloader of the .war file(s). i.e. irrespective
   >>>>                          of whether this flag is set to true
   or false, the
   >>>> .war within a .ear will have a isolated classloader
   >>>>                          and other subdeployments within that
   .ear will not
   >>>> be able to access classes from that .war. This is
   >>>>                          as per spec*
   >>>>
   >>>> Thx
   >>>>
   >>>> Vimal
   >>>>
   >>>> _______________________________________________
   >>>> jboss-as7-dev mailing list
   >>>> jboss-as7-dev@lists.jboss.org
   <mailto:jboss-as7-dev@lists.jboss.org>

   >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
   >>> _______________________________________________
   >>> jboss-as7-dev mailing list
   >>> jboss-as7-dev@lists.jboss.org
   <mailto:jboss-as7-dev@lists.jboss.org>

   >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
   >>
   >> _______________________________________________
   >> jboss-as7-dev mailing list
   >> jboss-as7-dev@lists.jboss.org
   <mailto:jboss-as7-dev@lists.jboss.org>

   >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
   >
   > _______________________________________________
   > jboss-as7-dev mailing list
   > jboss-as7-dev@lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>

   > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

   _______________________________________________
   jboss-as7-dev mailing list
   jboss-as7-dev@lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>