A Confluence 8.9 EAP milestone is now available. EAP releases provide a snapshot of our work in progress and give you an opportunity to test and fix your apps before the final release.
As usual, we’ll be releasing weekly milestones and betas during the development of Confluence 8.9, so head to Preparing for Confluence 8.9 to find out what’s changed.
If you have any problems with an EAP release, please raise an issue to let us know. The earlier we know about problems, the more time we’ll have to fix them before the final release.
Enjoy!
The Atlassian Confluence team
We now announce Confluence Data Center releases and more in the Atlassian developer changelog. Subscribe to the changelog to receive the latest updates.
We have deprecated this legacy import/export. Can you please share details which specific files and how are you using it, for us to provide relevant info.
I checked whether the same application runs after the standalone installation of m43 - in this variant the application starts correctly.
EDIT:
It’s nice that all com.atlassian.* packages marked as deprecated from this list RFC-24: Data Center Grey API Removal were available for use until they were removed
We’re seeing our app fail to enable seemingly because something is null within StrutsModuleDescriptor
2024-02-27 15:03:52,905 ERROR [UpmAsynchronousTaskManager:thread-2] [atlassian.plugin.manager.DefaultPluginManager] There was an error loading the descriptor 'SR Confluence Space Admin Action' of plugin 'com.onresolve.confluence.groovy.groovyrunner'. Disabling.
-- url: /confluence/rest/plugins/1.0/ | userName: admin | traceId: 5246de9c99e4a796
java.lang.NullPointerException
at java.base/java.util.Objects.requireNonNull(Objects.java:221)
at com.atlassian.confluence.plugin.descriptor.StrutsModuleDescriptor.enabled(StrutsModuleDescriptor.java:139)
at com.atlassian.plugin.manager.DefaultPluginManager.lambda$notifyModuleEnabled$47(DefaultPluginManager.java:1890)
I just hit this too. Unfortunately, this looks like yet another random binary incompatibility that was introduced in the late 8.x release series.
You’re using atlassian-pocketknife-dynamic-modules to create xwork modules, right? It needs to be upgraded to work with Confluence 8.9. It looks like 2.0.1 will probably work, but I didn’t verify (I’m using a patched version with even more changes). EDIT to add: Although then your app probably becomes binary-incompatible with Confluence <= 8.8…
Atlassian added an overloaded method of ModuleDescriptor#init somewhere around atlassian-plugins v7.5 and they deprecated the old init signature, and this is apparently included in Confluence 8.9.
So when DynamicModuleDescriptorFactoryImpl in the old pocketknife calls moduleDescriptor.init(), it ends up looking for the old signature and calling the only init method that exists with that signature (from the AbstractModuleDescriptor superclass), rather than the new-signature method in the StrutsModuleDescriptor or XworkModuleDescriptor. This means that your module descriptor is never initialized, leading to the error above.
@scott.dudley , I owe you a beer (or alternative beverage).
Effectively everything in ScriptRunner gets registered dynamically, including the struts actions.
I haven’t confirmed you’re right yet, but I don’t doubt that you are.
Although then your app probably becomes binary-incompatible with Confluence <= 8.8…
Oh no…, does the new version of pocketknife use a method signature not available pre 8.8? That would be really irritating. I don’t want to have to fork it.
@rlander We don’t need Yet Another Thing to Fork, so I suspect that adding try { /* ... */ } catch (MethodNotFoundException e) { /* try again with the legacy method */ } is where we are going to end up. We’re patching atlassian-pocketknife-dynamic-modules anyway to eliminate the Guava and Apache Commons dependencies (to avoid bundling 3 Mb of crap that is barely used), so what’s one more change at this point? Drinks can be had at TEAM.
@WendyR, can you ask if this binary breaking change to the signature of com.atlassian.plugin.ModuleDescriptor#init can be reverted before 8.9 final release?
Also, since this issue will clearly come up again when this change hits in 9.0, would you (@WendyR) also be able to inquire if anyone in engineering can maintain the atlassian-pocketknife-dynamic-modules library? (It shouldn’t have the Guava/Commons dependencies anymore, and it should be compatible with both Confluence 8 and 9, without each vendor needing to perform this patching independently.)
Yeah, the problem with the ModuleDescriptor#init method when called from the dynamic module pocketknife code is an oversight from our side. We made the assumption that the init methods weren’t called outside of our core plugins code, which has now been proven false
The 2.0.0 version of the pocketknife dynamic modules is indeed compatible with Confluence 8.9, but will indeed cause problems with Confluence 8.7 and earlier because it expects the new module descriptor API to exist. Our current angle of attack is to implement and release a 1.2.0 version of this module (or perhaps 1.1.x, we’ll decide on what makes sense in the context of semantic versioning when we finish the implementation) that should work with both older and newer versions of Confluence. We’ll probably have to open up some nasty tricks to make it happen, but we agree that there should be a path forward for this Confluence feature release without having to do strange forking of dependencies.
For now the workaround would be to use 2.0.0 if you want to continue testing against the 8.9 EAP version of Confluence. We are still tied up in some urgent work to wrap up this week, but we expect an engineer to pick up this task by the start of next week, so we hope to have more to communicate on this front as next week goes on.
Thanks for finding this edge case and all the information around it!
Thanks for your help! And I’m glad that some engineers will be picking this up.
The pocketknife changes would certainly be helpful, but do you know if there is any chance of having a fix/workaround applied directly in the core product? (To preserve binary compatibility for a non-major release?) Because we are surely not the only people using the pocketknife utilities, and to fix it outside of the core product would first require vendors to stumble across this thread to realize that a specific dependency also needs to be updated.
I don’t know if that’s realistically doable. The changes are integrated across multiple layers, so it’d be a pretty significant investment to revert all of them or build a whole new approach around them. If we had known this would happen ahead of time, it’s something we would probably have done differently, but as it stands, I think we’re committed to this path.
For somebody who doesn’t use dynamic modules, things should keep working as they are. I don’t know how widely used the dynamic modules are, so the exact impact is not quite clear. I’ll chat with the Confluence folks to see if we can put some clear communication in the change notes for Confluence 8.9 around this, since I agree that it would be a bit hard to find here in CDAC.
@TomRijnbeek OK, thanks, that makes sense. Do you have (or can you get) any insight as to whether the package associated with the signature change is currently planned to be backported into 8.5 LTS? And if so, which release is targeted? It’s the sort of thing that could surprise vendors and customers alike if it shows up in a point release.
Since the new API in ModuleDescriptor is considered a new feature, especially in context of semantic versioning, there is no expectation that we can bring this API back to older versions of Confluence (or any product for that matter). It requires a Confluence feature release to introduce something of this scope.
For pocketknife-dynamic-modules specifically, we’ll ensure that the changes we makes remain compatible back to at least the latest Confluence LTS.
As of yesterday, we have released version 1.1.1 for pocketknife-dynamic-modules. In our testing, this version was compatible at least back to Confluence 7.19 (the latest Enterprise Release) and up to the latest 8.9 EAP. It will likely continue working for Confluence 9.0 onwards, though version 2.0.0 will continue being available for that as well.
This should address any problems reported here, and we’re keen to hear any feedback on whether this new version does indeed all of the problems you have encountered with this.
I found a strange bug. When compiling add-ons in version 8.9.0-m62 everything works fine and I don’t get any error messages, unfortunately when I upload such a compiled add-on to any version of Confluence I get an error
java.lang.NoSuchMethodError: 'boolean com.atlassian.confluence.security.PermissionManager.hasPermission(com.atlassian.conflu
ence.user.ConfluenceUser, com.atlassian.confluence.security.Permission, java.lang.Object)'
at com.appClass.page.getPage(FormatConversionResource.java:2
72)
Source code
import com.atlassian.confluence.security.PermissionManager;
...
private final PermissionManager permissionManager;
...
Page page = PAGE_OBJECT
if (!this.permissionManager.hasPermission(AuthenticatedUserThreadLocal.get(), Permission.EDIT, page)) {
...
