It is really more theoretical question, but I would like to hear what is
websphere people opinion of this.
It seems to me that there is a lot of classloader questions on this news
group. It started(for me) with WAS 3.5 and versions of xerces.jar. Now it's
the same with apache commons and jdom.
My opinion is that this classloader confusion could be simplified if
application couldn't use(see) any of websphere internal jars.

Is there a way to achieve something like that in WAS?
So the question is, do I really want to use exactly same jars as
websphere(commons, log4j, jdom)?
What are the benefits of this approach?

[ Post a follow-up to this message ]

If your application can't use any of the websphere "internal" jars, it would
not run. All the J2EE APIs and implementations are "internal jars", your
app. won't be able to use J2EE.  We have our share of classloading issues
from ver. 3.5 to 5.1.  The WAS classloading architecture has created
problems for folks like me but not using the "internal" jars is not even
remotely possible at least for us.  The problems we encountered can be
summarized into two areas:  interactions between wars, jars (including
ejbjars);  the other is the limitation of the classloading architecture.
Your problem can be resolved by putting the reference jars like commons,
log4j, etc. in the deployment ear, make sure your application's manifest
points to those jars.  So the EAR or WAR classloader will always resolve to
those jars first before letting the parent classloaders, which sees the
"internal" jars resolve the classses.  Example, Websphere uses one version
of xerces, we use another, there is absolutely no conflict because we
include our version of xerces in the ear.  The limitaion of classloading
architecture is more difficult to solve, consider this, JAF (java activation
framework) is in one of those "internal" jars,  but the handlers
(implemented by us) are in our EAR.  The higher level classes which loads
JAF can't invoke(see) the implementation handlers loaded by the EAR loader,
which defeats the purpose of JAF.  The quick solution is to put the handlers
in the same classpath as JAF, it's an ugly solution and not always feasible,
we ended up moving the JAF to the EAR.

If you go to Websphere's InfoCenter and search for classloader you will find
good explanation of WAS classloaders.  Hopefully this will put you on the
right footing, good luck!

Jun



"Ian" <ianeruda_rem_this@yahoo.com> wrote in message
news:1fg58l2uv0o33.10e2w1gr9tedv$.dlg@40tude.net...
> It is really more theoretical question, but I would like to hear what is
> websphere people opinion of this.
> It seems to me that there is a lot of classloader questions on this news
> group. It started(for me) with WAS 3.5 and versions of xerces.jar. Now
it's
> the same with apache commons and jdom.
> My opinion is that this classloader confusion could be simplified if
> application couldn't use(see) any of websphere internal jars.
>
> Is there a way to achieve something like that in WAS?
> So the question is, do I really want to use exactly same jars as
> websphere(commons, log4j, jdom)?
> What are the benefits of this approach?
>

[ Post a follow-up to this message ]

On Thu, 16 Dec 2004 20:14:17 -0500, Jun wrote:
>
> "Ian" <ianeruda_rem_this@yahoo.com> wrote in message
> news:1fg58l2uv0o33.10e2w1gr9tedv$.dlg@40tude.net... 
> it's 

[vbcol=seagreen]
> If your application can't use any of the websphere "internal" jars, it wou
ld
> not run. All the J2EE APIs and implementations are "internal jars", your
> app. won't be able to use J2EE.
Jun, thank you for your reply.
J2EE jars are one thing and commons and jdom are another. Of course that I
need J2EE jars in classpath. Other approach would create problems. But I
don't need JDOM jar in my classpath. I solved my problems with
classloaders, but I can see that lot of people still ask a lot of question
about this. I think that WAS should at least have some smart defaults in
this matter.

Example:
I have an war/ear with jdom.jar in it. If I deploy it in WAS my application
and don't change defaults, application will use WAS jdom.jar. Well, this
isn't smart default. And I think Java default classloader behaviour isn't
good enough reason for this.
What will happen if I deploy it in app server that doesn't use jdom
internally. Than the same application will use jdom deployed with war/ear.
And I still can't see any benefits of this classloading approach.

So, I'm talking about concept, and not about WAS Info center.

[ Post a follow-up to this message ]

> Example:
> I have an war/ear with jdom.jar in it. If I deploy it in WAS my
application
> and don't change defaults, application will use WAS jdom.jar. Well, this
> isn't smart default. And I think Java default classloader behaviour isn't
> good enough reason for this.

Actually the default classloading behavior is opposite of what you
described.  WAS' classloading tree looks like this:

simplified version:
System loaders (top, parent of app. loaders)
|
|
application loader(s) (2nd, parent of war loaders)
|
|
WAR loader(s) (3rd)

The system loaders load WAS jdom.jar, the application loader loads your EAR
with your jdom.jar in it, then the WAR loader loads Web-inf/classes and
web-inf/lib.  Remember the parent loader(s) can't see the classes in the
child loaders but the child loaders can see the classes in all the parent
loaders.  Assume you have a WAR application deployed, the way the
classloading works is the WAR loader would first look at its classpath to
load the jdom class, if the jdom class can't be found, it would let the
application classloader resolve the class, if application loader can't load
the class in its classpath then as the last resort the system loaders would
resolve the jdom class.  As you can see if the jdom.jar is either in
web-inf/lib or the ear itself, your application will always, by default, use
that jdom.jar and the WAS jdom.jar will never be used in your application.

WAS info center explains what I mentioned in the previous paragraph in far
greater details.  Hope this helps.

Jun

"Ian" <ianeruda_rem_this@yahoo.com> wrote in message
news:14vmf0ovwym05$.1bckw4ualm8l0.dlg@40tude.net...
> On Thu, 16 Dec 2004 20:14:17 -0500, Jun wrote: 
is[vbcol=seagreen] 
news[vbcol=seagreen] 
>
> 
would[vbcol=seagreen] 
> Jun, thank you for your reply.
> J2EE jars are one thing and commons and jdom are another. Of course that I
> need J2EE jars in classpath. Other approach would create problems. But I
> don't need JDOM jar in my classpath. I solved my problems with
> classloaders, but I can see that lot of people still ask a lot of question
> about this. I think that WAS should at least have some smart defaults in
> this matter.
>
> Example:
> I have an war/ear with jdom.jar in it. If I deploy it in WAS my
application
> and don't change defaults, application will use WAS jdom.jar. Well, this
> isn't smart default. And I think Java default classloader behaviour isn't
> good enough reason for this.
> What will happen if I deploy it in app server that doesn't use jdom
> internally. Than the same application will use jdom deployed with war/ear.
> And I still can't see any benefits of this classloading approach.
>
> So, I'm talking about concept, and not about WAS Info center.

[ Post a follow-up to this message ]

Jun wrote:
> 
> application 
>
> Actually the default classloading behavior is opposite of what you
> described.  WAS' classloading tree looks like this:
>
> simplified version:
> System loaders (top, parent of app. loaders)
>         |
>         |
> application loader(s) (2nd, parent of war loaders)
>         |
>         |
> WAR loader(s) (3rd)
>
> The system loaders load WAS jdom.jar, the application loader loads your EA
R
> with your jdom.jar in it, then the WAR loader loads Web-inf/classes and
> web-inf/lib.  Remember the parent loader(s) can't see the classes in the
> child loaders but the child loaders can see the classes in all the parent
> loaders.  Assume you have a WAR application deployed, the way the
> classloading works is the WAR loader would first look at its classpath to
> load the jdom class, if the jdom class can't be found, it would let the
> application classloader resolve the class, if application loader can't loa
d
> the class in its classpath then as the last resort the system loaders woul
d
> resolve the jdom class.  As you can see if the jdom.jar is either in
> web-inf/lib or the ear itself, your application will always, by default, u
se
> that jdom.jar and the WAS jdom.jar will never be used in your application.
>

I think perhaps something's missing in this explanation.  The classloader po
licy you're
describing is the default (PARENT_FIRST).  Under such a policy, the jdom cla
sses in the
parent classloader will be loaded in preference to any jdom classes further 
down the
hierarchy.  How can you say the WAS system-loaded jar will never be used?

Wayne

[ Post a follow-up to this message ]

On Fri, 17 Dec 2004 18:29:19 -0500, Jun wrote:

>
> "Ian" <ianeruda_rem_this@yahoo.com> wrote in message
> news:14vmf0ovwym05$.1bckw4ualm8l0.dlg@40tude.net... 
> is 
> news 
> would 
> application 

[vbcol=seagreen] 
> application 
>
> Actually the default classloading behavior is opposite of what you
> described.  WAS' classloading tree looks like this:
>
> simplified version:
> System loaders (top, parent of app. loaders)
>         |
>         |
> application loader(s) (2nd, parent of war loaders)
>         |
>         |
> WAR loader(s) (3rd)
>
> The system loaders load WAS jdom.jar, the application loader loads your EA
R
> with your jdom.jar in it, then the WAR loader loads Web-inf/classes and
> web-inf/lib.  Remember the parent loader(s) can't see the classes in the
> child loaders but the child loaders can see the classes in all the parent
> loaders.  Assume you have a WAR application deployed, the way the
> classloading works is the WAR loader would first look at its classpath to
> load the jdom class, if the jdom class can't be found, it would let the
> application classloader resolve the class, if application loader can't loa
d
> the class in its classpath then as the last resort the system loaders woul
d
> resolve the jdom class.  As you can see if the jdom.jar is either in
> web-inf/lib or the ear itself, your application will always, by default, u
se
> that jdom.jar and the WAS jdom.jar will never be used in your application.
>
> WAS info center explains what I mentioned in the previous paragraph in far
> greater details.  Hope this helps.
>
> Jun

This is simply not true. Default classloader behaviour in WAS 5.1 is
PARENT_FIRST which means that in this example system classloader will load
jdom.jar first.

[ Post a follow-up to this message ]

What I described is the default behavior for WAS.  The parent first is only
for single classloader, not for multiple.  The default is mulitple
classloader, not single.

Jun

"Ian" <ianeruda_rem_this@yahoo.com> wrote in message
news:22ts4k26dds9.wr5vi00gc2tq.dlg@40tude.net...
> On Fri, 17 Dec 2004 18:29:19 -0500, Jun wrote:
> 
Now[vbcol=seagreen] 
your[vbcol=seagreen] 
that I[vbcol=seagreen] 
I[vbcol=seagreen] 
question[vbcol=seagreen] 
in[vbcol=seagreen] 
this[vbcol=seagreen] 
isn't[vbcol=seagreen] 
war/ear.[vbcol=seagreen] 
>
> 
this[vbcol=seagreen] 
isn't[vbcol=seagreen] 
EAR[vbcol=seagreen] 
parent[vbcol=seagreen] 
to[vbcol=seagreen] 
load[vbcol=seagreen] 
would[vbcol=seagreen] 
use[vbcol=seagreen] 
application.[vbcol=seagreen] 
far[vbcol=seagreen] 
>
> This is simply not true. Default classloader behaviour in WAS 5.1 is
> PARENT_FIRST which means that in this example system classloader will load
> jdom.jar first.

[ Post a follow-up to this message ]