Announcement Announcement Module
Collapse
No announcement yet.
JiBX unmarshalling - DOM error Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JiBX unmarshalling - DOM error

    I am using the JiBX marshaller/unmarshaller - when the XML message reaches the the endpoint class [a type of AbstractMarshallingPayloadEndpoint] I get an error that reads: "JibxMarshaller does not support unmarshalling of DOM Nodes..." - am I missing a property setting in the bean(s)??

    I am using build .9 so I had to declare the JibxFactory bean (etc.) which is no longer required in 1.x, was this a bug that has been resolved in a more recent build?

    thanks!
    Ron

  • #2
    It is not a bug, it is a feature of Jibx mentioned in both the Javadoc and the reference manual:

    Note that the JibxMarshaller only operates on raw I/O streams, and not on DOM nodes, nor SAX handlers.
    Since SAAJ is based on DOM, you cannot use it in combination with Jibx. Rather than convert the entire DOM tree to a byte buffer, and unmarshal from that, I decided to throw an exception and mention the behavior in the Javadocs, since the conversion process might be slow.

    I could add an option to the JibxMarshaller to allow for this conversion, but I think the whole speed advantage of Jibx will go away.

    It might be that this feature was fixes in the recently released Jibx 1.1, I have not checked that version out yet.

    Comment


    • #3
      how do I fix this problem then?

      OK- so how do I correct this? Is it a fix on the client side such that it does not send and XML SOAP block?? Or is it a fix on the server side not to convert the incoming XML to a SOAP message (so I should use a different dispatcher?)?

      Can I get some more help/guidance on this one please? Any example code/cofiguration would be great.

      Comment


      • #4
        Originally posted by rwilcom
        OK- so how do I correct this? Is it a fix on the client side such that it does not send and XML SOAP block?? Or is it a fix on the server side not to convert the incoming XML to a SOAP message (so I should use a different dispatcher?)?

        Can I get some more help/guidance on this one please? Any example code/cofiguration would be great.
        I'm sorry if I wasn't helpful before, let me improve on that.

        The current implementation of the JibxMarshaller does not work with DOM, and therefore SAAJ. So you can either use a different Marshaller such as the Jaxb2Marshaller, or you can wait until I provide a fix for this.

        My preferred way of fixing this is figuring out if Jibx 1.1 does support DOM, and use that. If that is not possible, I can convert incoming DOM documents to streams, and unmarshal from those. This conversion behavior will probably be optional, because it can decrease performance, and not all users will want that.

        I've created a JIRA issue for this here, which you can track for progress.

        Hope that makes things a little clearer,

        Comment


        • #5
          Ok, thanks - so lets say I wanted to use JiBX to take advantage of the performance? How do I do that without using DOM/SAAJ? I have control of both client and server so I am not against sending an XML I/O stream - but the question is how does it get dispatched to the proper marshaller/endpoint on the server side? The examples I have must parse to the SOAP body (payload element name) then on to the endpoint based on the value of the first element (tag) - is there some direct way to dispatch to an endpoint?

          Correct me on this (?) - but the negative side to using JiBX is that it is not going to employ the standard web services protocol since the client can't send an XML SOAP (XML) message?

          Comment


          • #6
            Originally posted by rwilcom
            Ok, thanks - so lets say I wanted to use JiBX to take advantage of the performance? How do I do that without using DOM/SAAJ?
            I am currently working on a way to do this. The idea is to use Axiom instead of SAAJ for generating SOAP messages. Axiom is based on StAX, and JiBX supports StAX as well. However, the JibxMarshaller doesn't yet, but I'm working on it. So, when I'm done with this feature, you can use the AxiomSoapMessageContextFactory (instead of the SaajSoapMessageContextFactory), and all should be well.

            Originally posted by rwilcom
            I have control of both client and server so I am not against sending an XML I/O stream - but the question is how does it get dispatched to the proper marshaller/endpoint on the server side? The examples I have must parse to the SOAP body (payload element name) then on to the endpoint based on the value of the first element (tag) - is there some direct way to dispatch to an endpoint?
            You can use an endpoint mapping which is not based on the content, such as the SoapActionEndpointMapping, which uses the SOAPAction HTTP header. It is used in the airline sample.

            Cheers,

            Comment


            • #7
              So - let me make sure I am clear on this thread -

              As of today's Spring WS release the JiBX implementation is not ready for use as a marshalling endpoint?

              or

              It "is ready" if you use the SOAP action header for dispatch and the cleint sends the body of the SOAP message as the bytes of the serialized object (or should the body contain the serialized JiBX output XML as a stream of bytes?)? Sorry if I sound a bit confused!

              Bottom line - going back to one of the original posts - I should just use JAXB2 if I want to move foward with my development efforts and want to have standard SOAP XML as the client's message format?

              thanks...

              Ron

              Comment


              • #8
                Originally posted by rwilcom
                As of today's Spring WS release the JiBX implementation is not ready for use as a marshalling endpoint?
                Yes, that is the bottom line. It is a bit more subtle than this (see below), but in the end you cannot use Jibx as a Marshaller when using the AbstractMarshallerEndpoint today. That said, I hope to have this fixed by the end of the week.

                Originally posted by rwilcom
                Bottom line - going back to one of the original posts - I should just use JAXB2 if I want to move foward with my development efforts and want to have standard SOAP XML as the client's message format?
                Yes you could, or you can wait a couple of days to have the JibxMarshaller fixed.

                Here's the longer version of the above. Just some background knowledge, which changes nothing to the answers I gave. You may ignore it .

                Having "standard SOAP XML" has nothing to do with the marshaller used. The central concept in SWS SOAP is the SoapMessage. There a two concrete implementations: SaajSoapMessage, which is based on a DOM tree, and AxiomSoapMessage, which is based on a StAX XMLStreamReader. The AbstractMarshallerEndpoint basically takes the body of the request message (using getPayloadSource()), and unmarshals that to a request Object. The response object is marshalled into the body of the response message (using getPayloadResult()). So the marshaller only reads from/writes to the body, and not the entire message.

                Now, because SAAJ is based on DOM (i.e. getPayloadSource() returns a DOMSource), you currently cannot use it in combination with JiBX, because
                the current JiBX version doesn't do DOM, only input streams. By the end of the week, you can use it, but it is not so fast because it converts SAAJ's DOM tree into a input stream first, and then unmarshals from that.

                Luckily, JIBX 1.1 also supports StAX XMLStreamReaders. So by the end of the week, you will able to use the AxiomSoapMessage with the JibxMarshaller (both using XMLStreamReaders), and have optimal, streaming performance.

                Cheers,

                Comment


                • #9
                  got it

                  Ok - I think I have this all straight now.

                  Thanks for all of your help!
                  Ron

                  Comment


                  • #10
                    Arjen,

                    Is this why I must return a DOMSource in my endpoint's implementation of getResponse() ? Because I get exceptions when I try to return anything but that...i.e. StreamSource/SAXSource.

                    Comment


                    • #11
                      Originally posted by decrypt
                      Arjen,

                      Is this why I must return a DOMSource in my endpoint's implementation of getResponse() ? Because I get exceptions when I try to return anything but that...i.e. StreamSource/SAXSource.
                      No, that's shouldn't be necessary. What Marshaller are you using?

                      Comment


                      • #12
                        Actually I'm using AbstractSaxPayloadEndpoint

                        If I attempt to return anything but a DOMSource in getResponse(), I get exceptions on the server-side.

                        Comment


                        • #13
                          Hmm that sounds like a bug. Could you create an issue with the exact configuration and errors you get?

                          Thans,

                          Comment


                          • #14
                            I will try...but I don't ever get to see the actual exception...it start trying to create a soap fault response and then it errors on the fact that there is already a response object created...so there may be two bugs at play here...

                            Comment


                            • #15
                              I replaced WebLogic's XML related jars (Xerces, Xalan, xml-apis) and now i can return a SAXSource or a StreamSource just fine now.

                              Comment

                              Working...
                              X