axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Håkon Sagehaug <>
Subject Re: axis2 and rampart embedded into a fully POJO environment
Date Thu, 13 Aug 2009 10:40:54 GMT

Didi you solve this? I'm facing the same issues as you. Trying to deploy
rampart enabled service inside the Simple server and getting hit with this
error from the null pointer.

cheers, Håkon

2009/3/23 Csaba Juhász <>

> Hi,
> I'm quite new to Axis so forgive me if ask something stupid.
> We are developing a middleware application which already has numerous
> north- and southbound interfaces towards other software components. We
> already have a solution for SOAP communication (it's based on a simple
> embedded HTTP server and some predefined XML snippets) which has worked so
> far, but we are facing a new use case now which may force us to use a new
> approach (our northbound integration is too specific especially in the field
> of security). There are some constrains and criterias concerning
> deployment,configuration and throughput that must be fulfilled by the new
> solution.
> Currently our software consist of several standalone Java processes
> communicating using an internal CORBA interface (no application server) and
> all configuration is done centrally through one property file manually or
> using our configuration GUI; our project leader wants to keep things this
> way, this is why I'm searching a solution that is fully embeddable and can
> be fully configured and manipulated programmatically.
> In the last few days I was investigating the possibility of using Axis2 and
> more importantly its Rampart module embedded into our POJO project. At first
> I've  tried to find similar use cases on the web but all I've managed to
> find were some cases where Axis was embedded into a web application running
> on some kind of an application server and some examples about the use of the
> SimpleHTTPServer included in Axis2. Using these examples and the
> SimpleHTTPServer I was able to deploy a simple POJO class (the Echo example
> service found on numerous web pages) as a service and engage the Rampart
> module (only a Timestamp is required in the request and the response) on it
> fully programmatically but had some exceptions when the service was exposed
> and I need some tips with these problems. I'm not sure if anyone has done
> something similar but thanks for any help. So the details:
> - I'm using the SimpleHTTPServer to host my test service which is a POJO
> service
> - Rampart module is engaged using the classes in the Rampart distribution
> by using an instance of the AxisnModule class with a programmatic
> configuration based on the contents of the Rampart module's deployment
> descriptor
> *1.* On the first tries when I invoked the deployed service with Rampart
> engaged on the server, my requests were sucessful regardless of the missing
> security header (only a timestamp) of the request. To find out the cause
> I've debugged the program flow during request processing and I've  found out
> that this behaviour was caused during the execution of Rapmpart's
> WSDoAllReceiver class. More concretely by the Object keyed with
> WSSHandlerConstants.INFLOW_SECURITY_SERVER (InflowSecurity-server) missing
> from either the options or the message context and similarly by the Object
> keyed with WSSHandlerConstants.INFLOW_SECURITY_CLIENT
> (InflowSecurity-client) missing from the same places. The relevant code in
> the WSDoAllReceiver class starts at line 119, you can see that the whole
> security functions are bypassed when the values retrieved by the ywo keys
> are nulls. I assume both of these keys are populated somehow in a normal
> deployment environment, but in my case they weren't as I've used only the
> WSSHandlerConstants.INFLOW_SECURITY (InflowSecurity) and
> WSSHandlerConstants.OUTFLOW_SECURITY (OutflowSecurity) keys to configure
> security on my service. My question is how are these missing keys poulated
> during normal deployment, what are their default values? I've currenlty
> managed to bypass this problem by putting instances of the Object class into
> the AxisConfiguration context using the two keys.
> objects I was able to come a bit further, but found a new problem for
> myself. Now my service invocations are failing as they should but the
> correct soap message is not returned to the client. I see the correct
> exception in the server logs (org.apache.axis2.AxisFault: WSDoAllReceiver:
> Incoming message does not contain required Security header) but directly
> after that I get an other exception and no result is returned to the client.
> I get the following exception:
> WARN  [HttpConnection-8080-1] - Error in extracting message properties
> org.apache.axis2.AxisFault: Error in extracting message properties
>     at
> org.apache.rampart.handler.RampartSender.invoke(
>     at org.apache.axis2.engine.Phase.invoke(
>     at org.apache.axis2.engine.AxisEngine.invoke(
>     at org.apache.axis2.engine.AxisEngine.sendFault(
>     at
> org.apache.axis2.transport.http.server.AxisHttpService.doService(
>     at
> org.apache.axis2.transport.http.server.AxisHttpService.handleRequest(
>     at
>     at
>     at
>     at
> Caused by: org.apache.rampart.RampartException: Error in extracting message
> properties
>     at
> org.apache.rampart.RampartMessageData.<init>(
>     at
>     at
> org.apache.rampart.handler.RampartSender.invoke(
>     ... 9 more
> Caused by: Error in converting
> SOAP Envelope to Document; nested exception is:
>     org.apache.axiom.soap.SOAPProcessingException: Only Characters are
> allowed here
>     at
> org.apache.rampart.util.Axis2Util.getDocumentFromSOAPEnvelope(
>     at
> org.apache.rampart.RampartMessageData.<init>(
>     ... 11 more
> Caused by: org.apache.axiom.soap.SOAPProcessingException: Only Characters
> are allowed here
>     at
> org.apache.axiom.soap.impl.builder.SOAP11BuilderHelper.processText(
>     at
> org.apache.axiom.soap.impl.builder.SOAP11BuilderHelper.handleEvent(
>     at
> org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.constructNode(
>     at
> org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.createOMElement(
>     at
> org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.createNextOMElement(
>     at
>     at
>     at
>     at
> org.apache.rampart.util.Axis2Util.getDocumentFromSOAPEnvelope(
>     ... 12 more
> Debugging the Rampart code I've found a posible cause but I'm not sure what
> to do about this one. I think the root cause for this is that the
> AxisService attribute is not copied when the FaultContext gets created from
> the original message context so its value will remain null. When the Rampart
> sender creates the RampartMessageData this null value causes a null pointer
> exception at line 308 of the constructor of the RampartMessageData class (
> *this.customClassLoader = msgCtx.getAxisService().getClassLoader();*).
> This may mean some inconsistency in this class because there is already a
> null value check for the value of the AxisService with a TODO comment
> indicating that there can be cases where the AxisService is null (the
> relevant code starts at line 177 of RampartMessageData). I'm not sure if
> this can be bypassed at all with some changes in my programmatic deployment,
> but I would be very happy if someone had some idea how to solve this.
> This got a bit lengthy and it's possible that my whole idea is wrong; feel
> free to tell me so, at least I won't waste more time with something
> impossible.
> Best regards,
> Csaba

Håkon Sagehaug, Scientific Programmer
Parallab, Bergen Center for Computational Science (BCCS)
UNIFOB AS (University of Bergen Research Company)

View raw message