XStream
  1. XStream
  2. XSTR-71

xstream.fromXML() requires XPP3 where xstream.toXML doesn't

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.0
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Now that the default driver for new XStream() is the XppDriver, there seems to be a dependency on the XPP3 library in the xstream.fromXML(String) method. However, according to the commit comment of XStream.java, revision 1.42, XPP3 should still be optional...

      "Default XStream constructor uses XPP3. Updated docs to recommend including this jar (although it is still optional)"

      The dependency is apparent in the XStreamSerializationTestCase.java, revision 1.1, in the Picocontainer CVS.
      http://cvs.picocontainer.codehaus.org/java/picocontainer/src/test/org/picocontainer/defaults/XStreamSerialisationTestCase.java

      In it, new XStream() is used, implicitly using the XppDriver (although an explicit DomDriver has been used in revision 1.2 to avoid this problem). Here's the error...

      Testcase: testShouldBeAbleToSerialiseEmptyPico(org.picocontainer.defaults.XStreamSerialisationTestCase): Caused an ERROR
      XPP3 pull parser library not present. Specify another driver. For example: new XStream(new DomDriver())
      java.lang.IllegalArgumentException: XPP3 pull parser library not present. Specify another driver. For example: new XStream(new DomDriver())
      at com.thoughtworks.xstream.io.xml.XppDriver.createReader(Unknown Source)
      at com.thoughtworks.xstream.XStream.fromXML(Unknown Source)
      at com.thoughtworks.xstream.XStream.fromXML(Unknown Source)
      at org.picocontainer.defaults.XStreamSerialisationTestCase.testShouldBeAbleToSerialiseEmptyPico(XStreamSerialisationTestCase.java:20)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

      So, it looks as if the XPP3 library is required. I would think that XStream would fall back to the DomDriver if XPP3 doesn't exist in the classpath.

      Jake

        Activity

        Hide
        Jacob Kjome added a comment -

        BTW, this also affects Prevayler's use of XStream. We use new XStream() and when we do xstream.fromXML(Reader), we get the same exception as I originally reported for the Picocontainer project. Here's a partial stacktrace...

        A snapshot using XStream's XML serialization will be taken every 20 seconds...
        java.lang.IllegalArgumentException: XPP3 pull parser library not present. Specify another driver. For example: new XStream(new DomDriver())
        at com.thoughtworks.xstream.io.xml.XppDriver.createReader(Unknown Source)
        at com.thoughtworks.xstream.XStream.fromXML(Unknown Source)
        at org.prevayler.implementation.snapshot.XStreamSnapshotManager.readSnapshot(XStreamSnapshotManager.java:98)

        Jake

        Show
        Jacob Kjome added a comment - BTW, this also affects Prevayler's use of XStream. We use new XStream() and when we do xstream.fromXML(Reader), we get the same exception as I originally reported for the Picocontainer project. Here's a partial stacktrace... A snapshot using XStream's XML serialization will be taken every 20 seconds... java.lang.IllegalArgumentException: XPP3 pull parser library not present. Specify another driver. For example: new XStream(new DomDriver()) at com.thoughtworks.xstream.io.xml.XppDriver.createReader(Unknown Source) at com.thoughtworks.xstream.XStream.fromXML(Unknown Source) at org.prevayler.implementation.snapshot.XStreamSnapshotManager.readSnapshot(XStreamSnapshotManager.java:98) Jake
        Hide
        Grégory Joseph (old account) added a comment -

        Well, the exception tells you what to do, doesn't it? I think optional means just that, you have the option not to use.

        (I personnaly prefer that over a failover scenario where xstream would use the DomDriver if it doesn't find xpp)

        Show
        Grégory Joseph (old account) added a comment - Well, the exception tells you what to do, doesn't it? I think optional means just that, you have the option not to use. (I personnaly prefer that over a failover scenario where xstream would use the DomDriver if it doesn't find xpp)
        Hide
        Joe Walnes added a comment -

        After some discussion with users, I'm going to leave it how it is. Most users prefer knowing which driver is being used over XStream choosing an appropriate one. For example, you may intend to use XPP but due to an error in configuration not have the library in the path.

        So, I'm sticking with the explicit option.

        Show
        Joe Walnes added a comment - After some discussion with users, I'm going to leave it how it is. Most users prefer knowing which driver is being used over XStream choosing an appropriate one. For example, you may intend to use XPP but due to an error in configuration not have the library in the path. So, I'm sticking with the explicit option.
        Hide
        Jacob Kjome added a comment -

        Greg,

        Thanks for pointing out the obvious. And your comment was partially what I was getting at; fallback behavior. The other issue I was getting at is spelled out in the bug report: "xstream.fromXML() requires XPP3 where xstream.toXML doesn't", otherwise known as an "inconsitency".

        Joe,

        I guess it is fine to require explicit configuration of the driver, but then why the default constructor implicitly using XPP3??? That's the opposite of explicit last time I checked. And, of course, as I mentioned above, there's the inconsistency issue. Why do things work fine in xstream.toXML(), but fail in xstream.fromXML()? Is toXML() falling back to the DomDriver, or is no XML parser used in toXML()? If the latter then, I guess the issue, as reported, is resolved, otherwise, the issue hasn't yet been addressed and should be reopened. Even then, there's still the contradiction in your statement about wanting to define the driver explicitly, but then having the default constructor use the XPP3 driver implicitly.

        Thoughts?

        Jake

        Show
        Jacob Kjome added a comment - Greg, Thanks for pointing out the obvious. And your comment was partially what I was getting at; fallback behavior. The other issue I was getting at is spelled out in the bug report: "xstream.fromXML() requires XPP3 where xstream.toXML doesn't", otherwise known as an "inconsitency". Joe, I guess it is fine to require explicit configuration of the driver, but then why the default constructor implicitly using XPP3??? That's the opposite of explicit last time I checked. And, of course, as I mentioned above, there's the inconsistency issue. Why do things work fine in xstream.toXML(), but fail in xstream.fromXML()? Is toXML() falling back to the DomDriver, or is no XML parser used in toXML()? If the latter then, I guess the issue, as reported, is resolved, otherwise, the issue hasn't yet been addressed and should be reopened. Even then, there's still the contradiction in your statement about wanting to define the driver explicitly, but then having the default constructor use the XPP3 driver implicitly. Thoughts? Jake
        Hide
        Grégory Joseph (old account) added a comment -

        I am, again, going to point out the obvious
        > is no XML parser used in toXML()?
        Well, no, since parsers are used to parse, while toXml builds xml, doesn't parse it.

        (Not exactly sure how xstream builds its xml though)

        Show
        Grégory Joseph (old account) added a comment - I am, again, going to point out the obvious > is no XML parser used in toXML()? Well, no, since parsers are used to parse , while toXml builds xml, doesn't parse it. (Not exactly sure how xstream builds its xml though)
        Hide
        Grégory Joseph (old account) added a comment -

        I am, again, going to point out the obvious
        > is no XML parser used in toXML()?
        Well, no, since parsers are used to parse, while toXml builds xml, doesn't parse it.

        (Not exactly sure how xstream builds its xml though)

        Show
        Grégory Joseph (old account) added a comment - I am, again, going to point out the obvious > is no XML parser used in toXML()? Well, no, since parsers are used to parse , while toXml builds xml, doesn't parse it. (Not exactly sure how xstream builds its xml though)

          People

          • Assignee:
            Unassigned
            Reporter:
            Jacob Kjome
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: