Hi Yes all was fixed when I changes to axiom 1.2.8.
cheers, Håkon 2009/8/13 Chinmoy Chakraborty <[email protected]> > What version of Rampart are you using? I guess your point (2) is something > related to JIRA > *RAMPART-236*<https://issues.apache.org/jira/browse/RAMPART-236>. > Please look at link [1]. > > [1]. > https://issues.apache.org/jira/browse/RAMPART-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739525#action_12739525 > > > Chinmoy > > > 2009/8/13 Håkon Sagehaug <[email protected]> > > Hi, >> >> 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 <[email protected]> >> >>> 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. >>> >>> *2.* Using the dummy INFLOW_SECURITY_SERVER and INFLOW_SECURITY_CLIENT >>> 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(RampartSender.java:70) >>> at org.apache.axis2.engine.Phase.invoke(Phase.java:317) >>> at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:264) >>> at org.apache.axis2.engine.AxisEngine.sendFault(AxisEngine.java:520) >>> at >>> org.apache.axis2.transport.http.server.AxisHttpService.doService(AxisHttpService.java:320) >>> at >>> org.apache.axis2.transport.http.server.AxisHttpService.handleRequest(AxisHttpService.java:187) >>> at >>> org.apache.axis2.transport.http.server.HttpServiceProcessor.run(HttpServiceProcessor.java:82) >>> at >>> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061) >>> at >>> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575) >>> at java.lang.Thread.run(Thread.java:619) >>> Caused by: org.apache.rampart.RampartException: Error in extracting >>> message properties >>> at >>> org.apache.rampart.RampartMessageData.<init>(RampartMessageData.java:322) >>> at org.apache.rampart.MessageBuilder.build(MessageBuilder.java:61) >>> at >>> org.apache.rampart.handler.RampartSender.invoke(RampartSender.java:64) >>> ... 9 more >>> Caused by: org.apache.ws.security.WSSecurityException: 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(Axis2Util.java:161) >>> at >>> org.apache.rampart.RampartMessageData.<init>(RampartMessageData.java:158) >>> ... 11 more >>> Caused by: org.apache.axiom.soap.SOAPProcessingException: Only Characters >>> are allowed here >>> at >>> org.apache.axiom.soap.impl.builder.SOAP11BuilderHelper.processText(SOAP11BuilderHelper.java:151) >>> at >>> org.apache.axiom.soap.impl.builder.SOAP11BuilderHelper.handleEvent(SOAP11BuilderHelper.java:63) >>> at >>> org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.constructNode(StAXSOAPModelBuilder.java:374) >>> at >>> org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.createOMElement(StAXSOAPModelBuilder.java:219) >>> at >>> org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.createNextOMElement(StAXSOAPModelBuilder.java:191) >>> at >>> org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:172) >>> at org.apache.axiom.om.impl.dom.NodeImpl.build(NodeImpl.java:449) >>> at >>> org.apache.axiom.om.impl.dom.DocumentImpl.build(DocumentImpl.java:488) >>> at >>> org.apache.rampart.util.Axis2Util.getDocumentFromSOAPEnvelope(Axis2Util.java:134) >>> ... 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) >> > > -- Håkon Sagehaug, Scientific Programmer Parallab, Bergen Center for Computational Science (BCCS) UNIFOB AS (University of Bergen Research Company)
