cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject Creating SOAP header elements without instantiating full SAAJ model
Date Tue, 29 Aug 2006 15:21:04 GMT

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

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.


    // addition of SOAP header - move to a new SOAP Interceptor?
    Element headers = message.getHeaders(Element.class);
    if (null == headers) {
        DocumentBuilder builder =
        Document doc = builder.newDocument();
        SoapVersion version = message.getVersion();
        headers = doc.createElementNS(version.getNamespace(),
        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()),
    // ... similarly for other MAPs

View raw message