Preparing for Confluence 9.0 - EAP out now

@fgrund for us the cause was that we were still using outdated <component> modules and thus got a ton of unwanted and blocked package imports along the way. Switching to Spring Scanner fixed the problem for us. See this comment on this thread for more details: Preparing for Confluence 9.0 - EAP out now - #43 by AndreasEbert
A couple of other comments here also deal with this problem.

2 Likes

We have discovered a problem using com.atlassian.upm.api.license.PluginLicenseManager. First of all I see the com.atlassian.upm.api.util.Option class used in its API is deprecated. Are there any plans to update the API? It appears that an internal reference to a com.google.common class (presumably from the removed Guava grey API) within the Option class is no longer exported through osgi, but as it is still exposed in com.atlassian.upm.api, we get a NoSuchMethodError:

Caused by: java.lang.NoSuchMethodError: 'com.atlassian.upm.api.util.Option com.atlassian.upm.api.util.Option.map(com.google.common.base.Function)'

What guidance can Atlassian offer? I see nothing in the code or the upm-server upgrade guide to suggest that the PluginLicenseManager itself is deprecated, even if it is using deprecated types in its java API. Are there any alternative ways I can obtain the com.atlassian.upm.api.license.entity.PluginLicense?

Edit: I was able to workaround my issue by removing all calls to .map() and instead checking licenseManager.getLicense().isDefined() followed by licenseManager.getLicense().get(), as these methods don’t have references to Guava.

4 Likes

Hi @andreas1,

Have you been able to reproduce this issue on the latest available milestone?

Unfortunately, I couldn’t get this to work with m116 after migrating everything to Java config; the OSGI error kept coming up. I gave up after a while and created my own AbstractUserProfileAction with only the necessary parts taken from Atlassian’s class. Pretty nasty, but at least I can install our app now.

1 Like

Hi @ShahrimanMohammad,

Did you manage to work around this @AnonymousSiteAccess vs @AnonymousAllowed without having to maintain two versions of the app, one for Conf 8 and another for Conf 9?

@nunoMSsantos You may be able to add both com.atlassian.plugins.rest:atlassian-rest-common and com.atlassian.plugins.rest:atlassian-rest-v2-api to your pom.xml at provided scope, given all you are importing directly from com.atlassian.plugins.rest.common is that annotation (or similar annotations).

You should then be able to add to your Import-Package instructions to make these optional:

<Import-Package>
...
com.atlassian.plugins.rest.common.security;resolution:="optional",
com.atlassian.plugins.rest.api.security.annotation;resolution:="optional",
...
</Import-Package>

And then you should be able to annotate your endpoints with annotations from both REST v1 and REST v2 like so:

@GET
@Path("/some-endpoint")
@com.atlassian.plugins.rest.common.security.AnonymousAllowed
@com.atlassian.plugins.rest.api.security.annotation.AnonymousSiteAccess
public Response someEndpoint(@Context HttpServletRequest request) {
    return Response.ok().build();
}

You can also import them as usual and annotate with just @AnonymousAllowed and @AnonymousSiteAccess.

Since missing annotations don’t cause ClassNotFoundExceptions, the presence of AnonymousAllowed in Confluence 9, or the presence of AnonymousSiteAccess in Confluence 8 won’t cause any problems.

As long as you annotate your endpoints with both annotations.

2 Likes

Dear @JordanAnslow ,

yes it is still there. However I have to correct myself - it says “blocked URL” not “bad URL”.

Best regards

Andreas

Dear @RomanStoffel ,

we had Atlassian-Plugin-Key but did not define ${atlassian.plugin.key} in the properties (<atlassian.plugin.key>${project.groupId}.${project.artifactId}</atlassian.plugin.key>). Thank you for directing me into the right direction.

Andreas

1 Like

Hi @andreas1,

Ah blocked URL. In that case if it’s an external resource it will likely be getting blocked by the allowlist feature detailed here. Could you try adding the URL to the allowlist and confirming that the PDF export works as expected?

Dear @JordanAnslow ,

Sorry for my very direct answer: no I won’t try that.

Firstly the URL is pointing to an internal picture in the app and should not be blocked. Secondly the image placeholder shall no be exported - the placeholder is for the editor and for nothing else. Confluence seems to take a wrong turn here trying to export the placeholder instead of the content behind the macro.

Andreas

@Kusal, please also add these entries to the global allowlist:

  • java.util.TreeMap$Entry#getKey()
  • java.util.TreeMap$Entry#getValue()

Thanks

3 Likes

Done, expect them in the next EAP

1 Like

Hi @aorlov
From my understanding, the EAP download page is cached really aggressively, which means sometimes it takes a while for the new download links to appear. This isn’t managed by Confluence Engineering. I feel your pain as we also experience the same problem. I don’t have much to suggest here other than trying a different browser or incognito/private browsing. Sorry I couldn’t be more helpful than that.

1 Like

Hi @aorlov,

Can I please know why do you need to require (“confluence.web.resources:editor-templates”). Asking because “editor-templates” houses server-side rendered soy-templates. The reason also why you are not able to find server-side putMetadata function.

Thanks

1 Like

@jens , I hope this problem has been solved with latest milestone as we exporting jackson annotations

Could you try the milestone [9_0_0-m135]

Seems like issue was occurring as com.comalatech.workflow depends on com.atlassian.mywork.model and my-workday plugin exports JAX RS1 as it was still on RESTV1.

Now that my-workday is in RESTV2 it should export RESTV2 , just like com.atlassian.plugins.rest.atlassian-rest-v2-plugin

Thanks

Hi,
between two Confluence test builds, we start to see

2024-06-26 08:50:25,745 WARN [http-nio-8080-exec-21] [velocity] log Invocation blocked as method is not allowlisted: org.apache.commons.lang3.StringUtils#isNotEmpty(java.lang.CharSequence)
 -- url: /plugins/servlet/userdeactivator/admin | userName: admin | referer: https://xxx/plugins/servlet/upm | traceId: 517f3bf8db95fa1d

messages. We started seeing this message with 9.0.0-m132, this code is not called by our app.

I don’t know if that is a bug on our side or on Confluence’s side. Any idea?

EDIT:
Also happens without any app installed:

2024-06-26 09:06:52,458 WARN [http-nio-8080-exec-2] [velocity] log Invocation blocked as method is not allowlisted: org.apache.commons.lang3.StringUtils#isNotEmpty(java.lang.CharSequence)
 -- url: /plugins/servlet/upm | userName: admin | referer: https://xxx/ | traceId: 82ede53648859d28

Best regards,
Christopher

We experienced a breaking change from m-123 to m-132. Our rest-v2 endpoints have been working a while (at least since m-116). After updating to m-132, I get a 404 for all endpoints.

2024-06-26 11:00:12,062 DEBUG [https-jsse-nio-8015-exec-8 url: /rest/ksso/api/info/1.0/ping; user: admin] [atlassian.confluence.servlet.FourOhFourErrorLoggingFilter] setStatus 404 code set with message Not Found
 -- url: /rest/ksso/api/info/1.0/ping | userName: admin | traceId: 16c63561bec8b748
java.lang.Throwable
        at com.atlassian.confluence.servlet.FourOhFourErrorLoggingFilter$1.setStatus(FourOhFourErrorLoggingFilter.java:42)
        at javax.servlet.http.HttpServletResponseWrapper.setStatus(HttpServletResponseWrapper.java:200)
        at com.atlassian.core.filters.HeaderSanitisingResponseWrapper.setStatus(HeaderSanitisingResponseWrapper.java:93)
        at javax.servlet.http.HttpServletResponseWrapper.setStatus(HttpServletResponseWrapper.java:200)
        at javax.servlet.http.HttpServletResponseWrapper.setStatus(HttpServletResponseWrapper.java:200)
        at com.atlassian.gzipfilter.SelectingResponseWrapper.setStatus(SelectingResponseWrapper.java:106)
        at javax.servlet.http.HttpServletResponseWrapper.setStatus(HttpServletResponseWrapper.java:200)
        at com.atlassian.oauth.serviceprovider.internal.servlet.OAuthFilter$OAuthWWWAuthenticateAddingResponse.setStatus(OAuthFilter.java:165)
        at
....
        at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:264)
        at org.glassfish.jersey.internal.Errors$1.call(Errors.java:248)

I see in upm that my rest-v2 modules are enabled, and debugging the rest-v2 code doesn’t seem to give me an explanation as to what fails. I’ve requested source code for m-123 and m-132 to inspect the diff and add breakpoints in the Confluence code, but until then I’d like to hear if anyone has any explanation.

:one: I cannot get the userManager.createUser(...) to work with Confluence 9.0-m132.
Somehow I cannot import and use DefaultUser anymore.

                        <Import-Package>
                            com.atlassian.sal.*,
                            com.atlassian.user.impl.*,<!-- needed for usermanager.createuser -->
                        </Import-Package>

Now I get

Caused by: org.osgi.framework.BundleException: Unable to resolve io.codeclou.app-confluence-common [298](R 298.0): 
  missing requirement [io.foo.app-confluence-common [298](R 298.0)] 
   osgi.wiring.package; (osgi.wiring.package=com.atlassian.user.impl) 
    Unresolved requirements: [[io.foo.app-confluence-common [298](R 298.0)] 
     osgi.wiring.package; (osgi.wiring.package=com.atlassian.user.impl)]

:two: Second is UserPreferencesAccessor and UserAccessor gets OSGI errors when trying to use it

1. org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at SystemInjecteeImpl(requiredType= UserPreferencesAccessor,parent=UsersEndpoint,qualifiers={},position=1,optional=false,self=false,unqualified=null,1108564563)
2. java.lang.IllegalArgumentException: While attempting to resolve the dependencies of io.foo.app.confluence.common.rest.UsersEndpoint errors were found
3. java.lang.IllegalStateException: Unable to perform operation: resolve on io.foo.app.confluence.common.rest.UsersEndpoint

I do with Spring Java Config

    @Bean
    public UserPreferencesAccessor initUserPreferencesAccessor() {
        return importOsgiService(UserPreferencesAccessor);
    }

:information_source: UPDATE 2024-07-01: With Confluence 9.0-beta2 the app starts again and can access the UserAccessor. BUT :zap: it is marked as deprecated => :question: What is the right Class to use to get/set UserPreferences then? I use currently:

User foundUser = userManager.getUser(userName);
ConfluenceUserPreferences prefs = userAccessor.getConfluenceUserPreferences(foundUser);
prefs.setString(UserPreferencesKeys.PROPERTY_USER_LOCALE, localePayload.getLocale());

:information_source: UPDATE 2024-07-02: :white_check_mark: Using UserPreferencesAccessor instead of UserAccessor works with Confluence 9.0-beta2. No deprecation warnings anymore.

LocalNotificationService seem to be deactivated in Confluence 9.0, is there any new way to send notifications to Confluence users ?

1 Like