[CXF-724] Interceptor ordering declared programmatically is being overriden by configuration

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.0
• Component/s: Core

Environment

OS X

• Assignee: Daniel Kulp
• Reporter: Fred Dushin
• Created: 12/Jun/07 16:57
• Updated: 29/Aug/07 02:04
• Resolved: 12/Jun/07 18:23

Description

The WSS4JInInterceptor has a dependency on the SAAJInInterceptor, and this is declared programmatically, in the WSS4JInInterceptor ctor, as follows:

{{{
public WSS4JInInterceptor()

{ super(); setPhase(Phase.PRE_PROTOCOL); getAfter().add(SAAJInInterceptor.class.getName()); }

}}}

When I run this interceptor with the following configuration:

{{{
<jaxws:endpoint name="

{http://www.acme.com}

GreeterPort" createdFromAPI="true">
<jaxws:inInterceptors>
<bean class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
<ref bean="WSS4JInInterceptor"/>
</jaxws:inInterceptors>
</jaxws:endpoint>
}}}

the interceptor fails on line 117 with the error: NO_SAAJ_DOC

And the line of code is:

{{{
if (doc == null)

{ throw new SoapFault(new Message("NO_SAAJ_DOC", LOG), version.getReceiver()); }

}}}

Looking at the logs (with full tracing), I see the following interceptor list:

{{{
pre-protocol [WSSJaxBInterceptor, WSSUsernameTokenCredentialsCollector, WSSBinarySecurityTokenCredentialsCollector, WSS4JInInterceptor, WSSX509CertificateCredentialsCollector, MustUnderstandInterceptor, SOAPHandlerInterceptor, LogicalHandlerInInterceptor, SAAJInInterceptor]
}}}

For some reason, the SAAJInInterceptor is being placed last in the phase.

If, on the other hand, I /reverse/ the order of definition in config, to read:

{{{
<jaxws:endpoint name="

{http://www.acme.com}

GreeterPort" createdFromAPI="true">
<jaxws:inInterceptors>
<ref bean="WSS4JInInterceptor"/>
<bean class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor"/>
</jaxws:inInterceptors>
</jaxws:endpoint>
}}}

the interceptor list instead reads:

{{{
pre-protocol [WSSJaxBInterceptor, WSSUsernameTokenCredentialsCollector, WSSBinarySecurityTokenCredentialsCollector, SAAJInInterceptor, WSS4JInInterceptor, WSSX509CertificateCredentialsCollector, MustUnderstandInterceptor, SOAPHandlerInterceptor, LogicalHandlerInInterceptor]
}}}

and the interceptor functions correctly (because the SAAJInInterceptor is getting called before the WSS4JInInterceptor.

This bug is being filed in the context of the WSS4JInInterceptor, but it probably applies to other interceptor types, as well.