registerClassloader....one more question. How would JaxME know which
classloader to use? ie. xml comes in. It looks up the namespace to find
the Manager, but how would it know which classloader to use to create
the JaxB object? I don't want to go through them all for performance
reasons.
In my code, it looks up the manager which will have the correct
classloader for those newly registered Jaxb objects, because the
classloader was passed in with the package and a manager is created with
that classloader. ie. object comes in....jaxme looks up manager, calls
manager. manager uses classloader to load jaxb object and fill it in.
I am not sure if I am not understanding what you are saying, please let
me know if I am not making sense too :)
thanks,
dean
Jochen Wiedmann wrote:
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]
