geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Why wrap a WebServiceContainer with a StoredObject?
Date Mon, 27 Mar 2006 21:55:39 GMT

On Mar 27, 2006, at 1:34 PM, Dain Sundstrom wrote:

> I thought this ugly hack was necessary to get around the web class  
> loader being a different class loader than the configuration class  
> loader.   IIRC the trick was to leave the object as a byte array  
> until the actual web class loader was passed in via the TCCL and  
> then deserialized.

That's the reason.

Here is the related commit, though your description is better than my  
commit message:


> -dain
> On Mar 27, 2006, at 1:28 PM, David Jencks wrote:
>> On Mar 27, 2006, at 12:58 PM, Conrad O'Dea wrote:
>>> Howdy,
>>> In the AxisBuilder, when the configurePOJO method constructs an  
>>> AxisWebServiceContainer it is set as an attribute in a GBeanData  
>>> object but is also wrapped in a StoredObject:
>>> targetGBean.setAttribute("webServiceContainer", new StoredObject 
>>> (axisWebServiceContainer));
>>> // Hack!
>>> It's been commented as a hack and I'm just wondering if anyone  
>>> knows why it was done like that.  This is causing me a problem as  
>>> the Celtix based WebServiceContainer that I am building contains  
>>> a reference to an active Celtix transport which does not take  
>>> kindly to being serialized.
>>> Is the wrapping of the WebServiceContainer with a StoredObject  
>>> something that can be changed easily?
>> The idea behind the connection between the web deployer and the  
>> web service deployer is that each will configure part of a gbean  
>> via a GBeanData instance.  I assumed that if you changed web  
>> service provider you'd need a different gbean for it for each of  
>> jetty and tomcat.
>> So, the stored object is a way to get the rather complicated yet  
>> serializable axis configuration objects from deploy time to run  
>> time: the gbean  attributes all have to be serializable.
>> I think what you will need to do is to write new gbeans for  
>> celtix.  That will let you store the necessary information in the  
>> gbeans in an optimal-for-celtix way.  In particular I suspect that  
>> you may want to wrap the transport in a gbean and provide a gbean  
>> reference from the web service gbean (that I'm telling you to  
>> write 2 of, one for jetty and one for tomcat) to that transport  
>> gbean.  When the web service gbean starts, it can construct  
>> whatever it needs to from its attributes and references and in  
>> particular insert the transport into whatever other data  
>> structures need it.
>> Hope this makes at least minimal sense :-)
>> david jencks
>>> thanks
>>> Conrad

View raw message