geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: XMLBeans for DDs
Date Sun, 22 Feb 2004 19:18:41 GMT
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.

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?

View raw message