Confluence Server 7.9 beta is available now

Confluence Development Confluence Data Center Announcements
, ,
1

Hi everyone, this week we released a beta for Confluence 7.9. There are changes in this release that may directly affect 3rd-party apps.

New in 7.9

To find out what’s in this release, check out the Confluence 7.9 beta release notes.

Get started

Download the beta from our site to start testing your app for compatibility with the changes. Be sure to take a look at our Preparing for Confluence 7.9 guide to find out what you need to do to make your app compatible. We’ll update that page regularly, so keep an eye on it to see any changes.

Cheers,

The Atlassian Confluence team

1 Like
2

Thank you @NathanMudaliar.

I verified that 7.9.0-m41 is the most recent release tagged ‘eap’ in your docker repo. That is not this “7.9 beta 1” you are talking about is it?

Now that Atlassian is using the ‘eap’ label in docker hub it is easy for us to upgrade our EAP/beta server. Just need to restart the docker container: Docker, but we can’t upgrade to 7.9-beta1 if it isn’t tagged in docker hub.

Our docker-compose.yml contains the ‘eap’ tag like this:

confluence:
        image: atlassian/confluence-server:eap

Just fyi, I don’t know how many people keep their test servers up to date using a docker container and your images/tags. It’s very convenient.

One of your release managers recently fixed your docker repo because Atlassian had forgotten about the ‘eap’ tag and it wasn’t being used. We noticed it and asked for that to be remedied and it was, someone added the ‘eap’ label again… but we can’t use it if Atlassian doesn’t use it. I can find that release manager’s name if you’d like, else could you please contact them and make sure that beta releases like this are using the eap tag so we can just restart our EAP docker container to get upgrades?

Thanks!

1 Like
3

Hi @TureHoefner, I just raised the issue with the team.

2 Likes
4

Hi @NathanMudaliar,

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:

#1

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.

#2

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.)

#3

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).

#4

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!
Scott

2 Likes
5

Hi @scott.dudley, I’ve passed your questions on to the XStream team. They will reply here with answers.

6

Hi Scott

Thanks for for getting onboard with XStream and providing valuable feedback. We appreciate your timely feedback and would incorporate few things from it in next EAP releases. Please find your answers below:

#1
You have spotted it correctly, we believe its because you are storing primitives or Java 4/earlier class objects. Chances of getting Conversion exception are low as we have found only few classes which have got their custom Converters in newer XStream. We have made a list of few of them which you can use as a reference:

  • URI:
    in 1.1.1

<java.net.URI serialization=&quot;custom&quot;>\n" +
" <java.net.URI>\n" +
" <default>\n" +
" <string>http://www.atlassian.com/&lt;/string&gt;\n&quot; +
" </default>\n" +
" </java.net.URI>\n" +
"</java.net.URI>"

         while with 1.4.x, it is

<uri>http://bulldogwiki.internal.atlassian.com/&lt;/uri&gt;

  • Date types, but in this case its just the format change from server timezone representation to UTC based format.

<date>2020-10-07 13:09:15.442 UTC</date>

  • Enum types don’t have reference attribute anymore.

#2
We don’t expect many issues, but there might be some scenarios we would look at while doing UpgradeTask.
Since you are using primitives, we don’t expect any breakages in your data unmarshalling.

#3
Correct, we experienced the same with non-bundled plugins. There can be Class cast issues because of different class loaders. To support this scenario, we plan to provide one more method
ConfluenceXStream getPluginXStream(ClassLoader classLoader);
in ConfluenceXStreamManager. This would allow plugins to pass-on OSGi classloader from the calling class. We will try to push it in EAP soon.

#4
We are working on getting a compat class which can help plugin devs keep a single version of plugin across Confluence versions. This will also be required by our team-cal to keep the same version across connie.

1 Like
7

The team addressed the issue. Now we apply the eap tag to whatever EAP download has the highest 7.x version number.

1 Like
8

Thanks @NathanMudaliar.

Reading the release notes, we saw that there are changes in the index architecture. This might be why the flush index queue action (/admin/flushindexqueue.action) is not available. Is there any other action that does the same?

Regards,
Andrea

9

Hi @andrea, I’ll confirm the new actions with the team on Monday and get back to you.

10

Hi @andrea, the flush index queue action is now split into /admin/flushcontentindexqueue.action and /admin/flushchangeindexqueue.action for the different indexes.

3 Likes
11

Hi everyone, just wanted to let you know we’ve released a new milestone (7.10.0-xstream-14-m03) for the XStream upgrade work.

Download the milestone, or head to XStream 1.4 upgrade for information about the most recent update.