oh, I think I might see what you are saying. I think you were saying if
I create two JaxBContexts under two different classloaders?
I am only using JAXBContexts from the same classloader for marshalling
all objects. There is no longer a reason to ever create another
JAXBContext in a different classloader, and I am not sure why anyone
would ever want to.
That said, yes, it does get complicated, but I also expect anyone that
starts messing with classloaders to have a basic understanding of the
way they work.
ie. If I have elements loaded by classloader A. If I then have two
JAXBContexts, one loaded by classloader B and one by C. Then, say A is
a child of B. If I register these elements with JAXBContext loaded by
C, the result would be unknown at this time. If you heavily use
reflection, it would actually work and the elements loaded by
classloader A would still be using the class in JaxME classloader B,
even though they are marshalled unmarshallled by JaxME in classloader
C. After all, JaxME only deals with objects. Regardless, classloader A
must have a parent classloader with JaxME in it(or classloader A must
have jaxME in it). To me, this is basic classloader stuff though and if
someone is using these features, they probably already understand these
issues.
hmmmm....maybe I should test this.....then there is really no
documentation that goes with register except the classloader that is
passed in must be able to load the configuration file of that
package....that and Jaxb must be in the path(meaning parent classloader
or same classloader) would be the only rule.
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]
