I'd just like to elaborate on this a bit since this "fix" wasn't real clear
but certainly does work.  The end result should look like this:

import java.util.List;

import javax.xml.soap.SOAPMessage;

import org.apache.cxf.binding.soap.SoapMessage;
import org.apache.cxf.interceptor.Fault;
import org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor;

public class PatchedWSS4JOutInterceptor extends WSS4JOutInterceptor {
        
        public PatchedWSS4JOutInterceptor() {
                super();
        }
        
        public PatchedWSS4JOutInterceptor(java.util.Map<java.lang.String, 
                java.lang.Object> props) {
                super(props);
        }
        
        public void handleMessage(SoapMessage msg) throws Fault {
                SOAPMessage sm = 
(SOAPMessage)msg.getContent(List.class).get(0); 
                msg.setContent(SOAPMessage.class, sm); 
                super.handleMessage(msg); 
        }
}

I had the exact same problem and WS-S X.509 support in cxf would not work
with a JAX-WS Provider type service.  The reason I'm using a Provider is
that I'm doing some work with XACML using OpenSAML and I'm marshalling to
and from XML using the framework and building my own messages.  I still
needed signtures to meet the profile requirements though and WS-S in cxf
fits the bill.

For the record, I'm also using a Dispatch<SOAPMessage> style client.  To tie
in the WS-S to the client I set the interceptors on the cxf bus in the
spring config.  The WSS4JOutInterceptor works perfectly fine without need
for modifications when used with the Dispatch client.  I suspect it has
something to do with the interceptor chains.  I've got bigger fish to fry so
no time to sweat the details now!  I'm just glad this "patch" from Lee got
me up and running!




Lee Breisacher-2 wrote:
> 
> For the record, the fix for this NPE is trivial, and this single fix seems
> to be all that's needed -- WS-S seems to work fine after just this one
> fix. I added this to my subclass of WSS4JOutInterceptor:
> 
>             SOAPMessage sm = (SOAPMessage)
> msg.getContent(List.class).get(0);
>             msg.setContent(SOAPMessage.class, sm);
>             super.handleMessage(msg);
> 
> Lee
> 
>> -----Original Message-----
>> From: Lee Breisacher [mailto:[email protected]]
>> Sent: Wednesday, September 24, 2008 12:54 PM
>> To: Daniel Kulp; [email protected]
>> Subject: RE: NPE when using WSS4JOutInterceptor
>>
>> Hm, that's too bad. I really need WS-Security.
>>
>> I don't mind hacking around with interceptors to make it work
>> -- would it be possible to get a brief overview of how
>> provider-style differs from "ordinary" services? When I debug
>> an ordinary service, I see lots of interceptors, like this:
>>
>> Chain org.apache.cxf.phase.phaseinterceptorch...@62aa33. Current flow:
>>   pre-logical [HolderOutInterceptor, SwAOutInterceptor,
>> WrapperClassOutInterceptor, SoapHeaderOutFilterInterceptor]
>>   post-logical [SoapPreProtocolOutInterceptor]
>>   prepare-send [MessageSenderInterceptor]
>>   pre-stream [LoggingOutInterceptor,
>> AttachmentOutInterceptor, StaxOutInterceptor]
>>   pre-protocol [SOAPHandlerInterceptor, WSS4JOutInterceptor]
>>   write [SoapOutInterceptor]
>>   pre-marshal [LogicalHandlerOutInterceptor]
>>   marshal [WrappedOutInterceptor, BareOutInterceptor]
>>   pre-stream-ending [StaxOutEndingInterceptor]
>>   prepare-send-ending [MessageSenderEndingInterceptor]
>>
>> And when I debug my provider-based service, I see not nearly
>> as many, like this:
>>
>> Chain org.apache.cxf.phase.phaseinterceptorch...@16fb957.
>> Current flow:
>>   prepare-send [MessageSenderInterceptor]
>>   pre-stream [LoggingOutInterceptor]
>>   pre-protocol [WSS4JOutInterceptor]
>>   write [DispatchOutDatabindingInterceptor]
>>   pre-marshal [DispatchLogicalHandlerInterceptor]
>>   user-protocol [DispatchSOAPHandlerInterceptor]
>>   prepare-send-ending [MessageSenderEndingInterceptor]
>>
>> I can see where things like StaxOut are setting up things
>> that the WSS4JOut uses (actually the SAAJOut called from
>> WSS4JOut), such as:
>>
>>         message.setContent(XMLStreamWriter.class, writer);
>>
>> The lack of that StaxOut is the cause of the particular NPE
>> I'm seeing.
>>
>> Anyway, I'm just wondering -- at a high level, how does
>> provider-style service work, interceptor-flow-wise? Do you
>> think it's practical for me to try to chase these kind of
>> bugs one-at-a-time and make it work?
>>
>> Thanks,
>>
>> Lee
>>
>>
>> > -----Original Message-----
>> > From: Daniel Kulp [mailto:[email protected]]
>> > Sent: Wednesday, September 24, 2008 11:46 AM
>> > To: [email protected]
>> > Cc: Lee Breisacher
>> > Subject: Re: NPE when using WSS4JOutInterceptor
>> >
>> >
>> > Honestly, I'm not sure any of the "advanced" things work with the
>> > provider/dispatch style services right now.   I KNOW
>> > ws-addressing and WS-RM
>> > don't.  The interceptors for the provider based stuff
>> definitely need
>> > some
>> > work to get them to properly slip into the other pathways.   :-(
>> >
>> > Dan
>> >
>> >
>> >
>> > On Wednesday 24 September 2008 1:36:59 pm Lee Breisacher wrote:
>> > > I have a simple WebServiceProvider-based service. I'm using
>> > CXF 2.1.2.
>> > > When I add a WSS4JOutInterceptor, I get this NullPointerException:
>> > >
>> > > java.lang.NullPointerException
>> > >         at
>> > >
>> > >org.apache.cxf.staxutils.StaxUtils.writeStartElement(StaxUtil
>> s.java:369
>> > >) at
>> > > org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:326) at
>> > > org.apache.cxf.staxutils.StaxUtils.copy(StaxUtils.java:314) at
>> > >org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEn
>> dingInterc
>> > >epto
>> > >r.handleMessage(SAAJOutInterceptor.java:161) at
>> > >org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor$SAAJOutEn
>> dingInterc
>> > >epto
>> > >r.handleMessage(SAAJOutInterceptor.java:127) at
>> > >org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseI
>> nterceptor
> 
>> > >Chai
>> > >n.java:220) at
>> > >
>> > >org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMes
>> > sage(Outgo
>> > >ingC
>> > >hainInterceptor.java:74) at
>> > >
>> > >org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseI
>> nterceptor
>> > >Chai
>> > >n.java:220) at
>> > >
>> > >org.apache.cxf.transport.ChainInitiationObserver.onMessage(Ch
>> ainInitiat
>> > >ionO
>> > >bserver.java:78) at
>> > >
>> > >org.apache.cxf.transport.servlet.ServletDestination.invoke(Se
>> rvletDesti
>> > >nati
>> > >on.java:92) at
>> > >
>> > >org.apache.cxf.transport.servlet.ServletController.invokeDest
>> ination(Se
>> > >rvle
>> > >tController.java:283) at
>> > >
>> > >org.apache.cxf.transport.servlet.ServletController.invoke(Ser
>> vletContro
>> > >ller
>> > >.java:166) at
>> > >
>> > >org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(Ab
>> stractCXFS
>> > >ervl
>> > >et.java:174) at
>> > >
>> > >org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(Ab
>> stractCXFS
>> > >ervl
>> > >et.java:152) at
>> > >javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
>> > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at
>> > >
>> > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.j
>> > ava:487)
>> > >at
>> > >
>> > >org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandle
>> r.java:362
>> > >) at
>> > >
>> > >org.mortbay.jetty.security.SecurityHandler.handle(SecurityHan
>> dler.java:
>> > >216)  at
>> > >org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandle
>> r.java:181
>> > >)  at
>> > >org.mortbay.jetty.handler.ContextHandler.handle(ContextHandle
>> > r.java:729
>> > >)  at
>> > >org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.j
>> > ava:405)
>> > >at
>> > >
>> > >org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrappe
>> > r.java:152
>> > >) at
>> > > org.mortbay.jetty.Server.handle(Server.java:324)
>> > >         at
>> > >
>> > >org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection
>> > .java:505)
>> > >at
>> > >org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpC
>> onnection.
>> > >java
>> > >:843) at
>> > org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:647) at
>> > >
>> org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at
>> > >
>> org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380) at
>> > >
>> > >org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEnd
>> Point.java
>> > >:395
>> > >) at
>> > >
>> > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThr
>> eadPool.java:
>> > >450) Sep 24, 2008 10:31:55 AM
>> > > org.apache.cxf.interceptor.LoggingOutInterceptor$LoggingCallback
>> > >onClose
>> > >
>> > > I'm not actually doing anything with WSS yet - just inserted the
>> > > interceptor in preparation for doing some real WSS stuff.
>> > >
>> > > I found CXF-1538 (http://issues.apache.org/jira/browse/CXF-1538),
>> > > which looks sortof like the same problem, but it appears to
>> > have been
>> > > fixed already.
>> > >
>> > > Am I doing something wrong or is this a bug?
>> > >
>> > > Thanks,
>> > >
>> > > Lee
>> >
>> >
>> >
>> > --
>> > Daniel Kulp
>> > [email protected]
>> > http://www.dankulp.com/blog
>> >
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/NPE-when-using-WSS4JOutInterceptor-tp19654161p21286952.html
Sent from the cxf-user mailing list archive at Nabble.com.

Reply via email to