You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Oliver Wulff <ow...@talend.com> on 2010/12/08 14:56:27 UTC

soap header processing and DOM/SAAJ dependency

Hi there

I'd like to put together a list of cases where an interceptor requires the creation of a DOM tree which results into a performance penalty.

1) If you implement a JAX-WS handler, CXF will create a DOM tree of your message everytime

2) If you configure the WSS4J interceptor, a DOM tree is created because of SAAJ dependency

3) If you create an interceptor and define something like:

getAfter().add(SAAJInInterceptor.class.getName());



4) If you implement an interceptor which extends AbstractSoapInterceptor  (not sure)

Are there any other cases where a DOM Tree is implicitly created?

If I want to do some soap header processing and want to avoid the creation of a DOM tree what is the best place to hook in?

Thanks
Oli

Re: soap header processing and DOM/SAAJ dependency

Posted by Daniel Kulp <dk...@apache.org>.
On Wednesday 08 December 2010 8:56:27 am Oliver Wulff wrote:
> Hi there
> 
> I'd like to put together a list of cases where an interceptor requires the
> creation of a DOM tree which results into a performance penalty.
> 
> 1) If you implement a JAX-WS handler, CXF will create a DOM tree of your
> message everytime

Correct.

> 2) If you configure the WSS4J interceptor, a DOM tree is created because of
> SAAJ dependency

Correct.


> 3) If you create an interceptor and define something like:
> 
> getAfter().add(SAAJInInterceptor.class.getName());

No.  Only if the SAAJInInterceptor is also configured in.   You can "after" 
something, but if that something isn't there, its not an issue.   Thus, (3) is 
really "If you explicitely configure in  the  SAAJInInterceptor".

 
> 4) If you implement an interceptor which extends AbstractSoapInterceptor 
> (not sure)

No.  That won't  do it.  We have a bunch of SoapInterceptors, but they 
wouldn't trigger a DOM.

> Are there any other cases where a DOM Tree is implicitly created?

I think the only cases involve the Provider services and Dispatch clients.  If 
you use Provider<SOAPMessage> or Provider<DOMSource>, you'll obviously get the 
DOM.

THAT said, at this point, all the soap headers are parsed into a DOM as part 
of ReadHeaders.  It stops at the soap:Body.   Thus, the headers are always 
available as a DOM.

> If I want to do some soap header processing and want to avoid the creation
> of a DOM tree what is the best place to hook in?

On  the incoming side?   Anytime after the ReadHeaders interceptor.   At that 
point, you can call message.get(Headers.HEADER_LIST) to get the headers and do 
whatever processing you want.


-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog