Preparing for Confluence 9.0 - EAP out now

[WendyR]

Preparing for Confluence 9.0 - EAP coming soon

We’re excited to share our plans for the upcoming platform release for Confluence Data Center.

Confluence 9.0 focuses on security, with many enhancements to our security posture and capabilities. It will also host a range of accessibility and supported platform improvements that sets the product up as a trusting host of features to be delivered in the 9.x series. It and will include some breaking changes and significant platform upgrades…

Predicted scope of breaking changes in 9.0

As development on Confluence 9.0 progresses, we’ll be able to provide much more specific details of any breaking changes that could affect your apps. Our intention today is to give you a broad overview of the areas that we’re focusing on, especially those we expect to impact your apps.

As always, the future Preparing for Confluence 9.0 page will be updated regularly with more details. We’ll do our best to include any breaking changes as early as possible to give you enough time to make changes to your app before the official Confluence 9.0 release.

Here are some of the things we’re working on:

• Dark theme for Confluence
• Removing support for Java 11
• Upgrading our platform, Atlassian and third-party components, and Atlassian-maintained libraries
• Upgrading our editor
• Cleaning up our code base by removing deprecated code paths including ‘gray APIs’ (unsupported third-party and cross-product libraries)
• Upgrading the editor
• Continuing to resolve critical accessibility issues

Many of these changes will enable us to improve Confluence more frequently without breaking your apps or requiring you to do significant testing and reword when these changes.

Test with Early Access Program (EAP) releases

Early Access Program (EAP) releases provide an opportunity to test your app with the upcoming platform release. We plan to release regular 9.x EAP milestones, in addition to the weekly 8.x EAP milestones. Get the latest milestones from the Early Access Program downloads page.

If you have questions or feedback for us, drop a comment below. You can also raise a feedback ticket.

Frequently asked questions

We know that platform releases have many unknowns. Here are some questions that we wanted to address with the information we currently have.

When will Confluence 9.0 be released?

We can’t provide an exact date at this stage, but we’re currently targeting mid-2024. We’ll continue to release regular Confluence 8.x versions while we work on 9.0.

Will there be breaking changes to APIs?

Yes, we expect there may be some breaking changes to the REST API or Java API. We aim to communicate these as early as possible.

Are there any restrictions to who can access to Confluence 9.0 EAP milestones?

No, the EAP is open to everyone.

Will there be additional resources to help us prepare?

Yes! The Preparing for Confluence 9.0 page is the source of truth for all resources. We’ll link to any additional materials, such as migration guides or Community posts for particular changes.

Here’s to the next stage of Confluence’s evolution,

The Confluence team

[scott.dudley]

Hi @WendyR

For the mentioned Struts XSRF protection changes, I have two questions:

1. Where is the documentation for the mentioned “permittedMethods Action parameter in the Struts module descriptor”? Also, will this work only in <struts> modules, or can it be applied to <xwork> modules too? Furthermore, will this parameter be gracefully ignored in earlier versions of Confluence that do not support it?
2. To save every vendor from having to do this step individually, can the Confluence team document the Confluence version availability of the @PermittedMethods and @HttpMethodRequired annotations? If neither of these would be usable in the earliest currently-supported version of Confluence 7.x (meaning that vendors cannot easily ship cross-compatible products), can Atlassian please provide a confluence-compat-lib solution, or else verify that there is a cross-version way to do this with step #1 above?

[Kusal]

Hi @scott.dudley

Apologies for the lack of detailed documentation in this area. The xwork and struts modules are equivalent in 8.x and only differ in name. There are some differences in these modules between 7.x and 8.x due to the underlying library upgrade but none that impact this particular change.

This particular Action parameter is supported from 7.x and can be utilised as follows:

<action name="index" class="com.atlassian.confluence.core.ConfluenceActionSupport">
    <param name="permittedMethods">GET</param>
    <result name="input" type="dispatcher">/admin/console.action</result>
    <result name="success" type="dispatcher">/admin/console.action</result>
</action>

Or if you wish to use an annotation based approach instead, the @com.atlassian.xwork.PermittedMethods annotation and its deprecated predecessor are also supported from 7.x.

These configuration options are not changing in 9.x - only the default behaviour in their absence.

[AndreasEbert]

@Kusal, thanks for the detailed info.
I wondered how permittedMethods allows multiple values, so I searched in Confluence source code (an old download, before source-downloads were hidden…), and found the docu in com.atlassian.xwork.interceptors.RestrictHttpMethodInterceptor, that it’s a comma-separated list:

/** ...
An example of the parameter configuration:
<action name="blah" class="com.example.MyAction">
  <param name="permittedMethods">GET, POST, PUT</param>
  <result name="success" type="redirect">/index.html<result>
</action>
Note that method names are case sensitive, and all upper case. They must correspond to one of the values of the HttpMethod enum.
...
*/

I agree with @scott.dudley that some public documentation is needed for this, especially now that with Confluence 9 this gets required!

[rw-dennis]

Hello!
Looking at the EAP and from the list of removed APIs/packages we have com.google.common for example. So we follow the recommendation and bundle guava in the app:

        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>33.0.0-jre</version>
            <scope>compile</scope>
        </dependency>

But as stated already in November by the community (Include/exclude list for RFC-24 Data Center grey API removal - #2 by scott.dudley) I get this error that I’m not allowed to scope compile this dependency:

[WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed with message:
make sure platform artifacts are not bundled into plugin
Found Banned Dependency: com.google.code.findbugs:jsr305:jar:3.0.2
Found Banned Dependency: com.google.guava:guava:jar:33.0.0-jre

What should I define the as? How do I proceed? Thank you.

[rw-dennis]

I would also echo the previous comments on documentation but in the context of the atlassian-related packages/classes that are now removed. Are these part of some maven dependency we could add, or would we need to use alternative APIs an if so, what are those APIs and do they work backwards to the lowest supported Confluence version (7.x) to avoid having a compat-lib or splitting the app build in two?

As an example com.atlassian.confluence.userstatus.* is mentioned on the Confluence 9 list of removals here: Deprecated code paths removed in 9.0 | Confluence Data Center and Server 8.7 | Atlassian Documentation
But these were not mentioned in the 8.7/8.8 docs (https://developer.atlassian.com/server/confluence/get-your-apps-ready-for-gray-api-removal/)
Furthermore the java API is not marked deprecated (e.g. for FavouriteManager) in the latest java docs so we don’t get any clue as to what to use instead for each method.

[WendyR]

Hi Dennis. I’ve notified our devs of your question, so they should be along shortly to answer. We’ll also address any missing info. Thanks for providing some examples.

[mtran]

You can define an exclude for maven-enforcer-plugin like this to exclude these dependencies from the ban dependencies list

<build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-enforcer-plugin</artifactId>
                    <executions>
                        <execution>
                            <id>ban-milestones-and-release-candidates</id>
                            <phase>validate</phase>
                            <goals>
                                <goal>enforce</goal>
                            </goals>
                            <configuration>
                                <rules>
                                    <banVersionDeps>
                                        <excludes>                                            
                                            <exclude>com.google.code.findbugs:jsr305</exclude>
                                            <exclude>com.google.guava:guava</exclude>
                                        </excludes>
                                    </banVersionDeps>
                                </rules>
                            </configuration>
                        </execution>
                    </executions>
                </plugin>
             </plugins>
        </pluginManagement>
</build>

Let me know if that works for you.

[jens]

Hi @WendyR,

could we please get some more info on what ‘Upgrading our editor’ exactly means? Is this about a ‘simple’ TinyMCE upgrade or will you bring the Cloud editor to DC?

We have some apps that are deeply integrated into the editor so more details here would help us in planning the compatibility efforts better.

Thanks,
Jens

[scott.dudley]

Hi @Kusal,

Would you be able to upgrade confluence-compat-lib so that it does not prevent apps from loading on Confluence 9.0? If any app incorporates the latest 1.6.1 of the compat lib, it induces a transitive dependency on the com.atlassian.fugue package, which is no longer OSGi-exported in 9.0, so it causes the plugin to fail to load.

I suspect that Atlassian is not getting a ton of feedback on the 9.0 EAP yet because many vendors probably cannot even load their plugins to test them. The fact that the OSGi load fails on the first missing package (and that it notes only the first problem and none of the subsequent problems) is an aggravating factor, because an app can be missing dozens of packages with the latest changes, and you have to fix them one by one. (I know it’s an OSGi thing and not something you can probably fix yourselves. And I guess trying to load against Conf 8.8 helps because it just spits out warnings rather than failing, but I don’t know if there are guarantees that the lists of missing packages are the same.)

As a workaround, I found that one can ask BND to explicitly remove packages from the auto-generated manifest using the following notation. (This will allow your app to work, at least up until the point where the classloader tries to load the referencing class.)

                        <Import-Package>
                            com.atlassian.plugin.web.conditions,
                            com.atlassian.plugin.web.conditions.*,

                            <!-- ... other packages here ... -->

                            !com.atlassian.fugue.*,
                            *
                        </Import-Package>

It can also be difficult to even locate where the “banned” package references are coming from when they result from transitive dependencies. I hope there is an easier way that someone can share, but I ended up running Maven inside a debugger and setting up a conditional breakpoint inside BND.

To save other people the trouble of figuring this out, here is what I did:

• temporarily throw the following into any POM to get the classes loaded in your IDE:

        <dependency>
            <groupId>biz.aQute.bnd</groupId>
            <artifactId>biz.aQute.bndlib</artifactId>
            <version>3.5.0</version>
            <scope>test</scope>
        </dependency>

• Start Maven with: MAVEN_DEBUG_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5099 " atlas-mvn package
• Launch your JVM debugger (attach to port 5099)
• Set a conditional breakpoint on aQute.bnd.osgi.Analyzer#analyzeJar line 2382. (Use the “download sources” feature in your IDE to make sure you have the source JAR installed.)

						for (PackageRef p : clazz.getReferred()) {
>>>>						referred.put(p);
							refs.add(p);
						}

• set the breakpoint to fire conditionally when p.toString().contains("fugue") (or whatever banned class name it is you’re looking for)
• when the breakpoint fires, clazz will contain the name of the referencing class and jar will point to the offending artifact

[Kusal]

Hi @scott.dudley,

That OSGi dependency is currently required for Confluence 6.x compatibility and we will remove it in the next major version of confluence-compat-lib.

For now you may exclude it, as you’ve already done (this will mean your plugin will not be able to leverage 6.x compatibility), or optional import it (as you’ve likely already done with the Struts OSGi dependencies that are present in 8.x but not 7.x).

Thank you for noting this however - and we are still looking to bring more comprehensive documentation for confluence-compat-lib in the future.

[scott.dudley]

Hi @Kusal,

You will probably also notice this when porting confluence-compat-lib to 9.0, but for the benefit of others who are stumbling through the process, that library also includes a transitive dependency on the banned com.atlassian.util.concurrent package.

If you run into OSGi load problems referencing com.atlassian.util.concurrent, you will have to exclude it too from the Import-Packages list as mentioned above.

Scott

[ramakrishna]

I am getting the below error, can someone help

Caused by: org.osgi.framework.BundleException: Unable to resolve com.tensixtwo.conf.latexmath [306](R 306.0): missing requirement [com.tensixtwo.conf.latexmath [306](R 306.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.confluence.importexport.resource)(version>=9.0.0.m07)(version<=9.0.0.m07)) Unresolved requirements: [[com.tensixtwo.conf.latexmath [306](R 306.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.confluence.importexport.resource)(version>=9.0.0.m07)(version<=9.0.0.m07))]

And which product and data versions we need to use it in our pom?

<confluence.version>7.4.0</confluence.version>
<confluence.data.version>7.4.0</confluence.data.version>

[aorlov]

Hello.
I’m getting the error for Confluence 9.0.0-m08:

Caused by: org.osgi.framework.BundleException: Unable to resolve com.my.app [302](R 302.0): missing requirement [com.my.app [302](R 302.0)] osgi.wiring.package; (&(osgi.wiring.package=com.opensymphony.module.propertyset)(version>=1.3.0.21Nov03)(version<=1.3.0.21Nov03)) Unresolved requirements: [[com.my.app [302](R 302.0)] osgi.wiring.package; (&(osgi.wiring.package=com.opensymphony.module.propertyset)(version>=1.3.0.21Nov03)(version<=1.3.0.21Nov03))]
	at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4398)
	at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
	at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:1006)
	at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:992)
	at com.atlassian.plugin.osgi.factory.OsgiPlugin.enableInternal(OsgiPlugin.java:404)
	... 106 more

But I don’t use opensymphony in my project directly (no imports, no dependencies).

Are the any known solutions? Help will be appreciated.

Kind regards

[scott.dudley]

(In other news, Confluence 9.0.0-m08 is now available.)

Hi @aorlov,

The problem is likely coming from a dependency.

You can troubleshoot this at the source by attaching a debugger to your Maven build and setting breakpoints for the banned package as I described above.

An quick alternative that (mostly) also works is to go through all of the bundled .JARs in your target/classes/META-INF/lib build directory, unzip each .JAR, and grep all of the corresponding class files for the name in question.

[aorlov]

Maybe it will help somebody.

Overriding plugin is not working for me (I use confluence-maven-plugin), but these settings are working:

Kind regards

[scott.dudley]

PSA: the latest Confluence 9.0 milestones (including up to at least 9.0.0-m08) exhibit different OSGi behavior if you have dev mode enabled.

The deprecated OSGi exports are apparently only withdrawn if dev mode is disabled. Even if everything loads fine for you in dev mode on 9.0, it may very well fail to load in production when all of the packages disappear.

It can also be helpful to enable the following log level in Confluence to debug the new OSGi loading: set com.atlassian.plugin.osgi.hook.dmz to DEBUG.

[jens]

@scott.dudley @aorlov To find what classes use a certain package you can also temporarily set

<extractDependencies>true</extractDependencies>

in the confluence-maven-plugin <configuration>, then run a simple mvn package and then just grep for the package name in the target/classes folder.

I found that to be more convenient than manual unzipping a ton of JARs.

[rlander]

I lost several hours to this yesterday, I can’t really think of a reason why Atlassian would choose to make OSGi behaviour differ in dev mode.

Initially Atlassian did not document that the Upload app button had been removed from the UPM by default. We noticed it came back if dev mode was enabled, and updated our tooling accordingly. We now know there is a system property specifically for enabling UPM uploads.

As we had left dev mode enabled, our app appeared to start and mostly function on Confluence 9. This was very confusing, as all the information points to the app needing a lot of work to function.

Thankfully after some rubber duck debugging with @scott.dudley we worked out what was going on.

[GorkaGalloBustinza]

Hello @AndreasEbert ,

Thanks, I’ve tried in Confluence 7.19.15 and Confluence 8.7.1 adding some permittedMethods in the descriptor to an action and it works.

Regards,
Gorka.