2 Replies Latest reply on Apr 10, 2012 10:58 AM by spyhunter99

    Bizarre Serialization Problem

    spyhunter99 Novice

      I'm looking at WS-Discovery, which is a UDP SOAP over multicast based protocol that is similar to UDDI, except way similier and it's adhoc. In the Java world, there's only one implementation that I've found which is here http://code.google.com/p/java-ws-discovery/.


      I can get the samples to run correctly in outside of the Jboss world and it works as advertised. Basically, there is a service that listens for "Probe" messages on UDP and replies to the requestor based on the search criteria. Cool.


      The problem I ran into boils down to a serialization issue. Escentially, when I run outside of Jboss, it's using the standard default JDK soap libraries, aka Sun's JAXB serializers, message factories and marshallers. In Jboss, it's actually creating JbossWS classes which fill these roles. For everything I've done up until now, this have been just fine with this arrangement. Enter WS-Discovery (at least this guys implementation).


      First, some implementation details that are worth mentioning and are important to understanding the problem. It's not SOAP over HTTP, it's over UDP which means this guys library serializes the message, then writes it to transport. In order to facilitate this, the author created a custom class which has functions such as getSOAPmessage and getSOAPbody etc with a toString function that serializes the message. The problem is related to how the message is structured and as you can imagine, using the JDK's classes it correctly serializes but with the JbossWS classes it does not. Specifically, the part with the search results is null under JbossWS.



      It appears that the actually loading of the JAXB specific stuff happens with this line, which unfortunately doesn't leave me with any flexiblity as far as forcing it to the JDK's vs JbossWS.

           MessageFactory  factory = MessageFactory.newInstance(soapProtocol);


      At the point of serialization, the SOAP message itself is





      Long story short, there is a way to force the class loading from a specific instance to use Sun's JDK? Or perhaps would it be better if I found either an alternative implementation or write my own.


      Esscentially what I would like to do is to write a JAX-WS handler which does a web service callout using WS-Discovery to find the correct url, thus eliminating the need for configuration files. It obviously would need to work in a variety of soap stacks, more than just JbossWS and Sun's default implementation.

        • 1. Re: Bizarre Serialization Problem
          Alessio Soldano Master

          I'm missing most of the details of what you really want to achieve, however, few considerations:

          1) FYI the SAAJ MessageFactory.newInstance(soapProtocol) basically ends up doing a classloader getResource lookup. So the actual message factory being used to create soap messages is controlled by the META-INF/services/javax.xml.soap.MessageFactory file you might have in a jar archive included in your classpath. JBossWS-Native has its own implementation of SAAJ API...

          2) also considering JBossWS-Native is EOLed, you should probably try JBoss AS 7 which defaults to JBossWS-CXF stack. That works with the SAAJ RI (what's in JDK), so you would most probably avoid any issue here

          1 of 1 people found this helpful
          • 2. Re: Bizarre Serialization Problem
            spyhunter99 Novice

            I was hoping you saw this. Thanks for the info. Long story short, I need to be able to support handlers within Tomcat and Jboss EAP as old as v5.0 which means that the soap stack in place could be metro, cxf, axis, jbossws native, etc. Anyhow, thanks I'll look into it.