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?
