I've implemented what I had in mind, to construct the schema type
loader using exactly the type loaders from the classloaders from the
classes we use. If this doesn't solve the problems I think we will
have to use no j2ee schema types in our dds.
thanks
david jencks
On Saturday, February 21, 2004, at 09:27 AM, David Jencks wrote:
two points:
(1) I think we need to be more careful in the DConfigBeans
constructing the SCHEMA_TYPE_LOADER. For a DConfigBean representing
say GerConnectorType, I think the code should be more like:
static final SchemaTypeLoader SCHEMA_TYPE_LOADER =
XmlBeans.typeLoaderForClassLoader(GerConnectorType.class.getClassLoader
());
(2) According to the docs, XmlBeans.typeLoaderUnion produces a
SchemaTypeLoader that searches its list of type loaders from first to
last. Therefore, by explicitly including the geronimo j2eeschema copy
of the compiled j2ee schemas first, the plugin should be able to
assure itself of the correct copies. Similarly, by including its copy
of the compiled j2ee schemas first, the tool should be able to assure
itself of the correct copies.
(2) + (1) probably means that a union should be explicitly
constructed: whether it can be shared easily among all the dconfig
beans in a "family" I don't know yet.
I might be able to experiment with this more later today or tomorrow,
meanwhile don't hesitate to change stuff to make it work better.
thanks
david jencks
On Saturday, February 21, 2004, at 08:06 AM, Aaron Mulder wrote:
FYI, it didn't work to just create separate ClassLoaders, because
there can only be one current thread context CL, so whichever one we
pick,
the other one breaks.
I am having luck loading the tool beans with a SchemaTypeLoader
constructed off a non-TCCL and letting the server beans load from the
TCCL, but I'm not yet far enough to call it a success.
Aaron
On Sat, 21 Feb 2004, David Jencks wrote:
It might be possible to get "independent" behavior even with several
copies of a compiled schema if we construct a SchemaTypeLoader union
in
the right order, being sure to put the compiled schemas we want to
use
first before the ones from a parent classloader.
david jencks
On Saturday, February 21, 2004, at 06:25 AM, Aaron Mulder wrote:
Jeremy,
Do you think there's some way to tell XMLBeans to load a document,
and let the only references to that schema type be assigned to the
loaded
elements? In other words, the XMLBeans infrastructure should "load
and
forget"? If so, you still have to expect, in the general case, that
the
tool won't do it this way, so it will have to be "load (ignoring any
other
schema type that might be in memory), then forget".
FYI, I was loading the server plugin in a child classloader of the
tool. I can change it around a bit so that the tool and server are
both
children of a common root (which holds only the libs and startup
class).
Aaron
On Sat, 21 Feb 2004, Jeremy Boynes wrote:
We cannot assume that the tool will have done this and need to
find a
solution that means the plugin works even if it is loaded in the
same
classloader as other xmlbeans.
David Jencks wrote:
How is the classloading of the .xsb schema type system set up?
From
your description I would guess that the tool loads its version of
the
j2ee schema types using one classloader, then loads the geronimo
dconfigbeans using a child classloader or the same classloader.
I think if you wish to write a tool using xmlbeans you need to
ensure
that the tools schema type system is loaded by a classloader
inaccessible to any plugins classloader. The copy of xmlbeans
should be
sharable, just not the binary schema .xsb files.
Does this make sense?
