Confluence 8.8 beta is available now

This week we released a beta for Confluence . There are some changes in this release that may directly affect third-party apps.

New in 8.8

To find out what’s in this release, check out the Confluence 8.8 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 8.8 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.

The Atlassian Confluence team


Hi @WendyR ,

Thanks for the post. I went through the beta release notes and discovered this:

Say ‘G0oD8y3’ to plaintext user directory server passwords

Secret manager now includes support for user directory password encryption. When configuring user directories, the supplied server password will be automatically AES encrypted. For existing instances that have user directories already configured, passwords will be encrypted automatically upon upgrade to Confluence 8.8.0. Confluence will automatically generate encryption keys and store them in the keys directory.

Our app needs to retrieve information from the LDAP(s) configured as user directories. To do so, it retrieves the configuration data in Confluence and opens a connection to the LDAP. Of course, for LDAPs that request authentication, this requires the password.

The question is: will apps be able to retrieve the decrypted password? Or would apps have to decrypt the password using the encryption keys in the keys directory?

Any insights on this would be appreciated.


I don’t know if they solved it like for Bamboo 9, but for Bamboo we had to switch from using the CrowdDirectoryService to DirectoryManager to access the directories.

With the CrowdDirectoryService we only got the directories with encrypted passwords thus it was not usable. Once switching to DirectoryManager fixed it. But I have not checked Confluence beta yet.



It is becoming increasingly difficult to track what happened to all the feedback that was given (primarily by @scott.dudley) on both the Confluence 8.7 EAP, Confluence 8.8 EAP and grey API CDAC threads and how they influenced changes between the EAP and the current BETA release.

In addition, can you please also provide any insights in the timeframes with regard to the release of Confluence 8.8, and whether or not the Confluence team is open to a 8.9 release prior to Confluence 9 or an extended EAP program for Confluence 9 itself in order for Marketplace Partners to asses the impact of grey API removal on their apps?


What happened with* and how an app can have a REST API endpoint now?

1 Like

What happened to com.atlassian.plugin.webresource.WebResourceUrlProvider?

I need the getStaticPluginResourceUrl(String moduleCompleteKey, String resourceName, UrlMode urlMode) method. Is there any alternative?

The javadoc says to use VelocityFriendlyPageBuilderService but I get errors on startup:

NoSuchBeanDefinitionException: No qualifying bean of type 'com.atlassian.confluence.setup.velocity.VelocityFriendlyPageBuilderService' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}

Also I run “atlas-run” now and get license problems. Is the dev license not set automatically anymore? Any help would be great.

com.atlassian.confluence.license.exception.LicenseException: Failed to retrieve license from storage.
[INFO] [talledLocalContainer] 	at
1 Like

Dear developer team,

I’m trying not to comment often, but there is a fundamental problem with the way this change it being handled: It is not being documented in the documentation pages. Maybe you expected it to be something small that can be contained at the developer level, but with the last revisions, since the change in the CQL in 7.19/7.20/8.0 actually, we have vastly incomplete documentation.

  • How to do things right is not documented,
  • Documentation is provided as CDAC comments instead of proper pages,
  • You rely on CDAC comments, hearsay, ancient knowledge from longstanding experts, archeology, access to sources (which are not public anymore) to document the APIs,
  • Since there is no single reference for how plugins should do things, the next team at Atlassian who works on changing the platform will have no history on this subject.
  • It is threatening the stability of plugins, and thus, it prepares for a huge setup where customers will be unhappy with dangerous bugs piling up.

You are also setting an unfair playing field, advantaging the big vendors, who have access to the right contacts to get the right information. The rest of us struggle with guessworking how APIs work. I don’t even think large vendors are happy with the situation.

  • Please stop trying to document with just comments on CDAC,
  • This is not a side-project. Please perform an impact analysis, and prove it by telling us how to do for every expected API. It is not a “We’re just upgrading library numbers” project.
  • Please enroll the help of copywriters at Atlassian,
  • Please write extensive documentation pages on how to do things right. We want to do things right!

Example with basic areas of public interest:

  • There is no page (up-to-date, without deprecated code that doesn’t compile) with how to perform a CQL search,
  • There is no documentation with how to get a page by ID, or a space by key,
  • There is no documentation (with an approved method, not hacks and Reflection API) about how to extend the RTE and the Macro Editor, as I saw Confluence 9.0 comes with a “new editor”, whatever it means,
  • There is no documentation about how to use the WebResourceModule properly,
  • There is no documentation about how to insert JavaScript using an approved method, let alone Typescript, AMD modules or React. Yes, I know, there is a page, but that page only contains outdated information.

Each comment above, from other vendors, is also a source of areas which need to be covered in the documentation.

Please enroll tech writers and do not release Confluence 8.8 until you have performed the impact analysis.

Thank you very much.


Unfortunately (perhaps reassuring?) we don’t have any exclusive backchannels that are of much use. Of course we have a TPM as a large partner, but very rarely do we escalate engineering problems via that path for DC apps.

We had prior knowledge of the grey API removal, as a few vendors/partners were consulted for early feedback. No specific details around removed APIs were given ahead of public announcements.

In terms of implementing the required changes, we’re working with the same public information as every other vendor, and will be providing our feedback/grievances in public.

Even as a large partner, it is incredibly difficult to get a path to an engineer within Atlassian to troubleshoot things, source code (RIP) is our best resource.

Personally I can only think of one occasion in recent memory where ScriptRunner had a direct line to an Atlassian engineer for a DC issue. Specifically the Log4j 2 fiasco.


Hello @clouless
In one of the other threads about Confluence 8.8 compat , @mkemp
mentions that there are changes in the web-resource manager APIs ( ) … maybe he knows the story for WebResourceUrlProvider and getStaticPluginResourceUrl?

I am also running into problems with web-resource APIs in my classpath, not sure but they might be related because mine are also web-resource API classes: when building against 8.7.1 it fails because com.atlassian.plugin.servlet.DownloadableResource is not available. It looks like maybe the “old” web-resource transform APIs are now gone and the switch to the “new” APIs is mandatory for 8.7+? I’m not sure: … I think I will refactor my web-resource-transformer implementation to use the “new” API per that doc.

1 Like

Before I get into specifics, just wanted to say that internally the issues with communication have been raised again today. I’m sorry I’m not involved with coordinating everything at a high-level so I can’t give you more specifics. I do know all the upgrade guidance for the UI Platform has already been provided internally to those people so any future large scale announcements from us can include it. I can only talk about what falls in my domain, here’s everything to try complement what Confluence has already announced.

WRT to DC UI Platform, you should only expect large changes in Web-Resource Manager and WebFragments. Upgrade guidance is public in their repos, linked just there. You should not expect much else in other modules other than everything implementing/extending ModuleDescriptor changing to use the Atlassian replacement API for dom4j (this change is being propagated out from Atlassian Plugins). The other DC UI Platform modules include;

The jQuery plugin is used by each of the products, but each of the products pick the version they used, whether they use migrate, etc. So follow their announcements as you already are.

If we do AUI 10 there will be large scale vendor comms, consultations, planning, buffer time for adoption, or extremely narrow scope, etc. ATM there is zero capacity to even think about this so I wouldn’t worry about it.

WebResourceUrlProvider is basically just moving to the API module and package.

I’m guessing you’re asking because VelocityFriendlyPageBuilderService is no longer working for you? Which I’m guessing is because it’s from Confluence Core module so it’s not there in maven, so BND doesn’t pick it up. I’m not on the Confluence team, so I’m unsure if they’ll port this to their API module for the next major version of Confluence or not. I’ll ask them to respond to you.

For sure though you can use the WRM API directly, again just be aware it’s moving packages in the next major version.

com.atlassian.plugin.servlet.DownloadableResource has not gone anywhere AFAIK, it actually lives in atlassian-plugins, there’s this module called atlassian-plugins-webresource-common which was moved back into that repo (many, many years ago) because it contains a bunch of stuff that should really change with all the servlet code, but the WRM relies on it heavily.

What I think has happened is because Confluence has removed maven dependencies from their maven modules, you’ll need to declare a new dependency on this maven module to get it back again.

Not quite, I think it’s just the maven setup as talked about just above. All of Confluence 8 should retain runtime compatibility, but legacy transforms and conditions are no longer supported on web-resources as of the next major version of all products. That guide can be followed, except for the last step where it shows have to both, we only need the new UrlReading kind since all the products have support the UrlReading kind for a long while now.

Yes, we’ll update that doc.


Thanks @mkemp for pointing all that out :slight_smile:

About the WebResourceUrlProvider: It is completely gone, I cannot import it when building against the confluence.version=8.8.0-beta1:

I am doing basically (shortened) in my pom.xml



Is there anything I am missing? thanks a lot.

Regardless what I try I will get this error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.12.1:compile (default-compile) on project foo-macro: Compilation failure
[ERROR] /Users/clouless/github/foo-macro/src/main/java/io/..../macro/macro/base/[52,51] cannot find symbol
[ERROR]   symbol:   class WebResourceUrlProvider
[ERROR]   location: package com.atlassian.plugin.webresource

My IDE shows me atlassian-plugins-webresource-api-6.3.1.jar is referenced, and when inspecting the JAR file the class WebResourceUrlProvider is missing.

We are encountering challenges with our integration tests in Confluence 8.8.

The core of the issue appears to be the transfer of JsonNode objects between our application and the testing plugin. In Confluence 8.8, the OSGI system bundle now exports com.fasterxml.jackson packages, a change not present in 8.7. This introduction of new OSGI exports seems rather contradictory given the fact that it’s all about removing APIs.

I wonder if I should invest time in resolving this issue or just hope that this exports are gone again in the next beta.

1 Like

Ah, with some more details it makes sense now. For a very long time the file has lived not in the API maven module like it should have, but in the module atlassian-plugins-webresource (which is where basically everything used to live and we’re fixing that). From WRM 7.0 / Confluence 9.0 WebResourceUrlProvider will live in the API module because it’s API and you should just be able to depend on that.

We intentionally didn’t move the module things live in minor versions where possible to try avoid creating work and surprise. This has obviously created a new issue where Confluence has removed this implementation from their API so this maven dependency is not declared for you in Confluence 8.8 in attempt to prepare for Confluence 9.0. I’m sorry this is the case, but could you please add a dependency like so for supporting Confluence 7/8?


I picked the version of the WRM assuming you’re currently compiling once for all versions of Confluence and you’re supporting the 7.19 LTS version. Picking the eldest version in general ensures you can’t accidentally rely on API introduced in newer versions. You can use this page if it helps you tweak the version.

Hi @mkemp ,

Thanks a lot for being so communicative and helpful :slight_smile: :+1:

Ok I will keep that in mind for Confluence 9.

But just so that everything is clear: The method signatures will not change even in Confluence 9 and I can safely rely on the WebResourceUrlProvider class?

Background is: I am using a WebWorker (JavaScript) that has to load a JS file directly during runtime. And I am getting the URL to a special JS bundle via the WebResourceUrlProvider. This is a core app functionality I do not want to loose :slight_smile:

thanks a lot, and keep up the good work :muscle:

In an effort to highlight what I think is close to the average App vendor’s current situation - but also because I feel stuck and don’t see how to proceed - I’ll list some items I currently have issues with on the 8.8.0-beta1 build when building with that as my target.
(I’ll reply here since it’s the newer of the two 8.8 threads, and has the most recent reply mentioning WebResourceUrlProvider - but it’s always a toss up on where to look for/ask for information it seems)

Building towards 8.8.0-beta1 we’re seeing a couple of packages/classes that aren’t mentioned in the list either via the 8.7/8.8 Grey API page here
or on the 9.0 list of removed APIs here: Deprecated code paths removed in 9.0 | Confluence Data Center and Server 8.7 | Atlassian Documentation

Any comments on if these indeed are removed and if so, what we should use instead would be great!

  • com.atlassian.util.profiling.Ticker / com.atlassian.util.profiling.Timers - We’ve used these to ensure our code is logged when Performance profiling is enabled. Seems these are marked @Internal now. In 8.8 adding this as provided dependency works. Haven’t tried 9.0.
  • - We’re using this in our REST APIs to get Confluence-defaults for paginations. It was previously available via com.atlassian.confluence:confluence-rest-api. It’s still available via the 9.0 javadoc and not marked deprecated etc. Will it be (re)moved and if so, can we still access it somehow or what would be the alternative?
  • com.atlassian.confluence.userstatus is in the list. We use FavouriteManager which is not marked deprecated etc. An oversight? Can I include that in the pom? If not, I found RelationService as a potential candidate, but the documented new SpaceFavouriteRelation() is a class that doesn’t seem to exist.
  • As per this doc we have a RestExceptionMapper that extends Similar to the PaginationLimits this is no longer available. How should this be approached now? Could the documentation be updated?

Also for things like WebResourceUrlProvider and UrlMode etc it’s mentioned that it will “just” move package from e.g. com.atlassian.plugin.webresource.WebResourceUrlProvider or com.atlassian.webresource.WebResourceUrlProvider to com.atlassian.webresource.api.WebResourceUrlProvider. Since the old package isn’t available - is the black-on-white recommendation from Atlassian to ship two builds/jars then? Will there be some compat-library solution or can it be solved in some other way if I really want to avoid doing 2 builds.

Thank you in advance, any and all for any input or thoughts.


Absolutely can build on WebResourceUrlProvider, after it’s moved modules and packages in the next major it will have the same API shape as before.

One general piece of advice that happens to apply here is to use the versions of methods that have UrlMode as a parameter if you can. We see quite a few bugs in our own code where we’ve relied on AUTO which lead to the wrong behaviour in some cases.

Thanks so much for providing this extra context, it helps a lot with being able to figure out how to best serve plugin engineers. Sorry, we don’t have better support for web-workers.

No worries.

1 Like

Hey, I can’t help with all the Confluence specific questions sorry, I’ll message them internally there’s more questions.

I’m sorry I can’t help more generally (I understand this is just indicative of your larger point), but I can help with this specific issue. Atlassian Profiling marked all of those as @Internal before the Gray API project and we never came up with a better annotation to explain the nuance. Profiling should be used in two different ways;

  1. Adding additional context to existing metrics the product ships with, everything you need for that is in <artifactId>atlassian-profiling-api</artifactId>. Here’s the developer documentation with more info. One important call-out is to have this as <scope>provided</scope> as the products are providing the API. Another is that this is still relatively “new” in our products so you may need to make these optional OSGi package and OSGi service imports if you’re also supporting older product versions.
  2. Emitting your own metrics (developer docs). Profiling started off in life being exposed by the products, even before Gray API we came to the conclusion that instead marketplace apps (including our own) should be able to compile scope and manage the version of this. This allows greater flexibility in being able to control exactly how the metrics look, being able to communicate changes on major versions of marketplace apps, etc. So until the next major version of all products it’s still possible to either OSGi import or compile your own versions in products where that has always been the case. With the Gray API project it was decided to move all in on marketplace apps compiling their own versions, and Confluence’s POMs reflect that.

FWIW Atlassian Profiling remains open source, you can continue to use as much or as little of it as you’d like. The metrics space is moving fast and yet nothing really provides a complete API for everything, so it’s totally possible that you decide using Dropwizard, or Micrometer, or OpenTelemetry directly instead makes more sense for you.

If you have more suggestions on how to improve Atlassian Profiling or metrics in general feel free to create a new thread and tag me. I’ll try route internally to the right team, because I no longer own Atlassian Profiling.

That’s my personal recommendation until there is broader sweeping communication from someone like @MalathiVangalapati.

I see the chance of a compatibility runtime layer being developed as low because more broadly the compilation against Java 17 combined with some changes that cannot be done before the next major (because they would break compat early), particularly stemming from Atlassian Plugins as ruling out this working for most plugins. I’ll raise this request internally. Coming back to specifically web-resource manager, it’s of course a fair bit of work, but open source so in the meantime you could develop your own layer if you really wanted to.

There’s many degrees to which you can apply the techniques of splitting apps into smaller plugins AND using OBRs to bundle multiple plugins as one app on marketplace. It’s really hard to know you’re giving the best advice for each app without knowing things like; is the app architected in such a way that you can limit the API changes to a couple of small delegate plugins or is it best to fork the plugin? Is the app already composed of? Then on the business side; does the App only do new features in the next major? Are there breaking functionality changes in the App that should coincide with the product majors?

Specifically, what I think may work for some apps is having two versions building them as separate plugins, one which is for the old product versions, and the other for the next major and beyond. Then taking those plugins and bundling them into a single OBR. If you’d like me or someone else to build an example or documentation, let me know we can probably extract this into a new dev community thread too.

There’s lots of other techniques (off the top of my head) you can apply too that may help you avoid this that could be lower cost, but introduce their own trade-offs; optional package imports, optional service imports, reflective detection of features, reflective invocation, compile scoping our code (be careful, don’t export these packages), JS feature detection, overloading web-resource dependencies, using template functions provided from the products. There’s definitely some apps out there that are quite UI focused that are more likely to be able to apply these. If you want specific help with these, it might be best to create new threads individually and we can try and help you out.


I’ll take a moment to express my gratitude to you @mkemp , for jumping into these threads and providing answers relating to the components you own.

Whilst some of the answers may be disappointing, I’ll gladly take that over an absence of information or direct communication.

I’d love to see other engineers jumping in to field questions relating to their area of work.


@mkemp, thanks for your insightful answers!

Yes, that sounds very interesting, not just for our apps specifically, but also from a purely technical point-of-view; I didn’t know something like that is possible with OBRs.


I’ll throw this in here in case anyone struggles with replacing their deprecated web-resource-transformer with url-reading-web-resource-transformer, implementing a WebResourceTransformerFactory per:

I needed to see a working example to get me over the hump and I found one in the Confluence 8.1.3 source (ColoursWebResourceTransformer). I don’t think there are any in the public documentation and that source code helped me a lot.

1 Like