Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XStreamMarshaller forces XPP dependency [SPR-11635] #16258

Closed
spring-issuemaster opened this issue Mar 31, 2014 · 5 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Mar 31, 2014

Jacob Daly opened SPR-11635 and commented

In org.springframework.oxm.xstream.XStreamMarshaller the XStream object is declared at class level:

private final XStream xstream = new XStream();

As the no-argument constructor is used, XStream is constructed using the XppDriver class. This therefore creates a runtime dependency on XPP.

It is therefore not possible to use other driver implementations such as DomDriver or StaxDriver.

Would it not be better to assign the xstream variable in a constructor of XStreamMarshaller? This would allow extension of the class in order to provide another driver implementation.


Affects: 3.1.4

Issue Links:

  • #15054 XStreamMarshaller - no way to set a MapperWrapper on XStream
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 31, 2014

Juergen Hoeller commented

XStreamMarshaller's construction of an XStream instance and its general configuration capabilities have been revised for Spring Framework 4.0. I'm afraid this is not going to be backported to the 3.x line.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 31, 2014

Jacob Daly commented

Thanks for the prompt response Juergen.

I just had a quick look at the 4.0.3 source and there would still be a dependency on XPP, due to the following line:

private final XppDriver fallbackDriver = new XppDriver();

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 31, 2014

Juergen Hoeller commented

Ah ok, so you're concerned about the XPP dependency in the classpath, not about using the XppDriver by default... That's a good point, we should be able to make our fallback driver initialization lazy there.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 9, 2014

Juergen Hoeller commented

We're lazily initializing a default XppDriver if necessary now, instead of pre-initializing a fallback driver. To be available in the upcoming 4.1 and 4.0.4 snapshots.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Apr 9, 2014

Jacob Daly commented

Excellent, thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.