Preparing for Confluence 9.0 - EAP out now

NikhilJain · February 22, 2024, 9:23am

If you are depend on com.atlassian.confluence.user.UserAccessor, that might permit a transitive load of the bucket superclass. Have you tried loading via transitive dependency. CC: @kmacleod

AndreasEbert · February 22, 2024, 9:37am

Have you tried loading via transitive dependency

@NikhilJain, thanks for your suggestion. I’m afraid I don’t understand. What you mean by that? Can you ellaborate?

AndreasEbert · February 22, 2024, 9:58am

With a pointer in the right direction by @scott.dudley I confirmed my suspicion about having to switch away from old-school <component> / <component-import>. and to use Spring-Scanner instead: I tested with a small dummy-app, having only 1 dependency at all, on com.atlassian.confluence.user.UserAccessor. I tried once with old-school, and once with Spring-Scanner. Here the result upon installing in Confluence 9.0.0-m11:

old-school: 18 Import-Package statements generated, coming from UserAccessor’s imports + ALL its super-classes’s imports, so incl. “bucket.user” (which is blocked as Grey API) → app could not be enabled
Spring-Scanner: 3 Import-Package statements: 1 for com.atlassian.confluence.user, 2 for Spring-Scanner stuff → app could be enabled

Conclusion: We definitely have to switch to Spring-Scanner…

@Atlassian, I think a public advisory (so to speak) about old-school <component> / <component-import> NOT working anymore with Platform 7 and having to switch to Spring-Scanner (or similar more modern approaches) might be useful.

AndrewMorton · February 22, 2024, 10:37am

Just asking as well - is there a timeline for when the dev vs prod OSGi issues will be resolved? I assume we’ll have to wait for 8.8.1 release at least before things are back to normal on that.

Thanks for acknowledging it, though. It’s just been a bit of a hinderance with trying to quickly push out compatibility for 8.8, never mind 9.0.

Kusal · February 22, 2024, 10:57am

Dev mode vs prod mode differing in OSGi behaviour for 8.x is intentional; it is to help vendors prepare for 9.0.

JamesGwynne · February 22, 2024, 11:47am

Could you please explain how we’re supposed to effectively test and perform any development with Confluence 8.8 if dev mode doesn’t match prod mode? Surely we prepare for 9.0 by utilising the EAP version? I would love to know the process which led to the decision to help us prepare for a future version by intentionally diverging the development and production environments on an existing version.

rlander · February 22, 2024, 12:50pm

Where is this documented? If 8.8 behaves like 9 for OSGi that would be useful to know…

rr1 · February 22, 2024, 1:08pm

My current but unproven observation is that users of the Spring Java Config are especially dealing with the OSGI issue in DEV mode. Might be right, might be wrong.

Currently I am a bit struck with missing dependencies (at deploy time) that I cannot add because they are banned from being added (at build time). Any deus ex machina would come handy …

Are there any references / resources so that I can check

to make sure that Spring Java Config is not a problem here and
to learn how to find the root cause of the issue then?

FbioCunha · February 22, 2024, 3:29pm

Hi,

I’m experiencing the same error @aorlov and @sax experience when installing our app in Confluence 9.0.0-m11, but for the now removed from confluence dependency com.google.guava:guava, which i’m including in the pom with the compile scope (default maven scope), as per Atlassian’s instructions regarding the gray API removal (https://developer.atlassian.com/server/confluence/get-your-apps-ready-for-gray-api-removal):

<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>32.1.3-jre</version>
</dependency>

The generated packaged jar does, in fact, include the aforementioned dependency under the META-INF/lib directory and it is also declared on the manifest file, under Bundle-ClassPath:

Bundle-ClassPath: 
...
META-INF/lib/listenablefuture-9999.0-empty-to-avoid-conflict-with-guava.jar,
... 
META-INF/lib/guava-32.1.3-jre.jar

However, when installing on a standalone Confluence 9.0.0-m11 instance (in dev mode or not, it doesn’t matter) I get the same familiar exception:

Caused by: org.osgi.framework.BundleException: Unable to resolve com.valiantys.software.spreadsheets.server-app [300](R 300.0): missing requirement [com.valiantys.software.spreadsheets.server-app [300](R 300.0)] osgi.wiring.package; (&(osgi.wiring.package=com.google.common.base)(version>=32.1.3.jre)(version<=32.1.3.jre)) Unresolved requirements: [[com.valiantys.software.spreadsheets.server-app [300](R 300.0)] osgi.wiring.package; (&(osgi.wiring.package=com.google.common.base)(version>=32.1.3.jre)(version<=32.1.3.jre))]
	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)

I tried @scott.dudley’s hack here Preparing for Confluence 9.0 - EAP coming soon - #10 by scott.dudley of including the relevant package in a negated pattern under the Import-Package tag, but with no success:

<Import-Package>
    ...
    !com.google.common.base,
</Import-Package>

Some guidance from Atlassian on how to resolve this would be greatly appreciated.

turehoefner_appfire · February 22, 2024, 4:41pm

Hello @rr1
For Catch-22 situation of dependencies that you must add but are prohibited from adding… see the “banningExcludes” configuration setting for the “confluence-maven-plugin” in your pom.xml.

There is some mention of it earlier in this thread and, I think, in one of the other Confluence compat topics in the dev community:

<plugin>
    <groupId>com.atlassian.maven.plugins</groupId>
    <artifactId>confluence-maven-plugin</artifactId>
    <version>${amps.version}</version>
    <extensions>true</extensions>
    <configuration>
        <banningExcludes>
            <exclude>com.google.code.findbugs:jsr305</exclude>
            <exclude>com.google.guava:guava</exclude>
            <exclude>commons-io:commons-io</exclude>
            <exclude>org.apache.commons:commons-lang3</exclude>
            <exclude>org.slf4j:slf4j-api</exclude>
            <exclude>org.apache.httpcomponents:httpclient</exclude>
            <exclude>org.apache.httpcomponents:httpcore</exclude>
        </banningExcludes>

I am also using Spring Java Config, btw.

In my opinion, differences between dev are not a help. I see that as a problem. I agree with JamesGwyn… we use the 9 EAP to prepare for 9. That is why it is so important (to partners) for Atlassian to slow down this train and not publicly release things (like 8.8) until partners are no longer reporting problems with the EAP every day.

AndrewMorton · February 22, 2024, 6:37pm

FWIW, we are using Spring Scanner and still experienced the OSGi issues when in dev mode.

WendyR · February 22, 2024, 11:10pm

Hi @rlander. It’s documented in the Confluence 8.8 release notes, the Preparing for Confluence 8.8 notes (admittedly, we added this content a day later, when we realised it was causing devs problems), the Confluence 8.8 beta release notes, and the Confluence 8.8 upgrade notes.

See the last paragraph on each of those page paragraphs about this change (“This change doesn’t affect the installation of apps from the Atlassian Marketplace. Note that the UPM upload option is still enabled for instances running in dev mode.”).

sax · February 23, 2024, 11:41am

Hi Fabio,
If you didn’t do it already, follow/vote for the support case I reported here. Hopefully, it will get some traction.

rr1 · February 23, 2024, 2:05pm

Hi @turehoefner_appfire,

Thank you very much for your reply and information about how to manage to include dependencies with my deployment bundle.

It also helps a lot that you managed to get it work with Spring Java Config and @AndrewMorton can confirm that other injection frameworks also have related issues. So I know that it can be done and that it is probably not related to the injections library I use.

I understand the solution for handling the dependencies I am using directly in my app:

scope ‘compile’ instead of ‘provided’ and
blacklist what does not pass the build checks

I did that for dependencies like commons-lang3 as you have shown in your code example. But when I have added all of these dependencies, I still get an issue that org.eclipse.gemini.blueprint.context cannot be resolved.

[INFO] [talledLocalContainer] Caused by: org.osgi.framework.BundleException: 
Unable to resolve de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros 
[312](R 312.0): missing requirement [de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros 
[312](R 312.0)] osgi.wiring.package; (osgi.wiring.package=org.eclipse.gemini.blueprint.context)
Unresolved requirements: [[de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros 
[312](R 312.0)] osgi.wiring.package; (osgi.wiring.package=org.eclipse.gemini.blueprint.context)]

Which dependency does call for this?

I am deploying a version compiled with Java 11 and Confluence 8.8.0 to a Confluence Server started with these versions using the SDK (to have Dev Mode activated since non-Dev would work on Confluence 8.x) with AMPS 8.13.5.

So what dependencies do I have?

I have dependencies due to Spring Java Config (https://developer.atlassian.com/server/framework/atlassian-sdk/spring-java-config-dependencies/), but they are either marked as provided or are not blacklisted, so there seems to be no problem. Since you are als using this framework I assume I am done here.

For completeness these are the dependencies for Spring Java Config provided

org.osgi:osgi.core
org.springframework:spring-beans
org.springframework:spring-context

and already included with the app (compile):

com.atlassian.plugins:atlassian-plugins-osgi-javaconfig

Further I’d like to assume that I can skip the imported dependencies and the following are also still provided (I do not see them in your example, so I’d like to assume that I am save here):

com.atlassian.confluence:confluence
com.atlassian.upm:licensing-api
com.atlassian.upm:upm-api
com.atlassian.upm:plugin-license-storage-lib

When I do a mvn dependency:list I get no dependency to org.eclipse.* an d if I restrict the list to the non-transitives, I get not surprised.

[INFO]    com.atlassian.confluence:confluence:jar:8.8.0:provided -- module confluence (auto)
[INFO]    org.apache.commons:commons-lang3:jar:3.14.0:compile -- module org.apache.commons.lang3
[INFO]    org.apache.commons:commons-text:jar:1.11.0:compile -- module org.apache.commons.text
[INFO]    org.slf4j:slf4j-api:jar:2.0.3:compile -- module org.slf4j
[INFO]    org.jsoup:jsoup:jar:1.17.2:compile -- module org.jsoup
[INFO]    com.google.code.findbugs:jsr305:jar:3.0.2:compile -- module jsr305 (auto)
[INFO]    com.atlassian.upm:licensing-api:jar:2.22.9:provided -- module licensing.api (auto)
[INFO]    com.atlassian.upm:upm-api:jar:2.22:provided -- module upm.api (auto)
[INFO]    org.osgi:osgi.core:jar:8.0.0:provided -- module osgi.core [auto]
[INFO]    org.springframework:spring-beans:jar:5.3.29:provided -- module spring.beans [auto]
[INFO]    org.springframework:spring-context:jar:5.3.29:provided -- module spring.context [auto]
[INFO]    com.atlassian.plugins:atlassian-plugins-osgi-javaconfig:jar:0.6.0:compile -- module atlassian.plugins.osgi.javaconfig (auto)

If I make the Import (although the Spring Java Config implies that the library is managing the imports for me when I include everything via the POM) optional, I get a ClassNotFoundException for org.eclipse.gemini.blueprint.service.exporter.support.InterfaceDetector from the missing package. No surprise here.

So I get really desparate and add the dependency with scope ‘compile’

<dependency>
  <groupId>org.eclipse.gemini.blueprint</groupId>
  <artifactId>gemini-blueprint-core</artifactId>
  <scope>compile</scope>
</dependency>

and get this:

Caused by: org.osgi.framework.BundleException: 
Unable to resolve de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros 
[318](R 318.0): missing requirement 
[de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros 
[318](R 318.0)] osgi.wiring.package; (osgi.wiring.package=org.aopalliance.aop) 
Unresolved requirements: [[de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros 
[318](R 318.0)] osgi.wiring.package; (osgi.wiring.package=org.aopalliance.aop)]

I am not sure if there is anything at the end of this particular rabbit hole … so I am stopping here.

So with all these details the question is still: Where does the missing requirement org.eclipse.gemini.blueprint.context come from? Do you spot the issue that I miss? Do you have any pointers that I could check?

Cheers,
Robert

rr1 · February 23, 2024, 2:06pm

Thank you, @AndrewMorton, it helps to rule out that this is only an issue with Spring Java Config!

matthiasbertsch · February 23, 2024, 3:13pm

According to my understanding, this originates from com.atlassian.plugins:atlassian-plugins-osgi-javaconfig. Specifically, the com.atlassian.plugins.osgi.javaconfig.OsgiServices.importOsgiService method, which you likely call in your plugin code, as it includes an import from org.eclipse.gemini.blueprint.*. This import is actually invoked when calling com.atlassian.plugins.osgi.javaconfig.OsgiServices.importOsgiService.

This appears to differ from Spring scanner, which also appears to have an import from org.eclipse.gemini.blueprint.* somewhere along the line. However, it seems that it’s not being invoked in my case. Therefore, with Spring scanner, the plugin enables for me after making the resolution of org.eclipse.gemini.* optional, i.e., by adding the following:

<instructions>
    <Import-Package>
        com.google.*;resolution:=optional,
        com.sun.*;resolution:=optional,
        org.eclipse.gemini.*;resolution:=optional,
        *
    </Import-Package>
</instructions>

I went down the rabbit hole you mentioned and also added a compile-time dependency on https://mvnrepository.com/artifact/aopalliance/aopalliance/1.0. After doing this, I encountered:

Caused by: java.lang.ArrayStoreException: arraycopy: element type mismatch: can not cast one of the elements of java.lang.Object[] to the type of the 
destination array, org.aopalliance.aop.Advice
        at java.base/java.util.ArrayList.toArray(ArrayList.java:401)
        at org.eclipse.gemini.blueprint.service.util.internal.aop.ProxyUtils.createProxy(ProxyUtils.java:38)

If you discover a solution to this issue, I would also be interested.

rr1 · February 23, 2024, 3:36pm

Hi @matthiasbertsch,

Thank you for this information!

I had been in the rabbit hole myself and added the following dependencies …

    <dependency>
      <groupId>org.jspecify</groupId>
      <artifactId>jspecify</artifactId>
      <version>0.3.0</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>org.eclipse.gemini.blueprint</groupId>
      <artifactId>gemini-blueprint-core</artifactId>
      <scope>compile</scope>
      <exclusions>
        <exclusion>
          <groupId>org.apache.servicemix.bundles</groupId>
          <artifactId>*</artifactId>
        </exclusion>
      </exclusions>
    </dependency>
    <dependency>
      <groupId>commons-logging</groupId>
      <artifactId>commons-logging</artifactId>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>aopalliance</groupId>
      <artifactId>aopalliance</artifactId>
      <version>1.0</version>
      <scope>compile</scope>
    </dependency>

… and some desperate imports …

<Import-Package>
  !de.smartics.*,
   *;resolution:="optional"
</Import-Package>

I can get the same exception with Spring Java Config as you have encountered with Spring Scanner:

[INFO] [talledLocalContainer] Caused by: java.lang.ArrayStoreException: arraycopy: element type mismatch: can not cast one of the elements of java.lang.Object[] to the type of the destination array, org.aopalliance.aop.Advice
[INFO] [talledLocalContainer]   at java.base/java.util.ArrayList.toArray(ArrayList.java:433)
[INFO] [talledLocalContainer]   at org.eclipse.gemini.blueprint.service.util.internal.aop.ProxyUtils.createProxy(ProxyUtils.java:38)
[INFO] [talledLocalContainer]   at org.eclipse.gemini.blueprint.service.importer.support.AbstractServiceProxyCreator.createServiceProxy(AbstractServiceProxyCreator.java:105)
[INFO] [talledLocalContainer]   at org.eclipse.gemini.blueprint.service.importer.support.OsgiServiceProxyFactoryBean.createProxy(OsgiServiceProxyFactoryBean.java:176)
[INFO] [talledLocalContainer]   at org.eclipse.gemini.blueprint.service.importer.support.AbstractServiceImporterProxyFactoryBean.getObject(AbstractServiceImporterProxyFactoryBean.java:95)
[INFO] [talledLocalContainer]   at org.eclipse.gemini.blueprint.service.importer.support.OsgiServiceProxyFactoryBean.getObject(OsgiServiceProxyFactoryBean.java:122)
[INFO] [talledLocalContainer]   at com.atlassian.plugins.osgi.javaconfig.OsgiServices.invokeFactoryBean(OsgiServices.java:280)
[INFO] [talledLocalContainer]   ... 33 more

I still hope that the documentation for Spring Java Config at https://developer.atlassian.com/server/framework/atlassian-sdk/spring-java-config-plugin-xml/ is true and this is the configuration I need to make in the POM …

<instructions>
  <Atlassian-Plugin-Key>${atlassian.plugin.key}</Atlassian-Plugin-Key>
   <Spring-Context>*</Spring-Context>
   <Import-Package>*</Import-Package>
   <Export-Package/>
</instructions>

But the answer from Confluence, with compile scope dependencies and blacklist exceptions is still this at deployment time in Dev Mode with Confluence 8.8.0:

[INFO] [talledLocalContainer] Caused by: org.osgi.framework.BundleException: 
Unable to resolve de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros 
[336](R 336.0): missing requirement [de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros 
[336](R 336.0)] osgi.wiring.package; (osgi.wiring.package=org.eclipse.gemini.blueprint.context) Unresolved requirements: [[de.smartics.atlassian.confluence.smartics-atlassian-confluence-macros 
[336](R 336.0)] osgi.wiring.package; (osgi.wiring.package=org.eclipse.gemini.blueprint.context)]

Cheers,
Robert

adam.labus · February 23, 2024, 4:23pm

@WendyR @Kusal

I think it’s worth Atlassian taking a closer look at this little mess that seems to be really bothering most partners.

Can we ask for:

smoothed the behavior of the DEV environment to behave like the PROD environment for all versions < 9.0.0
providing several sample add-ons with the most frequently used classes/libraries and how to resolve their dependencies in version >= 9.0.0

Cheers
Adam

rr1 · February 23, 2024, 4:28pm

Hi @WendyR,

Thank you for your reply to @rlander’s question!

I encounter a missing requirement ‘org.eclipse.gemini.blueprint.context’ (for more information, please see above) and I try to figure out how OSGi handles apps at deploy time differently when running on Confluence 8.8 with dev mode set to true. There is no issue when the dev mode is set to false.

Due to @Kusal’s reply I must assume that this is not an issue with the dev mode, but a peek into the world of Version 9.

I thought this was the focus of @rlander’s question (but I may be biased due to my problem with the missing requirement ). I cannot find this OSGi related information on the referenced pages. I see only the need to switch the local upload button on.

Could you please given some information on the relation between the OSGi processing and dev mode on Confluence 8.8.0? Or am I missing something on the referenced pages?

Cheers,
Robert

turehoefner_appfire · February 23, 2024, 8:32pm

Does anyone know when the plugin instruction <Spring-Context>*<Spring-Context> showed up as a requirement for using Spring Java Config? And why?

https://developer.atlassian.com/server/framework/atlassian-sdk/spring-java-config-plugin-xml/

    <!-- Ensure the plugin is Spring-powered -->
    <Spring-Context>*</Spring-Context>

I don’t think that was in that doc years ago when I converted to Spring Java Config. I see it in others’ pom.xml file here. I suppose I’ll add it but I’d like to know more about it, if possible.

Is “*” some global spring context? And is that what it defaults to if not specified? I’ve been using Spring Java Config for years without that instruction.

Maybe that comment in the document:


means something like this?


Thanks!