Joachim Grüneis wrote: > 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... Let's continue this elsewhere; I have already just posted a reply to some of these issues (as addressed by Ralf as well in a separate email) . > > 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. Okay, I will focus on this subject only in this reply. Personally, I think that an Un-/Marshaller should receive a copy of the InternalContext instance as maintained by XMLContext. It does not need to be a full clone, but let's reverse that statement: by no means should an Un-/Marshaller instance change the InternalContext instance as maintained by the XMLContext class. Currently, this is the case, as can easily be observed when you change a property on e.g. the Marshaller. That change is visible on the XMLContext as well, and that needs to be avoided in the future. Having said that, somehow I don't like a big-bang approach anymore. In other words, let's address all these issues individually, let's keep the discussions focused on one subject only. In other words, if we cannot come to an agreement easily on e.g. class loading, at least start work on isolation/cloning, as I believe it should be far easier to come to a conclusion in this (and other) area(s). > 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
