Axis2 1.5.1, JAX-WS and Rampart: client and endpoint configuration

[Victor Rentea <vi...@gmail.com>]

Hy everyone!

I built a working (?) solution and I want your opinion if this is a
safe approach, and if its semantically consistent with Axis2
internals.
I would really appreciate if you could give me a hand because my
knowledge of Axis internals is very limited.
Many will be interested in this subject especially because the
examples on the net are missing, and I didn’t managed to find anything
useful on this topic.

My requirements are:
Build J2ee web apps that expose secure web services with the latest
stable technology.

The solution I am building consists of an axis engine with the JAX-WS
services deployed right onto the web-app classes folder (next to the
Axis2Servlet), not putting any jaxws jar in servicejar.

Following [1] I managed to create an endpoint that used Rampart with
JAX-WS. By using SoapUI I managed to test it successfully. In fact,
this behavior (rampart configured on a per-axis2 engine basis) is
exactly what I needed, because all my webservices deployed there where
homogenous (part of the same application).

The next task, as other had also encountered [2], is creating a client
jax-ws application to consume the secure WS. I really wanted to stay
on the JAX-WS world because of the great JAXB and the Proxy feature,
that kept my code clean and small. Of course, I guess one can always
switch to the old JAX-RPC approach, that works perfect with Axis2, but
this seemed to me as a “downgrade”.

So I tried building a JAX-WS client to consume a secured WS.

First observation: another axis2 runtime was build in order to invoke
a jax-ws call (some modules were loaded again, time was wasted).

Second obs: the new runtime was not using the axis2.xml configuration
file, so the Rampart module was not loaded. The sent messages were not
passing through Rampart. What I needed is to somehow reuse the
existing Axis2 engine (started with the web-app) with the JAX-WS call.

As this seemed pseudo-impossible, I tried to at least reuse the
org.apache.axis2.context.ConfigurationContext from the running engine.
In order to get a grip of that context, I created a module that stored
this context for later use in a static field CONFIG_CONTEXT_REF.

After deep searches, I found
org.apache.axis2.jaxws.ClientConfigurationFactory that had an factory
method

public static ClientConfigurationFactory newInstance() {
return (ClientConfigurationFactory)MetadataFactoryRegistry.getFactory(ClientConfigurationFactory.class);
   }
That can be customized (through
org.apache.axis2.metadata.registry.MetadataFactoryRegistry) to return
ANOTHER IMPLEMENTATION, by means of a particular configuration file
placed at
WEB-INF/classes/META-INF/services/org.apache.axis2.metadata.registry.MetadataFactoryRegistry


With the contents of

org.apache.axis2.jaxws.ClientConfigurationFactory|com.sample.CustomClientConfigurationFactory

So what I did is implement a

public class CustomClientConfigurationFactory extends
org.apache.axis2.jaxws.ClientConfigurationFactory {
	@Override
	public synchronized ConfigurationContext getClientConfigurationContext() {
		if (MyModule.CONFIG_CONTEXT_REF!=null) {
			return MyModule.CONFIG_CONTEXT_REF;
		} else {
			return super.getClientConfigurationContext();
		}
	}
}


That returned the stored config context from the module.

The strange thing is that when I deployed this solution, I noticed
that no additional Axis engine was created anymore, and the Rampart
module did his job, securing out and in flow.



[1] http://markmail.org/message/dkwjvskrh3gysvnw?q=list#query:list+page:1+mid:aioxif5ayfhwagnz+state:results
[2] http://markmail.org/message/dkwjvskrh3gysvnw?q=list#query:list+page:1+mid:t7cpqqdc7pbcstol+state:results