Important classes are package-private [SWS-153]

[gregturn]

Jeff Peterson opened SWS-153 and commented

A great deal of important classes are package private. While writing an interceptor, I discovered that I would need access to some of these classes in order to appropriately process the message.

For example, I was trying to add some header elements to an outgoing message.

 // create header element
 SoapMessage msg = (SoapMessage) messageContext.getResponse();
 SoapHeaderElement security = msg.getEnvelope().getHeader().addHeaderElement(WSSE_SECURITY);
  // add child elements
 // but I can't do this because SaajSoapHeaderElement is package-private
((SaajSoapHeaderElement) security).getSaajHeaderElement().addChildElement(...);

When I was poking around in the SVN i noticed a ton of package-private classes. May i suggest that they be made public?

org.springframework.ws.soap.saaj.*
org.springframework.ws.soap.axiom.*
...

---

Affects: 1.0 M3

Attachments:

• SWS-153.patch (16.86 kB)

Issue Links:

• AxiomSoapHeaderElement has no convenient way to access child elements of the header element [SWS-243] #396 AxiomSoapHeaderElement has no convenient way to access child elements of the header element

[gregturn]

Jeff Peterson commented

Changed classes in org.springframework.ws.soap.axiom.* and org.springframework.ws.soap.saaj.* to public.

[gregturn]

Jeff Peterson commented

So, i discovered after making those changes that I still couldn't add children to a header element. The problem is that getSaajHeaderElement() and getSaajElement() are "protected". They could be made "public" but that seems to be a slippery slope.

I've looked at using the getSource()/getResult() methods, but in SAAJ 1.1 they return a SAXSource/SAXResult. This would mean re-parsing the message which I don't like. If I wasn't using SAAJ 1.1, getSource()/getResult() would seem to be the ideal method.

Perhaps this whole issue isn't a bug after all, just a limitation of an old SAAJ API.

[gregturn]

Kai Hudalla commented

I am experiencing a similar problem while implementing an EndpointExceptionResolver. I am subclassing org.springframework.ws.soap.server.endpoint.AbstractSoapFaultDefinitionExceptionResolver and while implementing the customizeFault() method, I run into the following problem:

        try
        {
            // the exception thrown by the service which I want to resolve to a SOAP Fault Detail
            IMException imEx = (IMException) e;
            SoapFaultDetail detail = fault.addFaultDetail();

            // create detail element 
            OMElement elem = IdmAdaptorUtils.createFaultDetail(imEx);
            XMLStreamWriter writer = XMLOutputFactory.newInstance().createXMLStreamWriter(detail.getResult());
            elem.serialize(writer);
        }
        catch (XMLStreamException e1)
        {
            logger.error(e1);
        }
        catch (FactoryConfigurationError e1)
        {
            logger.error(e1);
        }            

This code runs into the catch ( XMLStreamException ) block since the underlying XMLOutputFactory does not support creating an XMLStreamWriter from a SAXResult which is what the detail.getResult() method returns. Anyhow, since the XMLOutputFactory.createXMLStreamWriter(Result) is an optional operation, how is an implementor supposed to add something more sophisticated than plain text to the SoapFaultDetail? Casting to AxiomSoapFaultDetail and directly accessing the OMElement it represents does not work for the same reasons Jeff has pointed out ...

[gregturn]

Jeff Peterson commented

Kai,

I found a work-around that might help you. In your case you would do something like:

SoapFaultDetail detail = fault.addFaultDetail();
OMElement elem = IdmAdaptorUtils.createFaultDetail(imEx);

TransformerFactory tFactory = TransformerFactory.newInstance();
Transformer xformer = tFactory.newTransformer();

// somehow get a Source object for elem
Source source = new DOMSource(elem); // this won't work, but should give you the idea.

xformer.transform(source , detail.getResult());

[gregturn]

Arjen Poutsma commented

There is a good reason I made these classes public: I cannot guarantee that the interface will stay the same, as new SAAJ versions are released. Therefore, I am resolving this as won't fix.

There is a workaround though: you can call getSaajMessage() on the SaajSoapMessage, or getAxiomMessage() on the AxiomMessage. This will give you the raw, unwrapped message, which you can use to do whatever you want.

[gregturn]

Arjen Poutsma commented

Correction: There is a good reason I made these classes non-public.