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

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

Hello.


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