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
