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:
http://svn.apache.org/viewcvs.cgi?rev=157992&view=rev
-David
-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