Thank you for posting these updates, as well as the advance information for 7.10.
I am hoping to get more information about the XStream changes in 7.10. I have already reviewed the Xstream 1.4 upgrade page and I have questions:
How is the Xstream 1.4 serialization output expected to be different? (Is a trivial example possible?)
I am looking at some of our software (which uses double marshalling) and trying to see how it might need to be modified, but my brief tests with 7.10.0-xstream-14-m02 are not showing any obvious difference in output. I am not sure if this is because we are only storing primitives, if we got lucky, or some other reason.
Is there any expected difference if the legacy system’s data is loaded via XML backup versus an in-place upgrade of an older Confluence version? (I recognize that the Bandana upgrade task is not yet released, but even without this, my tests with existing data restored by XML still seem to work on 7.10.0-xstream-14-m02.)
The Xstream upgrade page suggests that double-marshalling is bad behavior. While I don’t disagree in theory, I believe that apps are using it to work around issues with using the raw Xstream instance in Confluence itself, which was (at least at one time) not app/plugin-friendly.
It has been a long time since we deployed this double-marshalling workaround, but according to the notes, we were previously seeing classloader-related problems on unmarshalling. I think the root cause was something within the XStream ecosystem holding on to references to an earlier version of a class, and then trying to instantiate the wrong (earlier) version of the class which was in a different OSGi bundle. This meant that things worked mostly okay on first install, but if the app was ever upgraded, a number of problems ensued. Some of our notes reference problems in a cluster as well, so there could also have been additional problems there related to caching, broadcasting, etc.
Note that this is a much more likely problem for third-party developers to run into versus Atlassian itself, since I believe that most Confluence system plugins are upgraded as part of full Confluence upgrades, as opposed to the runtime installations and upgrades that third-party apps end up requiring for day-to-day use.
This item is thus not so much a question, but I wanted to mention this to provide some context to the admonishments that are on the Xstream upgrade page mentioned above. If we end up having to migrate the data, we will most likely get rid of Bandana entirely and put the data in AO to avoid having to deal with this mess. If we do end up migrating away from Bandana, I am hoping that we can use the legacy method of getting an XStream instance and still be able to read the old data (see item below as to why).
The suggestion to use ConfluenceXStreamManager is helpful guidance, but this is challenging to use directly if the app must support earlier versions of Confluence (which effectively everyone has to). It may require either reflection or some Maven submodule hacks, plus version detection, to allow the code to coexist nicely with older versions.
It would be nice if a compatibility library could be released that can be consumed by third-party developers, like has been done for some other new Confluence features. And hence my questions above about wondering what the data format looks like, since we are trying to determine if using the new XStream is truly necessary or if we can skip it.
Thanks for any guidance you can provide!