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? Thanks, Jarek
