geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor" <>
Subject Re: SAAJ integration idea
Date Wed, 14 Mar 2007 17:40:00 GMT
> If a webservice can call another webservice locally (using the same
> thread), you will need to keep the original thread local value and
> reset it on the way out.

Yes, of course.

> Do all the SAAJ implementations implement the same spec API version?
> If not you will not be able to switch implementations like this.

Axis2 and CXF yes. Yesterday I got Axis1 updated so that it also
implements SAAJ 1.3 API.  The new methods in Axis1 will just throw
OperationUnsupportedException or similar but at least they are there.

> > Just to clarify, the user is not expected to do the SAAJUniverse
> > set/unset bit. Only the web service container implementations or
> > service-ref builders would do that (i.e. the idea is to make it
> > transparent to the user as much as possible).
> >
> > Also, if a call is made within some SAAJ universe but then it is
> > handled by some thread pool later on, things might break. So this
> > solution is definitely not foolproof but hopefully good enough.
> It should work as long as you reset the thread local in a finally
> block as you have above.

Right, ok.

> > Another idea I've had was to create a new context classloader (when
> > set() is called) instead of the thread local solution. That new
> > context classloader would first load a specific jar file for the SAAJ
> > implementation (the jar file would just contain SAAJ configuration
> > files) and delegate everything else to the existing context
> > classloader. That way, since the right configuration files would
> > appear first in the classloader, it would force the right SAAJ
> > implementation to be used (the SAAJ factory classes first check the
> > context classloader for the configuration files).
> I don't see how this could work as the resource data would likely be
> cached by Java code, so when you attempt switch to another SAAJ
> implementation the Java code won't notice the CL switch.

Hmm... you mean that information would be cached somewhere else
besides the classloader?


View raw message