sorry, I somehow blew past this. It is hard reading through all the
emails on this list. Some answers
two different implementations....not bad wouldn't mind at all. Were
would we put this new class though? I would like to see it no break
when the configuration stuff is overhauled.
synchronization.....IMO. I would like to stay away from
synchronization. I am developing a very high performance platform. I
have done this with castor before and no synchronization. Also, the
JAXB spec team was saying they want to do this without without
synchronization. The trick to not having synchronization is using the
feature of java that lets you change a reference atomically...ie.
public void switchMap(Map newMap) {
Map m = newMap; //this operation is atomic and needs no synchronization.
}
Another way is to just use a synchronized Hashtable to. I believe there
is no reason to use synchronization unless I have mistakes in my code
and in that case, I should fix the mistakes instead of using
synchronization.
classloaders(registerClassLoader). I am confused why you would separate
the registerClassloader and registerPackages method. What would
registerClassLoader do? JAXBContext must be already loaded from it's
classloader if you are calling registerClassloader so it would not be
for the marshaller/unmarshaller/jaxbcontext itself. I don't get that
method that you are trying to split off.
classloaders(registerPackages). The registerPackages method would still
need to take the classloader for how to load those jaxb objects from the
package it was given. Without it, registering the package would result
in the config file not being found as it would not know which
classloader to look in.
Marshaller and classloader......The classloader passed into
registerPackages has nothing to do with Marshaller, and JAXBContext
except that it must be a child classloader of the one that loaded
JAXBContext, because the generated objects depend on JaxME.
Classloader(General). I have had much experience in classloader stuff,
and may not be able to explain this stuff like I was just beginning in
it. Basically, the classloader passed into the register method would
have to be a child of the JAXBContext classloader. When someone loads
their objects through a different classloader, they will encounter
problems long before they call registerPackage, and those problems have
nothing to do with the registerPackage method. The problem they
encounter would likely be ClassNotFoundException: JAXBContext or some
JaxME class because the generated objects depend on JaxME. They would
then change that by making that classloader a child of the JAXBContext
classloader which would resolve all their problems. Again, this is too
clear to me, so it is not easy to make sure I am explaining everything
and might be inadvertently skipping some stuff that has become second
nature to me.
What are your thoughts here?
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]
