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. Having said that I see also advantages of 2 classloaders for XML when using a plugin mechanisum.
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
