[jboss-as7-dev] EAR Classloading documentation seems to be in contradiction.
Francesco Marchioni
marchioni.francesco at gmail.com
Tue Jul 19 09:29:07 EDT 2011
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 at 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 at redhat.com <mailto:jpai at redhat.com>>
>>
>>
>> The document has been updated
>> https://docs.jboss.org/author/**display/AS7/Class+Loading+in+**AS7<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<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 at lists.jboss.org
>> <mailto:jboss-as7-dev at lists.**jboss.org<jboss-as7-dev at lists.jboss.org>
>> >
>>
>> >>>> https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>> >>> ______________________________**_________________
>> >>> jboss-as7-dev mailing list
>> >>> jboss-as7-dev at lists.jboss.org
>> <mailto:jboss-as7-dev at lists.**jboss.org<jboss-as7-dev at lists.jboss.org>
>> >
>>
>> >>> https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>> >>
>> >> ______________________________**_________________
>> >> jboss-as7-dev mailing list
>> >> jboss-as7-dev at lists.jboss.org
>> <mailto:jboss-as7-dev at lists.**jboss.org<jboss-as7-dev at lists.jboss.org>
>> >
>>
>> >> https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>> >
>> > ______________________________**_________________
>> > jboss-as7-dev mailing list
>> > jboss-as7-dev at lists.jboss.org <mailto:jboss-as7-dev at lists.**
>> jboss.org <jboss-as7-dev at lists.jboss.org>>
>>
>> > https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>>
>> ______________________________**_________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org <mailto:jboss-as7-dev at lists.**jboss.org<jboss-as7-dev at lists.jboss.org>
>> >
>>
>> https://lists.jboss.org/**mailman/listinfo/jboss-as7-dev<https://lists.jboss.org/mailman/listinfo/jboss-as7-dev>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-as7-dev/attachments/20110719/9e5e7b1b/attachment.html
More information about the jboss-as7-dev
mailing list