Aaron Mulder wrote:
So I'm trying to run a JSR-88 tool that uses XMLBeans for the J2EE DDs against the Geronimo (connector) JSR-88 plugin that also uses XMLBeans for the J2EE namespace. Problem is, the tool doesn't use the same package names that the Geronimo plugin does. And apparently there's some static mapping from namespaces to object classes in XMLBeans, because when the Geronimo code tries to load a J2EE String, it gets the tool's J2EE String class instead of the Geronimo J2EE String class and gets a ClassCastException.
It's possible to construct the tool such that there's a separate XMLBeans instance loaded for each of the server plugin and the tool code with some ClassLoader magic.
AIUI we are using the thread's context classloader to load XMLBeans - David has already raised that as a issue with the ConfigBuilder's and I think this might be the same problem. However, the plugin can't rely on the tool behaving properly so we should try and find a way that the plugin can get the mapping right on its own. Of course, having our tool behave right would help too :-)
It would also be possible to make sure the Geronimo DDs don't use or extend any classes from the J2EE namespace (for example, there's probably no reason why the field in question couldn't be an XSD String instead of a J2EE String).
I think that is too much of a restriction to impose.
It might also be possible to work around this in XMLBeans somehow.
Any preferences or suggestions?
Working around it in the way we use XMLBeans.
-- Jeremy
