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
