Hi Ralf, just trying to catch up on this one.
Ralf Joachim wrote: > Hi Joachim, > > if you like to use only one class loader at XML side I do not care at > the moment but for JDO I know usecases where 2 are required. As far as I > know some older releases of EJB containers required 2 classloaders and > if you use some kind of plugin mechanisms you may also require 2. I am not sure this is required for newer releases of Castor any more. I do agree that with (quite) old releases of ejb/servlet containers (mainly Websphere, Weblogic et alias) class loader handling was error prone. But i have not seen a single issue with servlet/ejb containers in the last four years or so. As such, I would argue that there's Castor releases who can be used on such (oldish) containers, but I would not recommend to anybody to go down that route (again). In other words, if I had a choice in 2008, I would redo things completely. Most of the time (ignoring OSGI for this discussion), getClass().getClassLoader() or Class.forName() should be enough these days. > Having > said that I see also advantages of 2 classloaders for XML when using a > plugin mechanisum. Can you expand on this a bit more ? I am not sure I do understand the use case in this context. > That the 2 classloaders of InternalContext are not used at CPA yet > relates to me not having enough time to pass an context instance around > to all CPA classes where config values and classloaders are used. In > most cases still the context is initialized in a static way which > prevents us from using different configurations anyway. > > Regards > Ralf > > > Joachim Grüneis schrieb: >> Hello, >> >> there are CASTOR-2183 and CASTOR-2187 reminding me constantly there >> this is still an unresolved topic... >> >> Lets define a solution and I will implemented it. >> >> XMLConfiguration knows two class-loaders: application and domain - is >> this concept present somewhere else? are these different class loaders >> really used that way? checking it via call hierarchy shows that the >> domain class loader is not used and application class loader is used >> by some CPA stuff... >> >> XMLContext manages no state... it has a class (okay an interface) >> called InternalContext for that purpose... >> InternalContext has a getClassLoader method which is again not used... Argh! >> >> The first decision I would like to reach: two class-loaders or just one >> >> My personal opinion is to use just one. Most people are already >> confused by one class loader and wont correctly use the possibility to >> use two. Also I know no situation in which I ever required to have two >> class-loaders. Only exception of this rule was some kind of >> bootstrapping - but still either I need Castor in the boot strapping >> then I need Castor and the mapped classes during boot strapping phase >> or I need all of it later - but again no two class loaders known to >> Castor... >> >> Second: I would prefer to hand down InternalContext to classes like >> Marshaller or Unmarshaller by cloning the InternalContext and keeping >> no own attributes in Un-/Marshaller. All classes that are 'served' by >> Un-/Marshaller will receive distinct values being set. >> >> Is this okay to all?! >> >> Have fun >> >> Joachim >> >> 2008/5/27 Werner Guttmann <[EMAIL PROTECTED]>: >>> Dear committers, >>> >>> is there a particular reason why the XMLContext class does not carry a >>> setClassLoader() method. Given that all other classes (such as >>> Unmarshaller and Marshaller (though through >>> XMLClassDescriptorResolver))) carry such a method, it would only be >>> natural to make this available on XMLContext as well, no ? >>> >>> Regards >>> Werner >>> >>> --------------------------------------------------------------------- >>> 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
