geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor" <>
Subject SAAJ integration idea
Date Wed, 14 Mar 2007 15:15:18 GMT
I'm working on the SAAJ integration in Geronimo. I have the following
idea on how to integrate it and I would applicate any comments,
suggestions, better solutions, etc.

We have three different SAAJ implementations to work with: Axis1,
Axis2, and Sun. And we can't really just use one as Axis1/Axis2 expect
their own implementations. Also, please keep in mind that within the
same module we can have both JAX-RPC and JAX-WS web services.
Now, in G code in certain places we know exactly what sort of SAAJ
implementation should be used. For example, if I'm invoking a Axis2
service, it should be using Axis2 SAAJ implementation. Or if I'm
calling a JAX-RPC service (using service-ref) Axis1 SAAJ
implementation should be used, and so on. So the idea is this:

First, in such places that we know what implementation should be used,
set the SAAJ implementation preference explicitly. For example:

SAAJUniverse universe = new SAAJUniverse(SAAJUniverse.Axis1);
try {
  // invoke the web service
} finally {

The .set() method would set some thread local variable with the SAAJ
implementation preference.

Second, we would provide our own implementations of the different SAAJ
Factory classes. These factory classes would just check that thread
local preference variable and return the appropriate factory instance.
Or if no preference is set, default to Sun's implementation.

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.

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).



View raw message