11:41 p.m.
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
11:47 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
11:55 p.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
11:58 p.m.
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12:03 a.m.
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
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
2:41 a.m.
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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
3:06 a.m.
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(a)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(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
6:29 a.m.
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(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org <mailto:jboss-as7-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
8:29 a.m.
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(a)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.**
> DeploymentStructureDescriptorP**arser.unexpectedContent(**
> DeploymentStructureDescriptorP**arser.java:483)
> at org.jboss.as.server.**deployment.module.**
> DeploymentStructureDescriptorP**arser.**parseModuleStructureSpec(**
> DeploymentStructureDescriptorP**arser.java:695)
> at org.jboss.as.server.**deployment.module.**
> DeploymentStructureDescriptorP**arser.parseModule(**
> DeploymentStructureDescriptorP**arser.java:660)
> at org.jboss.as.server.**deployment.module.**
> DeploymentStructureDescriptorP**arser.parseStructureContents(**
> DeploymentStructureDescriptorP**arser.java:581)
> at org.jboss.as.server.**deployment.module.**
> DeploymentStructureDescriptorP**arser.parseDocument(**
> DeploymentStructureDescriptorP**arser.java:510)
> at org.jboss.as.server.**deployment.module.**
> DeploymentStructureDescriptorP**arser.parse(**
> DeploymentStructureDescriptorP**arser.java:396)
>
>
> Is it an issue with documentation or with .xsd ??
> Thanks
> kind regards
> Francesco
> 2011/7/19 Jaikiran Pai <jpai(a)redhat.com <mailto:jpai@redhat.com>>
>
>
> The document has been updated
>
https://docs.jboss.org/author/**display/AS7/Class+Loading+in+**AS7<htt...;.
> 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<htt...
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(a)lists.jboss.org
> <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev@lists.jboss.org>
> >
>
> >>>>
https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists...
> >>> ______________________________**_________________
> >>> jboss-as7-dev mailing list
> >>> jboss-as7-dev(a)lists.jboss.org
> <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev@lists.jboss.org>
> >
>
> >>>
https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists...
> >>
> >> ______________________________**_________________
> >> jboss-as7-dev mailing list
> >> jboss-as7-dev(a)lists.jboss.org
> <mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev@lists.jboss.org>
> >
>
> >>
https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists...
> >
> > ______________________________**_________________
> > jboss-as7-dev mailing list
> > jboss-as7-dev(a)lists.jboss.org <mailto:jboss-as7-dev@lists.**
> jboss.org <jboss-as7-dev(a)lists.jboss.org>>
>
> >
https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists...
>
> ______________________________**_________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
<mailto:jboss-as7-dev@lists.**jboss.org<jboss-as7-dev@lists.jboss.org>
> >
>
>
https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists...
>
>
>
4:05 a.m.
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
>>>> jboss-as7-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
5268
days inactive
5268
days old
9 comments
3 participants
participants (3)
-
Francesco Marchioni -
Jaikiran Pai -
Vimal Kansal