Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.gr;
  h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
  b=DKii4TGnO6fX7HOkTKLGxRxSCRsRlhOMs6K09ae8qwaTfCpB5zRSl+W4TwRqw/7vgPnQZMgQoyescFB+2KE+aE0T6eCkI+yKmQ/Ynx9zpn1iELDVUKxhgxRWR5ruZ/+ZZo25WYapKzgOZJsha5+N9EArh6DhInGaGO9jbhEiPxI=
  ;
Message-ID: <4B14184D.4050904@yahoo.gr>
Date: Mon, 30 Nov 2009 21:09:01 +0200
From: Alexandros Karypidis <akarypid@yahoo.gr>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: users@cxf.apache.org
Subject: Re: NPE caused by cxf-rt-ws-policy with WS-Addressing policy in WSDL
References: <4B140D9C.3060900@yahoo.gr>
In-Reply-To: <4B140D9C.3060900@yahoo.gr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ok, I've been reading through the source code of  CXF and found that the 
error seems to be related with the service mode and the SAAJ 
interceptor. This may be a bug, so if someone more knowledgable could 
help out in isolating, please read on (note that the references to CXF 
sources are from the 2.2.4 release):

When the endpoint uses "message" mode:

    @WebServiceProvider(...)
 >    @ServiceMode(Mode.MESSAGE)
    @BindingType(value = HTTPBinding.HTTP_BINDING)
    public class MyServiceProvider implements Provider<Source> {
    ...

Then the "org.apache.cxf.jaxws.interceptors.MessageModeOutInterceptor" 
will behave as follows (LINE 81):

        if (saajOut != null) {
            doSoap(message);

Where (LINE 147):

    private void doSoap(Message message) {
        MessageContentsList list = 
(MessageContentsList)message.getContent(List.class);
        Object o = list.get(0);

The NPE is because "message.getContent(List.class);" returns null in 
this case.

I believe doSoap() should be re-written as:

    private void doSoap(Message message) {
        MessageContentsList list = 
(MessageContentsList)message.getContent(List.class);
if(list != null) { // =========== do nothing if there is no content
        Object o = list.get(0);
        if (o instanceof SOAPMessage) {
            SOAPMessage soapMessage = (SOAPMessage)o;
            if (soapMessage.countAttachments() > 0) {
                message.put("write.attachments", Boolean.TRUE);
            }
        }
        message.getInterceptorChain().add(internal);
} // =========== end of addition
    }

Does this sound right?

Alexandros Karypidis wrote:
> Hi,
>
> I need some help with WS-Policy in CXF 2.2.4
>
> I have been fighting to enable WS-Addressing using the WS-Addressing 
> Metadata policy assertions. I attahed a policy in my WSDL with:
>    <wsp:Policy wsu:Id='myPolicy' 
> xmlns:wsp='http://www.w3.org/ns/ws-policy'>
>        <wsam:Addressing 
> xmlns:wsam='http://www.w3.org/2007/05/addressing/metadata' >
>            <wsp:Policy/>
>        </wsam:Addressing>
>    </wsp:Policy>
>
> Now, I have two separate CXF applications (the provider-app and the 
> client-app). Both activate the policy framework by:
>    1) Adding a dependency in their pom.xml to "cxf-rt-ws-policy"
>    2) Including in their spring "beans.xml" an
>        <import 
> resource="classpath:META-INF/cxf/cxf-extension-policy.xml" />
>
> The problem is that when the provider has WS-Policy enabled, the 
> MAPAggregator throws an NPE.
>
> So, if I do (1) and (2) for both the "client WAR" and the "provider 
> WAR", I get an NPE at the provider-side, while the incoming request is 
> being processed. If I remove (1) and (2), the policy still gets parsed 
> properly and Addressing headers are added by CXF in the client, 
> without the provider complaining. I assume that in this case the 
> addressing interceptors are not added to the endpoint of the provider, 
> so it doesn't attempt to process the WS-Addressing headers, thus 
> avoiding the NPE.
>
> The NullPointerException is thrown while the server processes the 
> request at:
> java.lang.NullPointerException
>    at 
> org.apache.cxf.jaxws.interceptors.MessageModeOutInterceptor.doSoap(MessageModeOutInterceptor.java:149) 
>
>    at 
> org.apache.cxf.jaxws.interceptors.MessageModeOutInterceptor.handleMessage(MessageModeOutInterceptor.java:82) 
>
>    at 
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236) 
>
>    at 
> org.apache.cxf.ws.addressing.ContextUtils.rebaseResponse(ContextUtils.java:380) 
>
>    at 
> org.apache.cxf.ws.addressing.MAPAggregator.mediate(MAPAggregator.java:355) 
>
> ...
> I looked at the CXF code and the catch() block which prints out the 
> above stack trace also logs:
> WARNING: SERVER_TRANSPORT_REBASE_FAILURE_MSG
>
> I'm using CXF 2.2.4 / Sun JDK 1.6.0_16 and get the same error when 
> deploying the "provider-app" on:
>
> - Tomcat 6.0.20
> - JBoss 5.1
> - WebLogic 10.3.2
>
> Any ideas what could be wrong?