Dean Hiller wrote:
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.
Doesn't matter. If it is there, and there is a unit test for its features, then we'll know if future changes break the feature.
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.
I absolutely do not follow the JAXB spec team here. The JAXBContext is explicitly designed for being thread safe. However, a modifiable JAXBContext is either not thread safe or synchronized. That's a fact.
Besides, I do not understand why the performance impact of synchronization should be so dramatically: Consider the case of marshalling to a Writer or InputStream. The writers and input streams are typically synchronized. In other words, marshalling will typically involve several hundred or thousand synchronized accesses to the target object. On the other hand, requesting the Manager object from the will add a single synchronized access to the JAXBContext. What's the story?
The trick to not having synchronization is using the feature of java that lets you change a reference atomically...ie.
No, that's simply not sufficient. It's like assuming that using a Hashtable (aka synchronized Map) will make an application thread safe. You are missing the gap between reading information and updating information.
Another way is to just use a synchronized Hashtable to.
A Hashtable *is* a synchronized object. As for performance, it doesn't matter, which object is being synchronized: The JAXBContext or the Hashtable. Besides, I have already pointed out that using a Hashtable won't make the code thread safe.
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.
Is your application threaded? If so, you need some style of synchronization, however it might look like. If you are doing that for yourself, then you don't do it at the logical place. (Which is as near to the critical objects aka Manager maps as possible.) This is far more error prone than doing it at the natural point.
classloaders(registerClassLoader). I am confused why you would separate the registerClassloader and registerPackages method. What would registerClassLoader do?
I simply do not see a reason why additional packages need another classloader. There may be a reason in your application but that's unrelated to the process of extending the manager map.
Even more important: The JAXBContext was designed (with very good reason!) to have a single ClassLoader. To me the "registerClassLoader" method means extending that single ClassLoader and not extending the internal map of managers.
Jochen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
