-
Suggestion
-
Resolution: Low Engagement
-
None
-
None
Background:
Confluence 7.10.0 upgraded XStream to 1.4.14 and in an effort to help vendors seamlessly navigate through this significant change, confluence-compat-lib was offered with helpful methods that can fetch the correct XStream for plugins running on both pre and post XStream upgrade Confluence version with relatively low effort on the vendors' side.
This ticket is a request for an extension to that functionality as originally brought forward in CONFSERVER-60576.
Summary:
I would like to suggest further extension to confluence-compat-lib to cover the non-backward compatible XStream#getMapper method. To give you a bit of context, we are using the new registerConverter method. However, our custom Converter extends from XStream's MapConverter whose constructor requires a com.thoughtworks.xstream.mapper.Mapper. This was easily obtained by running XStream#getClassMapper on XStream 1.1.1 but since this was renamed on XStream1.4.14 to XStream#getMapper, we have resorted to using reflections to cater for both cases. It would be great if the compatibility library could expose this method to enable us to register convertors more efficiently and rely completely on XStreamManagerCompat ensuring better future proofing.
@Component
public class XStreamManagerCompat {
...
/**
* Retrieve the Mapper.
*
* @return the default Mapper in XStream 1.4.x or the default ClassMapper in XStream 1.1.1.
*/
public Mapper getMapper() {
delegate.getMapper();
}
}
Thanks again for your help in making this transition as seamless as possible and for considering the suggestion brought forward here.
Ahmed.
Given we are moving into 9.0 and there have been low traction on this feature request, we would request plugins to use Bandana's API as much as possible. We're closing this suggestion now. Appreciate you bringing it up.