geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <da...@coredevelopers.net>
Subject Re: XMLBeans for DDs
Date Sat, 21 Feb 2004 17:27:55 GMT
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?
>>>
>>
>


Mime
View raw message