Hi Werner,
I think it should be possible to refrain managing classloaders for the
common deployment scenarios while still supporting the early Servlet/
EJB containers you mentioned.
This could be done e.g by refactoring the lookup of a class by it's
name into a strategy pattern which defaults to a version without using
classloaders while still allowing to swap in a strategy that supports
early Servlet/EJB containers.
no worries, Bernhard
Hi Bernhard,
any chances to get a longer summary (sic!) of this discussion .. ;-).
Yes, I agree with the general statement. But we have to live with a
reality, and unfortunately this is a bit different from where we
should
be. And I am not saying that we should not change things.
Having said that, please see inline as well.
Werner
Bernhard Woditschka wrote:
Hi,
I'd Ilke to contribute a summary of a discussion with Joachim on
classloaders:
OSGI based deployment scenarios are emerging (e.g. Eclipse RCP,
Spring
DM,...), I think it should be considered to discuss if Castor should
manage classloaders at all.
Most likely .. no. Problem is, we already do. As such, the solution
would be to find a way to make this work without doing so. As far as I
remember, things have been added so that Castor was capable of working
together with early Servlet/EJB containers (where class loading was a
single big mess initially). As such, it was perfectly understandable
that class loader management was added back then.
To manage (one or multiple) classloaders
will most likly create problems within these deployment scenarios as
OSGIs main concern is classloading.
Agreed.
A solution to load classes by name in a way that would work in all
envirements could be to use Class.forName() and avoid using
ClassLoader.loadClass. This should render the management of
classloaders
obsolete.
I would have a few concerns here, to be honest. Whilost I can see this
working with all major deployment forms where Castor is used (e.g.
stand-alone, JEE, ....), there's a few issues that should be
discussed,
namely loading of (generated) descriptor classes.
No worries, Bernhard
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
