EAR Classloading documentation seems to be in contradiction.

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

EAR Classloading documentation seems to be in contradiction.

Vimal Kansal
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: EAR Classloading documentation seems to be in contradiction.

Jaikiran Pai
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: EAR Classloading documentation seems to be in contradiction.

Vimal Kansal
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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: EAR Classloading documentation seems to be in contradiction.

Jaikiran Pai
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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: EAR Classloading documentation seems to be in contradiction.

Vimal Kansal
Thanks a lot Jaikiran.

Vimal

On 19/07/2011 2:58 PM, 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: EAR Classloading documentation seems to be in contradiction.

Jaikiran Pai
In reply to this post by Jaikiran Pai
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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: EAR Classloading documentation seems to be in contradiction.

Francesco Marchioni
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 <[hidden email]>
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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: EAR Classloading documentation seems to be in contradiction.

Vimal Kansal
In reply to this post by Jaikiran Pai
Thanks a lot Jaikiran. I am going through every single word/line/para of
the documentation and will keep reporting whenever I find something.

On 19/07/2011 5:41 PM, Jaikiran Pai wrote:

> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>> _______________________________________________
>>>> jboss-as7-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: EAR Classloading documentation seems to be in contradiction.

Jaikiran Pai
In reply to this post by Francesco Marchioni
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 <[hidden email] <mailto:[hidden email]>>
>
>     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
>     >>>> [hidden email]
>     <mailto:[hidden email]>
>     >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>     >>> _______________________________________________
>     >>> jboss-as7-dev mailing list
>     >>> [hidden email]
>     <mailto:[hidden email]>
>     >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>     >>
>     >> _______________________________________________
>     >> jboss-as7-dev mailing list
>     >> [hidden email]
>     <mailto:[hidden email]>
>     >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>     >
>     > _______________________________________________
>     > jboss-as7-dev mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>     _______________________________________________
>     jboss-as7-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: EAR Classloading documentation seems to be in contradiction.

Francesco Marchioni
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 <[hidden email]>
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 <[hidden email] <mailto:[hidden email]>>


   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
   >>>> [hidden email]
   <mailto:[hidden email]>

   >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
   >>> _______________________________________________
   >>> jboss-as7-dev mailing list
   >>> [hidden email]
   <mailto:[hidden email]>

   >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
   >>
   >> _______________________________________________
   >> jboss-as7-dev mailing list
   >> [hidden email]
   <mailto:[hidden email]>

   >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
   >
   > _______________________________________________
   > jboss-as7-dev mailing list
   > [hidden email] <mailto:[hidden email]>

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

   _______________________________________________
   jboss-as7-dev mailing list
   [hidden email] <mailto:[hidden email]>



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev