Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44F5A357.1060101@envoisolutions.com>
Date: Wed, 30 Aug 2006 10:40:23 -0400
From: Dan Diephouse <dan@envoisolutions.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
CC: "Kulp, John Daniel" <daniel.kulp@iona.com>
Subject: Re: Creating SOAP header elements without instantiating full SAAJ
 model
References: 
 <FA1787F64A095C4090E76EBAF8B183E00300D6@emea-ems1.dublin.emea.iona.com>
In-Reply-To: 
 <FA1787F64A095C4090E76EBAF8B183E00300D6@emea-ems1.dublin.emea.iona.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Eoghan,

One option might be to add a getOrCreateHeaders() method SoapMessage. 
Then we aren't creating a header everytime. Although that would probably 
presume that we're working with just DOM headers.

I suppose for now it might not be a bad idea to just add an interceptor 
which does it for us. We can always tweak it later.

- Dan

Glynn, Eoghan wrote:
> Hi Dan,
>
> I'm recasting the WS-A handlers as interceptors, partly to avoid
> instantiating the full SAAJ model (as would be required for a JAX-WS
> SOAPHandler).
>
> I know your working on some smarts around optimizing the creation of the
> SOAPMessageContext from the SOAPMessage, perhaps to avoid the full SAAJ
> model if only the SOAPHeaders are touched by the handler? So I just
> wanted to check that I wasn't working at cross-purposes to you ...
>
> Now I've found that the way the SOAP interceptors are currently
> structured, my WS-A interceptor has to take responsibility for adding
> the SOAP header element. 
>
> See below a highly excerpted snippet of the approach my interceptor
> takes, I just wanted to check whether this would conflict with your
> SOAPMessageContext-related changes ... particularly whether I should
> look at adding an extra SOAP interceptor in the out chain that simply
> calls SoapMessage.setHeaders() with an empty Element so that this is
> available for other interceptors in the pre- or post-protocol phase that
> need to add headers.
>
> Cheers,
> Eoghan
>
>     // addition of SOAP header - move to a new SOAP Interceptor?
>     Element headers = message.getHeaders(Element.class);
>     if (null == headers) {
>         DocumentBuilder builder =
> DocumentBuilderFactory.newInstance().newDocumentBuilder();
>         Document doc = builder.newDocument();
>         SoapVersion version = message.getVersion();
>         headers = doc.createElementNS(version.getNamespace(),
>  
> version.getHeader().getLocalPart());
>         headers.setPrefix(version.getPrefix());
>         message.setHeaders(Element.class, headers);
>     }
>
>     // marshall WS-A MAPs
>     Marshaller marshaller = jaxbContext.createMarshaller();
>     marshaller.setProperty(Marshaller.JAXB_FRAGMENT, Boolean.TRUE);
>     marshaller.marshal(new JAXBElement<AttributedURIType>(qname,
> AttributedURIType.class, maps.getMessageID()),
>                        headers);
>     // ... similarly for other MAPs
>  
>   


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog