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
