On Thu, 2005-03-10 at 16:25 +1300, Simon Kitching wrote:
Hi Ceki,
You mentioned in your page on JCL
(http://www.qos.ch/logging/classloader.jsp):
quote
Jake also keeps reminding us on the log4j-dev mailing list that the
child-parent delegation model is not the only model out there and that
parent-first delegation model is alive and well.
/quote
Are you able to provide the names of some frameworks that use
parent-first classloading? I'm curious to find out whether these are
large + well-used frameworks or whether these are experimental and/or
obsolete systems.
I find it odd that a container would make it impossible for a contained
application to override libraries that the parent provides. This seems
rather fragile and inflexible to me; maybe reading the documentation for
some projects which Jake has referred to will help me understand the
reasons for using parent-first delegation.
I received the following email from Paul Smith ([EMAIL PROTECTED]) which
did not get to this list because, apparently, the moderator rejected it.
It's certainly on-topic and useful so I presume this was just a slip of
the mouse on the moderator's part. Anyway, here's Paul's email:
mail
Resin's default class loader behaviour is parent first. In Resin 2 to
emulate the true specifaction, one has to:
servlet-classloader-hackfalse/servlet-classloader-hack [1]
Which shows you what the Caucho folks think of child-first
delegation :)
[1] - http://www.caucho.com/support/resin-interest/0403/0132.html
Paul Smith
/mail
Following the email thread referred to above:
* Joseph Dane recommends using Resin's default parent-first classloading
but ensuring that the Resin classloader actually has no jars in the path
(ie nothing in resin/lib).
simonWell, if there is nothing in the parent classloader, then
parent-first and child-first are effectively equivalent, yes? So this
advice is not bad, but doesn't shed any light on why Resin goes with
parent-first/simon
* Eric Hauser recommends using a Resin-proprietory extension to
classloading, which involves putting
classpath id='/path-to-hibernate/hibernate2.jar' /
in the web.xml file.
simonI'll try to track down exactly what exactly this does with
respect to class-loaders and CLASSPATHs/simon
NB: in Resin 3.0, the servlet-classloader-hack feature still exists,
but has been moved in the config file to class-loader/servlet-hack.
I've done a fair bit of research in the hope of finding additional info
on resin's classloading policy:
* The Resin docs for the servlet-classloader-hack config element:
http://www.caucho.com/products/resin/ref/http-config.xtp#servlet-classloader-hack
Nope, no clues there
* Hmm..here's a reply to a question from one Torsten Curdt; now where
have I seen that name lately? :-)
http://www.caucho.com/support/resin-interest/0305/0223.html
In the end, though, it doesn't shed a lot of light on why Resin doesn't
wish to follow the java spec...
The resin-reference.pdf file has a fraction more information. It
states that using child-first loading can cause surprising
ClassCaseExceptions. Yep, that's the full description of why they
reject the sun recommendation.
The resin source code doesn't hold any clues either. No comments at all
on why they prefer parent-first.
So I'm still looking for someone to suggest why anyone would not use
child-first
Regards,
Simon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
