Hi Werner,
Joachim pointed out that the dev list would be more suitable for this
discussion, so I'll post he answer there under the subject '[castor-
dev] XMLContext and setClassLoader()'
no worries, Bernhard
On May 28, 2008, at 9:31 AM, Werner Guttmann wrote:
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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
