You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by bu...@apache.org on 2009/06/07 20:38:39 UTC

DO NOT REPLY [Bug 46888] Unable to Create XMLX509IssuerSerial from valid Element

https://issues.apache.org/bugzilla/show_bug.cgi?id=46888





--- Comment #3 from Edgar Higgins <ed...@gmail.com>  2009-06-07 11:38:36 PST ---
Hey Colm,

Thanks for your comments, I do appreciate you taking the time to look into
this.

You were correct, it seems that the Weblogic SAAJ SOAP Message Factory is not
interning the namespace.  So, the parsed soap message fails in XML Security
ElementChecker.

This means that WS-Security is not compatible with the SOAP Message Factory
that is included with Weblogic 10.3.

I have spent some time trying to find a work around, and the best I could come
up with is to override the default message factory used by Spring-WS (which
would otherwise resolve to Weblogic's MessageFactory implementation).  The
configuration is as follows:

    <bean id="wsTemplate"
class="org.springframework.ws.client.core.WebServiceTemplate">
        <property name="interceptors" ref="wsInterceptors"/>
        <property name="marshaller" ref="wsMarshaller"/>
        <property name="unmarshaller" ref="wsMarshaller"/>
        <property name="messageFactory" ref="wsMessageFactory"/>
    </bean>

    <bean id="wsMessageFactory"
class="org.springframework.ws.soap.saaj.SaajSoapMessageFactory">
        <property name="messageFactory">
            <bean class="???.MessageFactoryImpl"/>
        </property>
    </bean>

I'm fairly confident this will work, but I haven't found a SAAJ 1.3
implementation yet (hence the ???.MessageFactoryImpl).  I used Sun's
implementation, and ran into an UnsupportedOperationException - It seems they
didn't actually implement MessageFactory.createMessage(), so that won't work. 
I started down the path of using the axis2 implementation, but that had
dependencies, and I don't really like the idea of mixing Spring WS with Axis2
libraries (although, there is probably nothing wrong with it).

I would still suggest that this bug be reconsidered.  I believe XML-Security is
relying on the implementation of the parsers, rather than the specification.  I
have attached a new fix for this bug that will give the same performance
benefits when using a parser that interns the namespace, but that will also
work with parsers that do not intern the namespace.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.