Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
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
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)
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) 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.
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. 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
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 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)
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) 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)
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) 
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