Preparing for Confluence 9.0 - EAP out now

scott.dudley · May 29, 2024, 3:50pm

@RomanStofeel The legacy OSGi plugin transformation process is described here (among other places). However, you don’t really want to be using it with Platform 7:

@kmacleod Multiple plugin vendors have fallen into the trap of trying to use <component-import> with Platform 7 and it seems like this is causing a lot of hang-wringing and wasted time (I believe there are half a dozen examples on just this thread).

Could Atlassian consider either removing support for <component-import> entirely (at least for non-Atlassian plugins), thereby forcing people to upgrade by showing a sensible error message? Alternatively, can you fix <component-import> so that it actually works on platform 7?

The root cause seems to be that the transformation process adds OSGi imports for all classes referenced by all methods of the imported class, plus all classes referenced by all methods of any superclasses. This prevents people from importing many non-trivial beans. If Atlassian is going to maintain <component-import>, I imagine that this auto-import-generation procedure needs to automatically skip any packages listed in the banned dependency list.

RomanStoffel · May 30, 2024, 8:14am

I switched to the Spring Java style configuration, which solved some OSGi issues, thanks.

However, I’m still stuck on ‘magically’ added OSGi imports, I get:

Caused by: org.osgi.framework.BundleException: Unable to resolve ch.mibex.confluence.include [301](R 301.0): missing requirement [ch.mibex.confluence.include [301](R 301.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.util.concurrent)(version>=3.0.0)(version<=3.0.0)) Unresolved requirements: [[ch.mibex.confluence.include [301](R 301.0)] osgi.wiring.package; (&(osgi.wiring.package=com.atlassian.util.concurrent)(version>=3.0.0)(version<=3.0.0))]
        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:408)
        ... 106 more

This import was added by Confluence. Our app doesn’t use com.atlassian.util directly.

My suspicion on what is happening:

We have a extractor2 declared in the atlassian-plugin.xml:

<extractor2 name="BitbucketFileExtractor"
          key="bitbucketExtractor"
          class="ch.mibex.confluence.include.search.BitbucketFileExtractor"
          priority="700">
</extractor2>

This extractor has a dependency to MacroManager. That interface has method with a com.atlassian.util.concurrent.LazyReference.
That triggers the import by at install time to com.atlassian.util.concurrent and then failing.

So, my questions are:

Can I register my extractor2 via Spring Java Configuration and hope it doesn’t trigger the OSGi import?
Or some other way to get it to run?

AndreasEbert · May 30, 2024, 2:43pm

According to com.atlassian.velocity.allowlist.impl.internal.PluginAllowlistConfigurator’s constructPluginClassAllowlist() and constructPluginPackageAllowlist() only Atlassian’s plugins are allowed to define these:

    private Set<Class<?>> constructPluginClassAllowlist() {
        ...
        for (var module : allowlistModules) {
            ...
            if (!isAtlassianModule(module)) {
                continue;
            }
            ...
        }
    }

    private static boolean isAtlassianModule(ModuleDescriptor<?> module) {
        return module.getPlugin().getPluginInformation().getVendorName().startsWith("Atlassian");
    }

RomanStoffel · May 31, 2024, 5:24am

Update on this.

Yes, my suspicion on the com.atlassian.util.concurrent import error was correct. If I remove any reference to the com.atlassian.confluence.macro.xhtml.MacroManager solves that issue. I tried to wrap & import it via Spring Java configuration, but the result is the same.
However, we do need the xhtml.MacroManager or an alternative to it. We use it to read back the macro configuration during indexing. If there is a better API to do that, let us know.

Anyway, right after getting past the com.atlassian.util.concurrent, I’m back at import errors for the bucket.user, even with the Spring Java configuration.

We either need a way to debug this magic imports or have a way to disable them. Or other suggestions?

Update: My ugly work around for the com.atlassian.util.concurrent to get further. I placed a fake class into that package in our app. This seems to prevent the magic OSGi import:

package com.atlassian.util.concurrent;

public final class PreventConfluence9OsgiImport {
    private PreventConfluence9OsgiImport() {}
}

I’m not sure if that will work, I fear some class loader mess down the line. But at least for not I can progress with the other errors. I’m not getting legit OSGi / import issues instead of ‘magically introduced’ ones =)

Update2: Ok, this error is back. It allowed me to get futher and eliminate some actual imports/dependencies, it is back now .Probably this hack just changed some order that other issues showed up first =(

Update3. I’ve added the atlassian.util.concurrent to app, despite not touching it.
Looks like that prevents the system from adding it at the moment?

        <dependency>
            <groupId>com.atlassian.util.concurrent</groupId>
            <artifactId>atlassian-util-concurrent</artifactId>
            <version>3.0.0</version>
        </dependency>

Update4. Nope. Still hanging on the com.atlassian.util.concurrent. The inclusion of the dependency again made other issues show up first, but then came back again.

AndreasEbert · May 31, 2024, 9:01am

@Kusal, good to hear. Could you please add following methods to velocity-default.properties’s introspector.proper.allowlist.methods entry:

java.util.TreeMap#size()
java.util.Arrays$ArrayList#size()
EDIT: java.util.LinkedHashMap#entrySet()

Other methods of those Collection classes are already allowed, but not size(). Conversely, other classes’s size() method are allowed, but not for those 2 classes. So, I think it’s no harm to fill this gap. Thanks.
There might be other Collection classes’s methods which could be added, but only those 2 popped up in our app.

General feedback:
It’s cumbersome and prone to error to execute all of our app’s actions with all possible code-paths, in order to have all our Velocity templates rendered, in order to trigger all relevant log-messages containing “Invocation blocked as method is not allowlisted: …”, in order to generate a complete list of methods that need allow-listing. How do you that at Atlassian? While debugging I saw that 32 of Confluence’s own apps have <velocity-allowlist> modules, so you must have some experience with the process and give us some tips. Any help is much appreciated.

scott.dudley · May 31, 2024, 2:57pm

@RomanStoffel

In your pom.xml, under build → plugins → plugin(maven-confluence-plugin) → configuration → instructions, do you have this?

<Atlassian-Plugin-Key>${atlassian.plugin.key}</Atlassian-Plugin-Key>

scott.dudley · May 31, 2024, 10:36pm

While we are here @Kusal, how about also the following? These would clean up a lot of log warnings (and they seem to originate from internal Confluence code):

java.util.ArrayList$SubList#size()
org.apache.commons.lang3.StringUtils#isNotEmpty(java.lang.CharSequence)

remie · June 2, 2024, 1:43pm

Hi!

In order to support ARM platform when running the Docker images, we clone the docker repository from bitbucket (as mentioned in the Advanced Configuration section of the Docker repo)

However, for 9.0.0 EAP this fails because it cannot do a checksum verification, due to a missing sha265 file:

curl: (22) The requested URL returned error: 403
sha256sum: atlassian-confluence-9.0.0-m41.tar.gz.sha256: No such file or directory

Would it be possible to start publishing EAPs with the SHA256 checksum to enable Docker builds again?

clouless · June 2, 2024, 4:29pm

It might help you that you can start those ubi jdk17 docker images on macOS.
I was building arm images myself for many years now and have stopped now and am using the UBI ones. Somehow this starts up with no problems on my M2 MacBook Pro when I use an arm-postgres image. Maybe a good workaround for you, until Atlassian fixes the sha.

jhronik · June 3, 2024, 12:48am

Hi @adam.labus . Thanks for reporting the ERR_INVALID_CHUNKED_ENCODING error. I’ll need a few more information to help reproducing and identifying the issue.

Do you get this error on the same back.css resource each time or does it occur for different resources too?
Do you have any proxy between your browser and Confluence by any chance?
Do the web-resources included in that batch use any special transformations, conditions, or any other customisations?
Thanks!

Kusal · June 3, 2024, 2:06am

Thanks @AndreasEbert and @scott.dudley - added to the global allowlist

This is already allowlisted for the system bundle - it could be a plugin bundled copy in which case it will need allowlisting via a module descriptor. If it’s indeed triggered by internal code, I’d be interested in knowing which endpoint triggers it if known.

We’ve been using the same manual approach as well as the system property mentioned in the developer notes. We additionally have a number of internal instances running the latest EAP so we have a tight feedback loop.

We’ve decided not to proceed with this at this point in time as there are some additional technical challenges in implementing this securely.

RomanStoffel · June 3, 2024, 4:14am

Thanks @scott.dudley, the missing Atlassian-Plugin-Key caused these issues. We had this app out for a long time without this manifest entry and I worked fine =).

So, everyone, please double check that the ‘Atlassian-Plugin-Key’ is present in the jar manifest.

adam.labus · June 3, 2024, 7:57am

Hi @jhronik

UPDATE - Today I checked different versions of the same configuration, results:

Version: 9.0.0-m108 - does not work properly
Version: 9.0.0-m97 - does not work properly
Version: 9.0.0-m81 - does not work properly
Version: 9.0.0-m72 - unable to check, problem with dependencies in the repo
Version: 9.0.0-m57 - works correctly
Version: 9.0.0-m41 - works correctly
Version: 8.9.0 - works correctly

Thank you for your questions, below is more information that I managed to gather.

I get an error on various resources, sometimes it’s js, sometimes it’s a page etc.
In case of an error on the page, I am able to get it almost every time - I go to edit any page, when the page in edit mode is ready, I click “back” in the browser.

No, I don’t use any proxy, I have a clean installation of macOS, the environment is deployed directly on this machine (atlas-run)
In the case of my additional js files, the error is also random. I load them very simply by adding them to the head element via javascript. Basically, these JS scripts are available to everyone from all possible places through the appropriate URL for this add-on

//Loading our JS
var scriptElement = document.createElement("script");
scriptElement.type = "text/javascript";
scriptElement.id = id;
scriptElement.src = baseUrl + ourResourcesUrl + filePathAndName;
AJS.$("head").append(scriptElement);

atlassian-plugin.xml

<resource type="download" name="appjs/" location="js/appjs/"/>

I performed the above tests on this configuration:

<confluence.version>9.0.0-m97</confluence.version>
<platform.version>7.0.8</platform.version>

ATLAS Version:    8.2.10
ATLAS Home:       /Applications/Atlassian/atlassian-plugin-sdk
ATLAS Scripts:    /Applications/Atlassian/atlassian-plugin-sdk/bin
ATLAS Maven Home: /Applications/Atlassian/atlassian-plugin-sdk/apache-maven-3.9.5
AMPS Version:     8.14.3
--------
Executing: /Applications/Atlassian/atlassian-plugin-sdk/apache-maven-3.9.5/bin/mvn --version -gs /Applications/Atlassian/atlassian-plugin-sdk/apache-maven-3.9.5/conf/settings.xml
Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
Maven home: /Applications/Atlassian/atlassian-plugin-sdk/apache-maven-3.9.5
Java version: 17.0.11, vendor: Eclipse Adoptium, runtime: /Library/Java/JavaVirtualMachines/jdk-17.0.11+9/Contents/Home
Default locale: en_PL, platform encoding: UTF-8
OS name: "mac os x", version: "14.5", arch: "aarch64", family: "mac"

When running version 8.9 on the same machine, with the same configurations, the same browser, everything loads every time.

<confluence.version>8.9.0</confluence.version>
<platform.version>NOT USED</platform.version>

ATLAS Version:    8.2.10
ATLAS Home:       /Applications/Atlassian/atlassian-plugin-sdk
ATLAS Scripts:    /Applications/Atlassian/atlassian-plugin-sdk/bin
ATLAS Maven Home: /Applications/Atlassian/atlassian-plugin-sdk/apache-maven-3.9.5
AMPS Version:     8.14.3
--------
Executing: /Applications/Atlassian/atlassian-plugin-sdk/apache-maven-3.9.5/bin/mvn --version -gs /Applications/Atlassian/atlassian-plugin-sdk/apache-maven-3.9.5/conf/settings.xml
Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
Maven home: /Applications/Atlassian/atlassian-plugin-sdk/apache-maven-3.9.5
Java version: 11.0.23, vendor: Eclipse Adoptium, runtime: /Library/Java/JavaVirtualMachines/jdk-11.0.23+9/Contents/Home
Default locale: en_PL, platform encoding: UTF-8
OS name: "mac os x", version: "14.5", arch: "aarch64", family: "mac"

Cheers
Adam

remie · June 3, 2024, 9:11am

Thanks! The issue is not such much that there aren’t any workarounds. The issue is that Atlassian broke her own deployment process, which is weird and should be addressed

AndreasEbert · June 3, 2024, 9:41am

@Kusal, thanks. I guess the next EAP (21) will contain this; the current EAP (20) does not.

Regarding EAP 20:
The docu Preparing for Confluence 9.0 | Confluence Data Center 8.9 | Atlassian Documentation says that the corresponding maven-artefact is 9.0.0-m105, but indeed only 9.0.0-m108 is available in Atlassian’s Nexus. Maybe this is a typo? If so, please correct it on the docu page, thanks.

RomanStoffel · June 3, 2024, 2:33pm

I’m struggling with the Velocity velocity-allowlist. I get these informative errors, telling me that the method isn’t on the allow list:

16:25:53,549 WARN [http-nio-1990-exec-9] [velocity] log Invocation blocked as method is not allowlisted: ch.mibex.confluence.include.macros.views.IncludeStashView#getRepoDisplayUrl()

However, it is clearly on the list:

<velocity-allowlist key="velocity-allowlist-for-include-bitbucket">
   <method>ch.mibex.confluence.include.macros.views.IncludeStashView#getRepoDisplayUrl()</method>
    <method>ch.mibex.confluence.include.macros.views.IncludeStashView#isBitbucketCloud()</method>
   <!-- sub-class of IncludeStashView -->
<method>ch.mibex.confluence.include.macros.views.IncludeTagsView#getRepoDisplayUrl()</method>
    <!-- ... -->
</velocity-allowlist>

The IncludeStashView is an super class. So I also tried to put the sub class on the a allow list, but that didn’t help.

Any idea what could be wrong?

AndreasEbert · June 3, 2024, 3:11pm

@RomanStoffel, be extra-careful that you have no invalid entries, i.e.:

only existing methods
only methods reachable by “your” classloader, so in practice: only your own classes

Otherwise, an error is logged and your WHOLE allowlist-module is ignored – not just the offending entry.
See @scott.dudley’s comment #243 from 7d ago:

Look for log entries like this during plugin load:
WARN [allowlist.impl.internal.PluginAllowlistConfigurator] getModuleMethodAllowlist Invalid method(s) METHODNAME defined for class CLASSNAME- disabling Velocity Allowlist plugin module YOURMODULE

scott.dudley · June 3, 2024, 5:24pm

Maybe this will be helpful to someone. I saw this referenced elsewhere, regarding some automated Atlassian OpenRewrite tooling to assist with performing Platform 7 migrations:

WendyR · June 3, 2024, 11:17pm

Hi Andreas. Thanks for raising this. We had a rare tech hiccup between the expected milestone number and the actual milestone number of the build. I’ve updated our Preparing for Confluence 9.0 | Confluence Data Center 8.9 | Atlassian Documentation milestone details to reflect the latest EAP release.

Over to @Kusal for your question about the global allowlist.

AndreasEbert · June 4, 2024, 7:16am

@WendyR, thanks. But on the EAP-download page I see that 9.0.0-m109 (released last night) is the milestone-version of EAP 20, but on Preparing for Confluence 9.0 | Confluence Data Center 8.9 | Atlassian Documentation it still says 9.0.0-m105. Sure you updated the correct place?