Heads up, I hung the UPM by installing a plugin built w/ Java 17 on Confluence 7.19 running on Java 11 (using UPM plugin v 5.1.13).
I was doing some testing for backwards-compat and wanted to see what the Java17/Java11 incompatibility would look like to a user on a regular non-dev instance.
I could see in the logs that Spring failed while trying to load my Spring Java Config configuration class (because it “… has been compiled by a more recent version of the Java Runtime…”). That’s expected.
I have not often encountered a UPM that is hung so I thought I’d bring it up… maybe it’s not too hard to add some error handling in the UPM for this scenario? Maybe a kill switch in the “Installing…” dialog that would appear after X minutes?
It sat for quite a while (20 minutes?) until the server was restarted, which brought the UPM back to health.
java.lang.IllegalStateException: Cannot load configuration class: my.plugin.MyPluginConfiguration
at org.springframework.context.annotation.ConfigurationClassPostProcessor.enhanceConfigurationClasses(ConfigurationClassPostProcessor.java:415)
at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanFactory(ConfigurationClassPostProcessor.java:268)
at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.invokeBeanFactoryPostProcessors(AbstractDelegatedExecutionApplicationContext.java:532)
I got my app working with confluence m57 runtime in 9.x.But when I test the same jar working on Confluence 9.0.0-m57 on previous version like confluence 8.8 I am getting same error NoSuchBeanDefinitionException as(below) . I tried to use qualifier also but still same error .
Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'com.atlassian.confluence.content.CustomContentManager' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:801)
at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:224)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1372)
I have the similar issue (m72). My variables in my velocity templates are not visible.
This attribute data-src="$req.contextPath/plugins/myplugin/load.action?pageId=${parameters.pageId}&spaceKey=${parameters.spaceKey}"
Since Velocity apparently doesn’t perform variable assignments if the value to be assigned is null, you can maybe even add just one line for cross-compatibility with both 7.x and 8+:
There’s also the <velocity-allowlist> module-type that seems to be new in 9.0.0-m72 (even though it’s not listed in the version details). I imagine that its absence could also cause these types of problems, depending on where your parameters come from.
See “Allowlist method invocations within your Velocity templates” on the Preparing for 9.0 page.
@clouless
Yes, the module descriptor applies the allowlisted items to VelocityEngines directly, which means if the plugin(having the macro) marks an item under and reaches VelocityEngine with a render() call, the call would succeed. Please stay tuned for more documentation.
@aorlov
Yes, you would need to mark the java methods that your plugin uses in VM files. As @scott.dudley mentioned, please see “Allowlist method invocations within your Velocity templates” section under Preparing for Confluence 9.0 page.
Thanks
Just to reiterate existing discussion in this thread, Confluence 9.0 m68 onwards does indeed have the Velocity method allowlist enabled. Please refer to the “Allowlist method invocations within your Velocity templates” section in the “Preparing for Confluence 9.0” page for further details.
All method invocations within any Velocity template must be allowlisted. Plugins can only allowlist methods defined within their own plugins. The global allowlist is still being refined and we are open to feedback on any methods you feel should be allowlisted but are not currently so.
Thanks for reporting this. Apologies, the intent was very much to avoid exactly this. I’ve reported it to the team. This break is unrelated to Platform 7 and unrelated to Confluence 9.
Aside: You can use <quickReloadVersion> and enableQuickReload in the configuration of AMPS instead of <pluginArtifact. It mostly does the same thing.
Has there been any consideration to automatically allowlisting all public methods defined in an app’s <velocity-context-item> modules?
I recognize that the goal of the lockdown is to increase the DC security posture, and I can easily see the benefit to requiring allowlisting of specific methods in other contexts. But in the case of the velocity-context-item, its sole purpose is specifically to make methods available in the Velocity context.
I grant that there could be some security benefit if a vendor has accidentally listed an internal and insecure method implementation as public inside such a module, or if they listed a multipurpose bean instead of a dedicated class, but I also wonder how common this case is.
If it’s not possible to allowlist automatically, does Atlassian already have any tool that reads a .class and outputs the method signatures in a compatible format? The upshot of not having this is that every vendor has to go through every velocity-context-item module manually and allowlist every public method, which generates a bunch of work and which is prone to error.
Now that the velocity method allowlist is enabled is it time for Confluence’s base classes like ActionSupport to annotate their accessor methods (e.g., getActionErrors, etc.)? If we use those inherited methods in our velocity templates should we add them to our velocity-allowlist?
I feel like I probably shouldn’t put inherited methods like that into my velocity-allowlist because I’d expect the base class to annotate them as velocity property accessors, but I don’t see annotations on them (@ParameterSafe or @StrutsParameter). Maybe I SHOULD be adding my inherited …#getActionErrors() to my velocity-allowlist?
To assist you in populating your allowlist module descriptor, we’ve implemented the system property atlassian.velocity.method.allowlist.debug , which, when set to true , will disable the allowlist enforcement but continue to log errors for method invocations which are not allowlisted. You can then use the log output to inform your allowlist configuration. Note that you can allowlist only the methods defined on classes within your plugin.
I tried this JVM parameter but I saw that it doesn’t produce any log output in m72.
I tracked this down and I found that most Velocity logging is now turned off at the system level. If you want to actually see which of your methods are being denied due to the allowlist (which is supposed to be logged regardless of whether or not you enable the JVM flag above, but which is never shown), you need to visit the “Logging and Profiling” admin page and change the log level for “velocity” from FATAL to WARN. You can also fix it to persist across restarts in confluence/WEB-INF/classes/log4j.properties.
I also did not read the <velocity-context-item> docs carefully, and I foolishly assumed that the delimiter between multiple parameter types was a comma. I found instead (after fixing the logging, reloading my failing pages, and re-reading the doc page) that it instead requires a space.
