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.
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?
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.
Thanks @mkemp, it’s something in between production and dev mode actually 
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.directoriesis 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.
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.
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!
Hey together,
I’m working on the compatibility for our Confluence app and doing all the steps suggested.
Now I’m at a point, where I’m not able to find the cause and also no workaround. So I’m not completely sure, if it’s a bug in the EAP, or if I’m doing something wrong - maybe some of you have the same problem?
If I install our app, I get the following error in the logs:
08:36:31,325 ERROR [UpmAsynchronousTaskManager:thread-1] [plugin.manager.PluginEnabler] actualEnable Unable to enable plugin ... <-- importent part is below -->
Caused by: org.osgi.framework.BundleException: Unable to resolve com.decadis.confluence.spaceadmin [295](R 295.0): missing requirement [com.decadis.confluence.spaceadmin [295](R 295.0)] osgi.wiring.package;
(&(osgi.wiring.package=com.octo.captcha.service.image)(version>=0.0.0)(version<=0.0.0)) Unresolved requirements: [[com.decadis.confluence.spaceadmin [295](R 295.0)] osgi.wiring.package; (&(osgi.wiring.package=com.octo.captcha.service.image)(version>=0.0.0)(version<=0.0.0))]
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:408)
... 106 more
I checked, where the package com.octo.captcha.service.image, that comes from the dependency com.octo.captcha:jcaptcha (mvn repo - if I’m not wrong). However, I was not able to find this dependency in the mvn dependency:tree result, but my guess was the confluence core dependency, so I checked the JAR file with the command jdeps -verbose confluence-9.0.0-m92.jar and found it.
The import is used at these places:
com.atlassian.confluence.security.CaptchaManager -> com.octo.captcha.service.image.ImageCaptchaService not found
com.atlassian.confluence.security.ConfluenceImageCaptchaService -> com.octo.captcha.service.image.ImageCaptchaService not found
com.atlassian.confluence.security.DefaultCaptchaManager -> com.octo.captcha.service.image.ImageCaptchaService not found
com.atlassian.confluence.security.seraph.ConfluenceElevatedSecurityGuard -> com.octo.captcha.service.image.ImageCaptchaService not found
com.atlassian.confluence.servlet.ImageCaptchaServlet -> com.octo.captcha.service.image.ImageCaptchaService not found
I tried it with add this line to the <Import-Package> part inside the plugin configuration of the pom, but no luck:
<Import-Package>
...
!com.octo.captcha.service.image
...
</Import-Package>
Does somebody of you have an idea, what I should do to fix that? You would save my day!
Thanks!
@m.frank Could be just a problem in your example here, but make sure to conclude the exclusion line with a comma. I’d also recommend to always append .* so potential sub-packages are also excluded (this will still include the package itself).
For example:
<Import-Package>
!com.another.exclude.*,
!com.octo.captcha.service.image.*,
... more excludes ...
*
</Import-Package>
Hey @jens,
thanks for the quick reply, but both things are already there (maybe I should share the whole block )
<Import-Package>
org.springframework.osgi.*;resolution:="optional",
org.eclipse.gemini.blueprint.*;resolution:="optional",
org.apache.struts2.interceptor.parameter;resolution:=optional,
!com.atlassian.jira.util.stats, <!-- interesting to see jira here :D - from confluence-core, maybe from the jira.integration package -->
!com.google.common.*, <!-- guava - is used in com.atlassian.activeobjects:activeobjects-plugin -->
!com.sun.jna, <!-- jna - not sure where it's used -->
!org.apache.commons.logging.*, <!-- commons-logging - is used in org.springframework:spring-beans -->
!org.apache.http.*, <!-- httpclient - comes from org.apache.httpcomponents:httpcore, what is included in org.apache.httpcomponents:httpclient -->
!org.apache.xerces.*, <!-- xerces - used in com.atlassian.confluence:confluence-core -->
!com.octo.captcha.service.image, <!-- com.octo.captcha:jcaptcha - used in com.atlassian.confluence:confluence-core -->
*
</Import-Package>
Also tried it with !com.octo.captcha.service.image.*,.
What confuses me as well, is that the error points to version 0.0.0 - what makes actually no sense, right?
@m.frank Are you still using component-import in your plugin XML? If so, you will need to switch to Spring Scanner or Java Config. The component-import is not compatible with platform 7. I suspect you’re using an import that has a method (or inherits from a class that has a method) that uses that class.
Hey @scott.dudley,
thanks for the response.
No, we do not use component-import in our plugin XML file. We switched to Spring Scanner some versions ago already.
Thanks for the hint. I will double check, if I can find any relation to that class in our code.
Cheers,
Marcel
Hey Guys,
another question. Since with platform 7, the dependency com.atlassian.upm:upm-api is upgraded to version 7.0.0, I’m not able to build my app with another version than Java 17.
Is that correct and intended to be?
If yes, how can I provide compatibility with older Confluence version using Java 11?
Thanks,
Marcel
@m.frank If you’re not using component-import, then there has to be something in your code or in one of the META-INF/lib dependencies (which you can usually unzip and then grep for the poison string).
You also don’t even need to try to load your JAR to test: you will see the reference in META-INF/MANIFEST.MF.
You will need to upgrade to Java 17 to build, but you can still create bytecode compatible with older Java versions by updating the maven-compiler-plugin configuration with <target>1.8</target> (or whatever).
I’m having Velocity method invocations blocked even though I have them allowlisted in the descriptor file. This happens in m97 but not in the previous milestong. Has anything changed?
thx!
Hey @scott.dudley,
thanks for the response.
Great idea. I checked my META-INF folder (and also my whole target folder) and searched for the import (or also just for the string octo), but no luck. For sure, before searching I extracted all the jar files inside META-INF/lib, but still no luck.
I will investigate further, if I can find the cause somehow. But for sure, if there is somebody who knows what’s wrong, I’m looking forward to your hint!
We use the <target>1.8</target> configuration setting. So we will just keep it then, and work with Java 17. I just hope that this is really secure and works.
Thanks!