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