Announcement Announcement Module
Collapse
No announcement yet.
Possible bug in spring-oxm JAXB support Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Possible bug in spring-oxm JAXB support

    I am trying to use the JAXB support of spring-oxm version 0.9.1 with the JAXB 2.0 implementation of Sun.

    I believe that may be a bug in the JaxbMarshaller.afterPropertiesSet() method at line 112.

    The call to unmarshaller.setValidating() is deprecated according to:

    https://jaxb.dev.java.net/nonav/jaxb...dating(boolean)

    and always throws the mentioned exception

  • #2
    Issue added

    I created an issue

    Link: http://opensource.atlassian.com/proj.../browse/SWS-22

    Comment


    • #3
      Originally posted by routis
      I am trying to use the JAXB support of spring-oxm version 0.9.1 with the JAXB 2.0 implementation of Sun.

      I believe that may be a bug in the JaxbMarshaller.afterPropertiesSet() method at line 112.

      The call to unmarshaller.setValidating() is deprecated according to:

      https://jaxb.dev.java.net/nonav/jaxb...dating(boolean)

      and always throws the mentioned exception
      Yep, that's a bug. Thanks for creating the JIRA issue, I will fix it soon.

      The reason for this bug is quite obvious: I only tested it with JAXB 1.0, since JAXB 2.0 is not final yet. That said, the JAXB 2.0 API seems pretty stable, so I guess we can support it. Which poses the following question:

      Are there any other features when using JAXB 2 in combination with OXM which you currently miss?

      Comment


      • #4
        Originally posted by poutsma
        Yep, that's a bug. Thanks for creating the JIRA issue, I will fix it soon.
        Thanks for the quick reply.

        Originally posted by poutsma
        Are there any other features when using JAXB 2 in combination with OXM which you currently miss?
        Currently, by avoiding the call to the JaxbMarshaller.setValidation(boolean) the JaxbMarshaller works fine except that JAXB does not validate xml. This is very annoying - at least in my case.
        I believe that in JAXB 2 someone has to use the method Unmarshaller.setSchema(schema), in order to validate the xml. I will investigate this.

        Comment


        • #5
          Ok here are the results of my investigation

          In JAXB 2 in order to validate an xml against a schema you need something like the following:


          // References to the schema files
          Source[] schemas = new Source[]{
          new StreamSource(schemaFile1),
          new StreamSource(schemaFile2)
          };

          // Obtain schema object
          SchemaFactory schemaFactory = schemaFactory.newInstance(XMLConstants.W3C_XML_SCH EMA_NS_URI);
          Schema schema = schemaFacotry.newSchema(schemas);

          // create unmarshaller
          JAXBContext jCtx = JAXBContext.newInstance("foo.bar");
          Unmarshaller unmarshaller = jCtx.createUnmarshaller();
          unmarshaller.setSchema(shema);


          As of version 0.9.1 of spring-oxm the JAXBContext is not exposed via getter/setter methods, but it is constructed internally by JaxbMarshaller. So, in my opinion, currently I the JaxMarshaller cannot validate xml against xml schema.


          Please note that I am very new to JAXB and maybe my conclusions are not valid.

          Comment


          • #6
            Originally posted by routis
            Currently, by avoiding the call to the JaxbMarshaller.setValidation(boolean) the JaxbMarshaller works fine except that JAXB does not validate xml. This is very annoying - at least in my case.
            As an alternative for validation you could use the PayloadValidatingInterceptor, that is: if you are use the marshaller within a Spring-WS Web service.

            Originally posted by routis
            I believe that in JAXB 2 someone has to use the method Unmarshaller.setSchema(schema), in order to validate the xml. I will investigate this.
            I believe you are correct. We can support this using the same principle as PayloadValidatingInterceptor, i.e. offer a schema property, in which you can inject a schema resource. This wouldn't work under JAXB 1, though, which is kinda ugly.

            We could separate the JAXB2 functionality from the JAXB1 stuff by offering a special Jaxb2Marshaller. I don't like this idea too much, though, since the basic functionality (i.e. marshalling) is the same in both the versions. Only the offered properties are different.

            I'll think about this.

            Comment


            • #7
              Originally posted by poutsma
              As an alternative for validation you could use the PayloadValidatingInterceptor, that is: if you are use the marshaller within a Spring-WS Web service.
              Intresting solution, but it is not correct for me. In my project I do work with xml but not with web services.
              I would prefer the autonomy of spring-oxm.


              Originally posted by poutsma
              We could separate the JAXB2 functionality from the JAXB1 stuff by offering a special Jaxb2Marshaller. I don't like this idea too much, though, since the basic functionality (i.e. marshalling) is the same in both the versions. Only the offered properties are different.
              I just did implement Jaxb2Marshaller and Jaxb1Marshaller that inherit from a common parent that provides the basic functionality. Since Jaxb1 and Jaxb2 are not configured in the same way in my opinion:
              1) Either there have to be two distinct classes (Jaxb1Marshaller and Jaxb2Marshaller)
              2) Or a single JaxbMarshaller that is not responsible for initializing the JAXB marshaller and unmarshaller. Perhaps a factory could be responsible for that.

              Comment


              • #8
                I fixed this issue in CVS, and basically took the approach you suggested. The JaxbMarshaller has been refactored into an AbstractJaxbMarshaller, a Jaxb1Marshaller and a Jaxb2Marshaller. Each concrete class allows for different properties to be set (i.e. the Jaxb1Marshaller has a validating property, while the Jaxb2Marshaller has a schema resource).

                Could you please checkout the Spring-WS sources and see whether this works for you?

                Cheers,

                Comment


                • #9
                  Dear poutsma,

                  Thanks for the fix. Unfortunately, I cannot access the cvs at work (due to restrictive company firewall policy), but I will find a way to see the new code.

                  By the way I don't understand why the various libraries are in cvs. Since I don't have a broadband internet connection it's very difficult to checkout the project.

                  Are there any plans for migrating to SVN like spring-rich-client?

                  Comment


                  • #10
                    Originally posted by routis
                    Thanks for the fix. Unfortunately, I cannot access the cvs at work (due to restrictive company firewall policy), but I will find a way to see the new code.

                    By the way I don't understand why the various libraries are in cvs. Since I don't have a broadband internet connection it's very difficult to checkout the project.
                    The libraries that are in cvs cannot be found on ibiblio, for instance JAXB can only be downloaded from SUN directly. You could look at the code using the Browse CVS functionality of SourceForge here.

                    Originally posted by routis
                    Are there any plans for migrating to SVN like spring-rich-client?
                    Yes, there are plans for SVN. Stay tuned.

                    Comment


                    • #11
                      Originally posted by poutsma
                      The libraries that are in cvs cannot be found on ibiblio, for instance JAXB can only be downloaded from SUN directly.
                      I believe JAXB libraries are ibiblio


                      Originally posted by poutsma
                      You could look at the code using the Browse CVS functionality of SourceForge here.
                      In viewcvs I cannot see any of the classes that you mentioned (Jaxb1Marshaller and Jaxb2Marshaller). Do you commited them on HEAD?

                      Originally posted by poutsma
                      Yes, there are plans for SVN. Stay tuned.
                      Great news

                      Comment


                      • #12
                        Originally posted by routis
                        I believe JAXB libraries are ibiblio
                        That looks interesting. Unfortunately, the release posted there is EA3, while I have used RC1. I could not get EA3 to work; it gave me IncompatibleClassChangeErrors while using the JAXB 1.0 functionality. RC1, released on the 17th of March, fixes this. When RC1 jars show up on ibiblio, I will use them.

                        Note however that the link you posted is a Maven2 repository, and as far as I know I cannot use maven2 repos with Ivy (Ivy is the dependency management tool we use). There are plans to switch to Maven2, so that would fix this issue altogether.

                        Originally posted by routis
                        In viewcvs I cannot see any of the classes that you mentioned (Jaxb1Marshaller and Jaxb2Marshaller). Do you commited them on HEAD?
                        Yes, I did. But I forgot that the anonymous cvs of sourceforge has been disabled for something like three weeks now, as you can read here. It will be up by the end of April, the administrators say. Totally unacceptable, but there is nothing I can do about it .

                        I'll talk to the other project leads to see what they think about the sourceforge situation. Thanks for the support and interest!

                        Comment

                        Working...
                        X