geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Why wrap a WebServiceContainer with a StoredObject?
Date Mon, 27 Mar 2006 21:34:16 GMT
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  


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