Dean,
I have studied your patch and find it generally acceptable. Two things
came to my mind, though:
- First of all, my feeling is, that the JAXBContext and it's associated
classes are already too large and complicated. Adding support for
more features will make them even larger. I do not like that.
An alternative and (IMO) better approach would be to create different
implementations of JAXBContext. The user might choose a suitable
implementation. The default implementation might be static. A subclass
might be dynamic.
In that case we might as well synchronize the dynamic implementation
properly (which it definitely should be, IMO). How do you think
about that?
- I am uncertain about the relation between element classes and
classloaders. Keep in mind, that a class called "Marshaller" might
be a totally different thing with separate classloaders. The current
implementation requires that the user knows about that fact and
chooses his classloaders properly. This will likely cause confusion.
I see two possible approaches:
* Document the problem carefully
* Possibly better, if it works (I am unsure about that, classloader
specialists might intervene): Make the JAXBContext use a separate
classloader, which internally delegates to the various other
classloaders. All classes, including marshaller, unmarshaller, etc.
are loaded via this classloader.
The register method would be split into two parts:
a) registerClassLoader() adds a new delegate to the context
classloader.
b) registerPackage() adds a new package.
Note, that the design implicates, that newly registered packages
*might* be loaded via classloaders that have been registered long
before.
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
