Preparing for Confluence 9.0 - EAP out now

Hi @clouless ,

Yes, the prehistoric radeox library has been removed from the public-visible API. The MacroUtils class itself is still there, but you won’t be able to load that class without radeox being visible.

This is something we can fix, should be working again in the next available milestone.

1 Like

Hi, @GorkaGalloBustinza, we’re in a pretty fluid environment at the moment so unfortunately aren’t able to say exactly, however, we’re hoping to get the first beta out either next week or the following couple of weeks after that. Stay tuned and we’ll be sure to provide an update here when it happens.

Hi @ashraf.teleb85 ,

Thank you for the report. Sorry for the inconvenience.

In order to better understand the issue, could I ask you to share more details?

  • What pages in Confluence do you see the errors on?
  • What error messages are there?
  • Is your app loading any version of underscore itself? If yes, which one and in what way?

While we have some idea of what might be going wrong, I’d like to be sure that we are addressing the right issue.

Thanks!

Edit 2024-05-16: In addition, would you mind updating Quickreload to 5.0.5 and report whether this behavior persists? We’ve published a fix to one of the likely causes of the issue - conflict with another instance of underscore loaded on the page. It would be nice to hear from you whether it was successful. Thanks again.

@mkemp With Confluence 9.0.0-m81 (potentially earlier milestones as well) there’s a new problem with the new velocity allowlisting and quickreload.

My plugin is rendering a velocity template like this:

Map<String, Object> velocityContext = ...;
return velocityHelperService.getRenderedTemplate("com/k15t/scroll/imagemap/macro/imagemap_img.vm", velocityContext)

The file is located in src/main/resources and therefore present within the installed plugin JAR file.

Now I get this in the logs:

2024-05-16 09:33:51,301 ERROR [http-nio-127.0.0.1-1990-exec-1 url: /confluence/display/TS/image+map, /confluence/pages/viewpage.action; user: admin] [velocity] log Template is not on the allowlist, but it was asked to be loaded. If you just added the file, first re-install the plugin. The template was: com/k15t/scroll/imagemap/macro/imagemap_svg.vm
 ...
2024-05-16 09:33:51,301 WARN [http-nio-127.0.0.1-1990-exec-1 url: /confluence/display/TS/image+map, /confluence/pages/viewpage.action; user: admin] [velocity] log ResourceManager : unable to find resource 'com/k15t/scroll/imagemap/macro/imagemap_svg.vm' in any resource loader.
 ...
2024-05-16 09:33:51,301 ERROR [http-nio-127.0.0.1-1990-exec-1 url: /confluence/display/TS/image+map, /confluence/pages/viewpage.action; user: admin] [confluence.impl.velocity.VelocityEngineRenderingService] getRenderedTemplate Failed to render template [com/k15t/scroll/imagemap/macro/imagemap_svg.vm]
 ...
org.apache.velocity.exception.ResourceNotFoundException: Unable to find resource 'com/k15t/scroll/imagemap/macro/imagemap_svg.vm'
	at com.atlassian.confluence.velocity.ConfigurableResourceManager.loadResource(ConfigurableResourceManager.java:379)
	at com.atlassian.confluence.velocity.ConfigurableResourceManager.getResource(ConfigurableResourceManager.java:298)
	at org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:1391)
	at org.apache.velocity.app.VelocityEngine.getTemplate(VelocityEngine.java:422)
	at com.atlassian.confluence.impl.velocity.VelocityEngineRenderingService.getTemplate(VelocityEngineRenderingService.java:84)
	at com.atlassian.confluence.impl.velocity.VelocityEngineRenderingService.getRenderedTemplateWithoutSwallowingErrors(VelocityEngineRenderingService.java:45)
	at com.atlassian.confluence.impl.velocity.VelocityEngineRenderingService.getRenderedTemplate(VelocityEngineRenderingService.java:70)
	...

This happens because Quickreload automatically registers my plugin’s resources directory in the plugin.resource.directories system property and the velocity resource loading mechanism replaces the ‘in-JAR’ URL for the template with the file URL because the template file is located in the resource directory.

Please note that I’ve disabled dev mode. If I manually enable it, then the template renders as expected because of the corresponding check in com.atlassian.confluence.setup.velocity.DynamicPluginResourceLoader#getResourceStream.
I’m also running a standalone standard Confluence installation, not an ‘atlas-debug instance’.

Regardless of that, shouldn’t the allowlist always allow files underneath plugin.resource.directories? Or should quickreload adapt plugin.resource.directories only if dev mode is enabled and leave it alone / unset it otherwise?

we used (CustomContentManager) ContainerManager.getComponent(“customContentManager”) to solve this

Please forgive the wall, hopefully it’s enough to cover not just for you, but also for everyone else

This diagnosis is exactly correct. FYI plugin.resource.directories is only meant to be set in development mode. If I’m reading what you’re saying correctly, then this is only a development or testing issue, not a production one.

QuickReload does have an API for setting system properties at runtime, you could use that to clear it and then the allowlist check should be happy again. Internally we tend to avoid installing QuickReload and other development things when we test so that the environment matches production. Of course you know AMPS can set system properties (I know you said you use a standalone installer in this case) and it can also be done in setenv.sh or other places in the standalone distribution.

Again on matching production, one of the things we’re considering is disabling all the development mode tooling when AMPS starts up the product for integration testing

There’s a new version of Platform with an updated version of Atlassian Template Renderer coming that resolves this. It flat disables the filetype and file allowlist (of course when using the ATR API).

The filetype and file allowlist will of course still be turned on for Velocity engines gotten directly from the products (Jira and Confluence have their own APIs for this), this allowlist should only take effect for files on the filesystem (not inside of JARs nor OSGi bundles). We’re adding development mode niceties so it doesn’t hit as hard.

Allow of these changes I just described should be coming the next Confluence 9 milestone.

We’re trying to get a new version of AMPS that avoids setting plugin.resource.directories during tests so that this matches production and plugin engineers could think about this complexity less.

As an aside: QuickReload doesn’t listen to plugin.resource.directories functionality, Atlassian Plugins does so you can use this without FastDev, QuickReload, etc.

1 Like

Thanks @mkemp, it’s something in between production and dev mode actually :smiley:

I typically keep a Confluence instance running all the time that’s independent of the app project
because I don’t want to lose the instance’s data when I run mvn clean in the project I’m currently working on. That instance (standard tar.gz distribution, standalone postgres DB) has dev mode disabled so I get the same behaviour as our customers.

Yet I still want quickreload, so I just install it in the instance like any other plugin and I have a ~/quickreload.properties file that contains entries for the plugin project directories I want to have reloaded automatically.

Now the problem is that QR automatically sets the plugin.resource.directories property to the corresponding src/main/resources folders for each of the monitored projects (See DirectoryTracker in QR). And then that interferes with the velocity allowlist.

This diagnosis is exactly correct. FYI plugin.resource.directories is only meant to be set in development mode.

That’s exactly what I want, but not what I currently get, because QR doesn’t seem to care about dev mode when setting the property.

I’ve followed the advice of removing the plugin and just use <enableQuickReload>true</enableQuickReload> to get the same result.
It works this way. Previously, I had both the plugin and enableQuickReload

Thanks

Yeah, we’re looking to make a change in Atlassian Plugins which should land in the next week or two into Confluence. IMO it shouldn’t matter why the plugin.resource.directories system property is set, it shouldn’t be respected in production. If anything changes, I’ll let you know.

1 Like

When I try to enable some of our apps on 9.0.0-m92, I run into enable timeouts:

2024-05-21 16:41:38,525 WARN [UpmAsynchronousTaskManager:thread-2] [atlassian.plugin.manager.PluginEnabler] isFinished Plugin 'com.k15t.scroll.scroll-html' did not enable within 5 seconds. The plugin should not take this long to enable. Will only attempt to load plugin for another '25' seconds.
...
2024-05-21 16:42:03,645 ERROR [UpmAsynchronousTaskManager:thread-2] [atlassian.plugin.manager.PluginEnabler] actualEnable Unable to start the following plugins due to timeout while waiting for plugin to enable: com.k15t.scroll.scroll-html

And then a few minutes later:

2024-05-21 16:46:33,517 WARN [Spring DM Context Creation Timer] [internal.dependencies.startup.DependencyWaiterApplicationContextExecutor] timeout Timeout occurred before finding service dependencies for [NonValidatingOsgiBundleXmlApplicationContext(bundle=com.k15t.scroll.html-server, config=osgibundle:/META-INF/spring/*.xml)]
2024-05-21 16:46:33,520 ERROR [Spring DM Context Creation Timer] [plugin.osgi.factory.OsgiPlugin] logAndClearOustandingDependencies Plugin 'com.k15t.scroll.scroll-html' never resolved service '&confluencePropertySetManager' with filter '(&(objectClass=com.atlassian.confluence.core.ConfluencePropertySetManager)(objectClass=com.atlassian.confluence.core.ConfluencePropertySetManager))'
2024-05-21 16:46:33,521 ERROR [Spring DM Context Creation Timer] [plugin.osgi.factory.OsgiPlugin] onPluginContainerFailed Unable to start the plugin container for plugin 'com.k15t.scroll.scroll-html'
org.springframework.context.ApplicationContextException: Application context initialization for 'com.k15t.scroll.html-server' has timed out waiting for (&(objectClass=com.atlassian.confluence.core.ConfluencePropertySetManager)(objectClass=com.atlassian.confluence.core.ConfluencePropertySetManager))
	at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.timeout(DependencyWaiterApplicationContextExecutor.java:489)
	at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.access$000(DependencyWaiterApplicationContextExecutor.java:54)
	at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$WatchDogTask.run(DependencyWaiterApplicationContextExecutor.java:109)
	at java.base/java.util.TimerThread.mainLoop(Timer.java:566)
	at java.base/java.util.TimerThread.run(Timer.java:516)
2024-05-21 16:46:33,582 ERROR [Spring DM Context Creation Timer] [extender.internal.support.ExtenderConfiguration] onOsgiApplicationEvent Application context refresh failed (NonValidatingOsgiBundleXmlApplicationContext(bundle=com.k15t.scroll.html-server, config=osgibundle:/META-INF/spring/*.xml))
org.springframework.context.ApplicationContextException: Application context initialization for 'com.k15t.scroll.html-server' has timed out waiting for (&(objectClass=com.atlassian.confluence.core.ConfluencePropertySetManager)(objectClass=com.atlassian.confluence.core.ConfluencePropertySetManager))
	at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.timeout(DependencyWaiterApplicationContextExecutor.java:489)
	at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.access$000(DependencyWaiterApplicationContextExecutor.java:54)
	at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$WatchDogTask.run(DependencyWaiterApplicationContextExecutor.java:109)
	at java.base/java.util.TimerThread.mainLoop(Timer.java:566)
	at java.base/java.util.TimerThread.run(Timer.java:516)
2024-05-21 16:46:33,583 ERROR [Spring DM Context Creation Timer] [internal.dependencies.startup.DependencyWaiterApplicationContextExecutor] fail Unable to create application context for [com.k15t.scroll.html-server], unsatisfied dependencies: Dependency on [(&(objectClass=com.atlassian.confluence.core.ConfluencePropertySetManager)(objectClass=com.atlassian.confluence.core.ConfluencePropertySetManager))] (from bean [&confluencePropertySetManager])
org.springframework.context.ApplicationContextException: Application context initialization for 'com.k15t.scroll.html-server' has timed out waiting for (&(objectClass=com.atlassian.confluence.core.ConfluencePropertySetManager)(objectClass=com.atlassian.confluence.core.ConfluencePropertySetManager))
	at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.timeout(DependencyWaiterApplicationContextExecutor.java:489)
	at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor.access$000(DependencyWaiterApplicationContextExecutor.java:54)
	at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$WatchDogTask.run(DependencyWaiterApplicationContextExecutor.java:109)
	at java.base/java.util.TimerThread.mainLoop(Timer.java:566)
	at java.base/java.util.TimerThread.run(Timer.java:516)

Did you only restore the com.opensymphony.module.propertyset OSGi export, but then did not keep the ConfluencePropertySetManager bean available to plugins?
We need that service for listing property keys and for working around broken caching in ContentPropertyManager.

1 Like

Hello,

Continuing with Platform 7 upgrade in progress: Learn about the first highlights and changes - #73 by FirasMkaouar, I have the same result with 9.0.0-m92:

Chain 1:
  com.comalatech.workflow [com.comalatech.workflow [294](R 294.0)]
    import: (osgi.wiring.package=javax.ws.rs.core)
     |
    export: osgi.wiring.package: javax.ws.rs.core
  com.atlassian.plugins.rest.atlassian-rest-v2-plugin [com.atlassian.plugins.rest.atlassian-rest-v2-plugin [165](R 165.0)]

Chain 2:
  com.comalatech.workflow [com.comalatech.workflow [294](R 294.0)]
    import: (osgi.wiring.package=com.atlassian.mywork.model)
     |
    export: osgi.wiring.package=com.atlassian.mywork.model; uses:=javax.ws.rs.core
  com.atlassian.mywork.common-plugin [com.atlassian.mywork.common-plugin [131](R 131.0)]
    import: (osgi.wiring.package=javax.ws.rs.core)
     |
    export: osgi.wiring.package: javax.ws.rs.core
  org.apache.felix.framework [org.apache.felix.framework [0](R 0)] Unresolved requirements: [[com.comalatech.workflow [294](R 294.0)] osgi.wiring.package; (osgi.wiring.package=com.atlassian.mywork.model)]

Am I missing something or mywork-api should be modified to avoid this chain conflict ?

thx!