You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2009/12/03 21:15:31 UTC
Re: NPE caused by cxf-rt-ws-policy with WS-Addressing policy in WSDL
That's definitely a potential way of working around the issue, but I'm
slightly concerned as to why the message would have no content. Is there any
way to create a small sample app (maybe take the provider example and add your
policies and such) that would show this? The list really shouldn't be null
at this point as far as I can tell.
Dan
On Mon November 30 2009 2:09:01 pm Alexandros Karypidis wrote:
> 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(Messag
> >eModeOutInterceptor.java:149)
> >
> > at
> > org.apache.cxf.jaxws.interceptors.MessageModeOutInterceptor.handleMessage
> >(MessageModeOutInterceptor.java:82)
> >
> > at
> > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCh
> >ain.java:236)
> >
> > at
> > org.apache.cxf.ws.addressing.ContextUtils.rebaseResponse(ContextUtils.jav
> >a: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?
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: NPE caused by cxf-rt-ws-policy with WS-Addressing policy in WSDL
Posted by Alexandros Karypidis <ak...@yahoo.gr>.
Hello Daniel,
Since I wrote this e-mail, I've actually checked out the CXF trunk and
have just finished writing a small "integration test" along the lines of
what can be found in cxf-systests-ws-specs. I'm hoping to fix it myself
but I'd appreciate some mentoring since I've been looking at CXF sources
for less than two month (and this on my free time).
I will file a bug report later in the day and attach the patch with the
test that exposes the bug (assuming that it is indeed a bug). I will
move this discussion to the developer mailing.
Daniel Kulp wrote:
> That's definitely a potential way of working around the issue, but I'm
> slightly concerned as to why the message would have no content. Is there any
> way to create a small sample app (maybe take the provider example and add your
> policies and such) that would show this? The list really shouldn't be null
> at this point as far as I can tell.
>
>
> Dan
>
>
> On Mon November 30 2009 2:09:01 pm Alexandros Karypidis wrote:
>
>> 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(Messag
>>> eModeOutInterceptor.java:149)
>>>
>>> at
>>> org.apache.cxf.jaxws.interceptors.MessageModeOutInterceptor.handleMessage
>>> (MessageModeOutInterceptor.java:82)
>>>
>>> at
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCh
>>> ain.java:236)
>>>
>>> at
>>> org.apache.cxf.ws.addressing.ContextUtils.rebaseResponse(ContextUtils.jav
>>> a: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?
>>>
>
>