Hi,
I have just released a version 8.8.0 compatible plugin, which was a bit of a nightmare with Atlassian closing so much things down in the Java API.
After many days I was able to get a POM working and compiling my code and everything tested well from versions 7.16 up to 8.8.
I released this new version and POW, it blew up as the first customers started to install it.
It throws this error, and I have no idea why, this code is 10 years old and always worked and doesn’t rely on any third-party code.
-- url: /rest/pageviewtracker/1.0/statistics/views | userName: xxxx | referer: https://xxxxxxxxx/display/~2562/testar+testar | traceId: 4dbf60d472a3f4e5
java.lang.NoSuchMethodError: 'boolean com.atlassian.confluence.security.PermissionManager.isSystemAdministrator(com.atlassian.confluence.user.ConfluenceUser)'
Does anyone know why this function, which compiles all versions, is not available at runtime?
I assume I need to add a jar to my POM for runtime support, but this doesn’t make sense as it should be part of Confluence core code.
Please HELP ASAP…
1 Like
Dear Chris,
I assume this thread already picked up the topic: Confluence 8.8 release EAP available now - #58 by scott.dudley. I didn’t screen for an answer.
Good luck
Andreas
Hi @andreas1 ,
Yes that looks like it is indeed the issue, I have been using ConfluenceUser in this function now for many years, this looks like a stupid Atlassian error that needs to be fixed. There needs to be a 2 years cut-over period where both API’s are valid until EOL of the older one. 8.7 is not EOL.
Hi Chris,
Sorry about that. We added new methods to PermissionManager to replace the ones that used the legacy com.atlassian.user.User type, instead using the current ConfluenceUser type. This does mean that if you recompile against 8.8 ands run against an older version, you get the NoSuchMethodError.
The quick workaround is to cast the user argument to User, to force it to use the deprecated PermissionManager methods.
I’m curious though - you say you compiled against 8.8 and tested against everything back to 7.16. Did this problem not come up in testing?
Hi,
we got the same problem. But I don’t understand why casting the user solves the issue.
The hasPermission method takes for Confluence 7.19.23 a com.atlassian.user Object, while for 9.0.0 it takes a ConfluenceUser. AuthenticatedUserThreadLocal.get() always returns a ConfluenceUser.
However, ConfluenceUser extends User, this should always work. When compiling against 7.19.23 or 9.0.0-rc2, my IDE does not show any error.
I feel like this is a dynamic casting thing because of the types have changed, but I don’t really understand why it breaks when being run.
Once your code is compiled, the compiler resolves this method call against a specific method signature (one that takes a User object or a ConfluenceUser object, depending on which version you compiled against). Since that selection happens at compile time and not at runtime, your binary will be looking for the specific method with the specific parameter types as determined at compile time. After adding the new overload, the compiler will choose the method with the most specific type (unless you cast it to tell it otherwise). Since this new method does not exist in earlier Confluence versions, the binary will fail to run there.
1 Like
Thanks for the answer!
That makes sense. I have to think about how to solve this in the best way. Using a deprecated method could create problems in the future when it gets removed …, that is maybe something for our compatibility library