Confluence 10.0 release EAP is available now

Hi everyone,

A Confluence 10.0 EAP milestone is now available. EAP releases provide a snapshot of our work in progress and give you an opportunity to test and fix your apps before the final release.

As usual, we’ll be releasing weekly milestones and betas during the development of Confluence 10.0, so head to Preparing for Confluence 10.0 to find out what’s changed.

Get the latest EAP

If you have any problems with an EAP release, please raise an issue to let us know. The earlier we know about problems, the more time we’ll have to fix them before the final release.

Enjoy!

The Atlassian Confluence team

We now announce Confluence Data Center releases and more in the Atlassian developer changelog. Subscribe to the changelog to receive the latest updates.

3 Likes

I have asked some questions about the Bandana removal: BandanaManager deprecation in Confluence 9.3

1 Like

Cannot use this EAP. The App Management fails instantly, and we can’t install our app through the REST API because it gets rejected by 500 Unauthorized.

There’s also a mixture of Jakarta 1.x and 2.x versions of the same libs. It would probably make sense to complete the transition to 2.x first.

2 Likes

Which Confluence version goes with which platform version? On https://developer.atlassian.com/platform/marketplace/dc-apps-platform-7/ there is no mentioning of version 10 (probably because it is an EAP …).

Is it Atlassian Repository: com/atlassian/platform/dependencies/platform-public-api/8.0.0-jakarta-m017/ (latest release date close to the release date of Confluence)?

Where could I lookup the correct platform version for a given Confluence version? Could this information be added to the release note or on the post in the developer community?

It is probably obvious, but it is not obvious to me … :smile:

@rr1, I once stumbled over atlassian / platform-module-usage / wiki / new-platform — Bitbucket, which contains a version-matrix showing which platform-version is used in which product-version.

2 Likes

Hi @metin

Could you or anyone else experiencing this provide further information such as error logs so we can investigate?

Generally, when developing your plugin you will want to import the com.atlassian.confluence:confluence-plugins-platform-pom to inherit the correct dependency management.

Further dependency information can be found in the published POMs themselves. Here is the project POM for EAP1: https://maven.artifacts.atlassian.com/com/atlassian/confluence/confluence-project/10.0.0-m16/confluence-project-10.0.0-m16.pom

1 Like

I used the docker image tagged eap, and after Confluence starts and I’ve logged in, when I select Manage Apps, it explodes. The log is full of

javax.servlet.ServletException: jakarta.servlet.ServletException: javax.servlet.ServletException: jakarta.servlet.ServletException: javax.servle
t.ServletException: jakarta.servlet.ServletException: javax.servlet.ServletException: jakarta.servlet.ServletException: javax.servlet.ServletException:
 jakarta.servlet.ServletException: 

Shouldn’t be difficult to reproduce.

2 Likes

I have the same error:

Also when replacing com.atlassian.xwork with com.atlassian.struts like

import com.atlassian.xwork.SimpleXsrfTokenGenerator;
import com.atlassian.xwork.XsrfTokenGenerator;

with

import com.atlassian.struts.xsrf.SimpleXsrfTokenGenerator;
import com.atlassian.struts.xsrf.XsrfTokenGenerator;

I had a compilation error saying class file for jakarta.servlet.http.HttpServletRequest not found and I had to add to my pom.xml the section

        <dependency>
            <groupId>jakarta.servlet</groupId>
            <artifactId>jakarta.servlet-api</artifactId>
            <version>${jakarta.servlet-api.version}</version>
            <scope>provided</scope>
        </dependency>

Shouldn’t be automatically included ? It seems the Confluence server package is missing some core dependencies.

Another question: the new Struts 7 dependencies upgrade are breaking the compatibility with Confluence 9.xx and older ? Meaning if we compile our plugin to be compatible with Confluence 10 we are no more able to install it on previous versions ?

About the Bandana Removal can you provide some code example to fetch the old data from the BANDANA storage in order to migrate old data to another method, like AO ?

1 Like

First problems:

  1. WebSudoManager = 10.0.0-m16 - still using javax.servlet
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

void startSession(HttpServletRequest request, HttpServletResponse response);


  1. ServiceExceptionMapper

Error

RestExceptionMapper.java:[11,8] cannot access jakarta.ws.rs.ext.ExceptionMapper
[ERROR]   class file for jakarta.ws.rs.ext.ExceptionMapper not found

pom.xml

<dependency>
        <groupId>com.atlassian.confluence</groupId>
        <artifactId>confluence-restv2-server-api</artifactId>
        <scope>provided</scope>
</dependency>

Java

import com.atlassian.confluence.rest.v2.api.exception.ServiceExceptionMapper;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import javax.ws.rs.ext.Provider;

@Provider
public class RestExceptionMapper extends ServiceExceptionMapper {

    private static final Logger log = LoggerFactory.getLogger(RestExceptionMapper.class);

    @Override
    protected void _annotateThisClassWithProvider() {
        ...
    }
}


  1. class file for javax.servlet.http.HttpServletRequest not found - this error occurs in more code even though javax.servlet.* is not used in the code

Error

[cut] cannot access javax.servlet.http.HttpServletRequest
[ERROR]   class file for javax.servlet.http.HttpServletRequest not found

Java

import com.atlassian.struts.xsrf.XsrfTokenGenerator;
import jakarta.servlet.http.HttpServletRequest;

XsrfTokenGenerator xsrfTokenGenerator = ComponentLocator.getComponent(XsrfTokenGenerator.class);
...
xsrfTokenGenerator.generateToken(HttpServletRequest);

Cheers
Adam

1 Like

Attempt to install app via REST API also fails:

Failed to authenticate - status code: 500 - response text: <?xml version="1.0" encoding="UTF-8" standalone="yes"?><status><status-code>500</status-code><message>'java.util.Locale com.atlassian.sal.api.message.LocaleResolver.getLocale(javax.servlet.http.HttpServletRequest)'</message><stack-trace>Please contact your admin passing attached Log's referral number: 957fa50c-5817-4737-ba03-09f765ea18cd</stack-trace></status>

Seems like the same root cause to me - reference to javax.servlet.http.HttpServletRequest

Hi all,

Thanks for the quick feedback.

We’ve identified the issue with UPM which is preventing plugin installs from the web UI and REST API. This will be rectified in the next EAP.


Most dependencies need to be explicitly specified. However, you should inherit the version management by importing com.atlassian.confluence:confluence-plugins-platform-pom. See my dependencyManagement snippet further down.


In general, yes.


There is no new dedicated API for migration, you should use the existing BandanaManager API, which will have its mutative APIs blocked.


This will be rectified in the next EAP.


The JAX-RS and Jersey dependencies are currently pinned to the incorrect versions in confluence-plugins-platform-pom due to some technical hurdles. This will be fixed in a later EAP but you may work around this issue by adding the following additional dependencyManagement entries for now.

2025-03-10 update: The temporary workaround entries below are no longer required!

<dependencyManagement>
    <dependencies>
        <dependency>
            <!-- Temporary workaround -->
            <groupId>org.glassfish.jersey</groupId>
            <artifactId>jersey-bom</artifactId>
            <version>3.1.9</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>
        <dependency>
            <!-- Temporary workaround -->
            <groupId>jakarta.ws.rs</groupId>
            <artifactId>jakarta.ws.rs-api</artifactId>
            <version>3.1.0</version>
        </dependency>
        <dependency>
            <!-- Temporary workaround -->
            <groupId>jakarta.inject</groupId>
            <artifactId>jakarta.inject-api</artifactId>
            <version>2.0.1</version>
        </dependency>
        <dependency>
            <groupId>com.atlassian.confluence</groupId>
            <artifactId>confluence-plugins-platform-pom</artifactId>
            <version>${confluence.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

We are aware of a handful of OSGi services which still leak the old javax.servlet.* APIs. Whilst not ideal, you may workaround this by depending upon both the old and new Servlet APIs. You may also need to specify an optional OSGi import. Please ensure you remove this workaround once these services are corrected in later EAPs.

<dependencies>
    <dependency>
        <groupId>jakarta.servlet</groupId>
        <artifactId>jakarta.servlet-api</artifactId>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <!-- Temporary workaround -->
        <groupId>javax.servlet</groupId>
        <artifactId>javax.servlet-api</artifactId>
        <scope>provided</scope>
    </dependency>
</dependencies>
3 Likes

We’re also aware that the jakarta.xml.bind packages are currently not OSGi available - this will be rectified in the next EAP.

2 Likes

EAP2 is now available - we welcome any further feedback on issues you are facing.

Hi @Kusal

For EAP2, can you clarify the scope of the Bandana removal? I understood that only mutative options were to be blocked, but I am seeing this error on plugin install.

For example, is the entire com.atlassian.bandana package being intentionally marked for internal use only? If so, what is the suggested alternative for read-only access to migrate old data?

Caused by: org.osgi.framework.BundleException: Unable to resolve com.myplugin [283](R 283.0): missing requirement [com.myplugin [283](R 283.0)] osgi.wiring.package; (osgi.wiring.package=com.atlassian.bandana) Unresolved requirements: [[com.myplugin [283](R 283.0)] osgi.wiring.package; (osgi.wiring.package=com.atlassian.bandana)]

Also, for future EAPs, is there any possibility of Atlassian publishing a changelog of sorts for any changes made to the OSGi export denylist? I understand that we can technically find this out by unzipping the internal Confluence JAR and diffing the public-api and package-exports.yaml files, but it would be nice if this information could be posted publicly so that not everyone has to reinvent the wheel.

2 Likes

@Kusal Where do you plan to store user macros? At the moment we can retrieve them using the “atlassian.confluence.user.macros” key from bandana…

I see that some legacy packages (like javax.servlet) are still exported in the OSGi context in -m20.

Are these expected to be fully removed? If so, do you know when?

I am exploring to see if there is any way at all to create a cross-major app. I was hoping to verify if a particular feature of OSGi might work, which is that optional imports will override any locally-defined classes declared within a bundle.

This could allow, for example, apps to declare their own shim version of javax.servlet classes that extend the corresponding jakarta.servlet class, but to also optionally-import javax.servlet from the host context.

On Confluence 9.x, the javax.sevlet classes will be imported directly and the shim layer would not be used. On Confluence 10, it would end up invoking the parent jakarta classes through the shim.

The problem is that for this to work, javax.servlet cannot be exported in Confluence 10, hence my question about its removal.

Thanks for raising this - this was indeed an oversight and we will restore these packages to public API in the next EAP.

We don’t intend to make any major changes to publicly exported packages from here on, other than the removal of Java EE 8 packages. If you are already going down the path of extracting the Confluence JAR, I’d recommend consulting com/atlassian/confluence/impl/util/OsgiAcceptanceTest-expected-public-api-exports.txt instead, which resolves the mentioned YAML files against packages actually on the classpath.

What is the use-case for retrieving them?

Yes, but towards the end of the development cycle. There are still a number of public APIs which leak/depend on the legacy packages and removing these prematurely could render some marketplace apps uninstallable.

Whilst this is not an approach we recommend due to the complexity and tech debt introduced, you may find this Atlassian library helpful in your experimentation.

5 Likes

@Kusal this looks incredibly useful. Thanks a lot for sharing it!

1 Like

@Kusal we can have our forms (ConfiForms) configuration grouped as a user macro and need to read the template → macro configuration. Helps our users to group and reuse form configurations

Just tried building one of our apps using 10.0.0-m20 (which I’m assuming is the latest EAP build).

(Builds fine against 9.3.1).

Got the following error (I added line breaks for readability):

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  07:14 min
[INFO] Finished at: 2025-02-19T12:57:54+11:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal com.atlassian.maven.plugins:confluence-maven-plugin:9.1.11:run (default-cli) on project [REDACTED]:
 Unable to find/resolve artifact.:
 Failed to read artifact descriptor for com.atlassian.synchrony:synchrony-proxy:war:5.0.0-CONFSRVDEV-34351-m02:
 The following artifacts could not be resolved:
 com.atlassian.confluence:confluence-plugins-platform-pom:pom:9.3.0-CONFSRVDEV-34351-m01 (absent):
 Could not find artifact com.atlassian.confluence:confluence-plugins-platform-pom:pom:9.3.0-CONFSRVDEV-34351-m01 in atlassian-public
 (https://maven.atlassian.com/repository/public) -> [Help 1]

Is this a known issue?
I’m using AMPS 9.1.11 if that makes any difference.

We usually wait until later in the EAP cycle before testing, but we wanted to get a head start this time around, and possibly we should wait a bit longer?