Re: [jboss-as7-dev] deploying a war - jboss-classloading.xml
On 4/13/11 9:40 PM, denstar wrote:
On Wed, Apr 13, 2011 at 6:44 PM, Jason T. Greene wrote:
> On 4/13/11 4:19 PM, David M. Lloyd wrote:
>> Responses inline.
>>
>> On 04/13/2011 03:41 PM, denstar wrote:
>>> Hi Folks!
>>>
>>> With AS5 I'd put something like this:
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <classloading xmlns="urn:jboss:classloading:1.0"
name="cfdistro"
>>> domain="DefaultDomain" export-all="NON_EMPTY"
import-all="true">
>>> </classloading>
>>>
>>> into WEB-INF/jboss-classloading.xml
>
> On AS5/6 that eliminates war isolation.
>
Kinda makes sense then, I guess. In weird side effect land. :)
More likely, I have classloading -- this thing I've worked with for
years now (with many a classloader walk) -- ill conceptualized. It
would not surprise me in the least. :)
(I add an emoticon, but I'm dead serious :])
Isolating something that's designed not to be isolated is never
pretty, I'd posit. And thus dependency management! Heh.
At any rate, it's basically the same list of jars I have to delete
now, that I had to delete when I first got things going with AS5
(before I found out about jboss-classloading.xml). I'm pretty sure
AS6 worked like 5 as far as having jboss-classloading.xml work it's
magic.
What was likely happening is that the default domain was preferring the
JDK API classes from the JVM vs the ones in your war. WARs are
effectively child first so if you include JDK API classes, they will be
proffered to the JVM, which will lead to clashes.
For this reason, in the past we filtered some (but not all API classes)
to prevent the common error. In 7 we have been planning to automatically
filter all spec classes by default. Although there are legitimate cases
to not filter (e.g. a war includes its own NEWER version of JSF).
Although at the moment we don't filter anything.
--
Jason T. Greene
JBoss, a division of Red Hat