If you’re still stuck trying to find the source of the banned import, you can follow the steps I posted here to debug the build process and see exactly where the OSGi package reference is being picked up.
And if it’s not found at build time (meaning the banned package is not listed in your META-INF/MANIFEST.MF) and the error only occurs at runtime when loading your plugin, then you need to double-check that you don’t have any <component-import>s whatsoever hidden somewhere in your .JAR, in a nested .JAR, or somewhere in an .OBR.
I agree. The current state of this solution is really hard to maintain.
I tried to use " Allowlist method invocations within your Velocity templates" in my addon and I should do so many duplicates. I have one DTO, but should declare every method.
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?
I just spent an hour trying to track down a similar problem. It looks like m97+ validates the entire <velocity-allowlist> module, and if there is an error in any single method name, the entire allowlist will be disabled.
Look for log entries like this during plugin load:
WARN [allowlist.impl.internal.PluginAllowlistConfigurator] getModuleMethodAllowlist Invalid method(s) METHODNAME defined for class CLASSNAME- disabling Velocity Allowlist plugin module YOURMODULE
In my case, I had one method parameter that was accidentally a long and not a Long, which are represented separately in the allowlist (long vs java.lang.Long).
As an aside, while debugging this, I discovered that <velocity-allowlist> seems to support <class> and <package> elements, in addition to the documented <method> element. I have not tried these.
In recent versions of Confluence 9 (also the last one), some of our resources (JS) randomly do not load in Chrome with the error ERR_INVALID_CHUNKED_ENCODING. These scripts are loaded dynamically depending on what is executed in the application GUI by loading them on demand. The same files opened in a new tab load correctly.
The same scripts in Confluence 8 work correctly every time and the above problem does not occur.
Everything tested on the same network and the same machine.
This is correct. Confluence 9 and Platform 7 are both compiled targeting Java 17 bytecode. If you compile against that version, the resulting classes can only be used on Java 17.
If you need to generate artefacts that work on Java 11 and older Confluence versions, you’ll need to compiler against those older versions. Generally, you’ll get better results compiling against your oldest supported Confluence version, and testing against the newer ones. If your app compiles against Java 11 and Confluence 7/8, the class files will still work on Java 17.
The com.octo packages are no longer exported from the OSGi system bundle as of Confluence 9.0, as you’ve noticed. This shouldn’t be a problem, though, unless your app is trying to use those classes that you listed, which do depend on com.octo, in which case it’ll transitively pull it in (or try to). I can’t think of any other reason why this would happen.
I checked again against the classes, that are using the com.octo dependency and finally found the place that is causing the issue.
We are using the com.atlassian.confluence.pages.actions.ViewPageAction what imports the com.atlassian.confluence.security.CaptchaManager, what is using the com.octo.captcha.service.image.ImageCaptchaService import.
However, I think the solution would be, to include the com.octo dependency into my pom and compile it, right? So that’s what I wanted to try, but the problem is, that com.octo has a high vulnerability and is depending on an import com.sun.image.codec.jpeg from Java 7. So it is still not possible to install it on Confluence 9.
Any suggestions here? Should I use something else instead of the ViewPageAction class?
You cannot generally package something that is already included in the system bundle, because you will end up with two different versions of the same class and (at best) ClassCastExceptions whenever something references it.
Also, Spring Scanner OSGi imports do not pull in classes transitively, meaning you need to directly use a method before the referenced classes will be listed in the imports. So, if you’re using one of the referenced classes from a banned package directly, then you need to find a way to stop doing that. If you are not, then you have a different problem.
In the latter case, your next step for debugging is to check the META-INF/MANIFEST.MF after a build to see if the banned package is listed there. If it is listed there, see my above post about adding debug breakpoints to Maven, and use that to figure out exactly where the reference came from within your code, and fix that code.
If it is not listed in the MANIFEST.MF, then you either have a <component-import> that you forgot about, or else your plugin is not 100% properly configured as a transformerless plugin which causes it to be transformed anyway (meaning you need to double-check all of the Spring Scanner configuration instructions).
The transformation process does include all transitive dependencies, but they are added at runtime, so you will still see those types of errors even if the dependency is not listed in your MANIFEST.MF.
(Atlassian should really just modify the plugin system to refuse to load any requires-transformation plugin, because none of them will work in Platform 7 anyway due to the banned dependencies.)
Hey @scott.dudley,
thanks for the support. I love your post about debugging the Analyzer class! I’ll definitely document it internally for future problems too
However, also with debugging there, I was not able to find the com.octo import. But with the hint from @kmacleod, I was finally able to find where it comes from. As I mentioned in my other post, it’s related to the ViewPageAction class, we extend. To be honest, I do not completely understand how this should work now? I think there is no alternative for us to this class to extend from, and how can Atlassian use it in their CaptchaManager class, without providing the dependency (also with the dependency that depends on Jira 7 imports)? - is this working because of the last thing you mentioned, that Atlassian adds the dependencies at runtime?
However, for now, I commented the part out, where we extend from this class, just to be able to skip this error for now, and “having fun” with the next upcoming errors.
I’ve had a dig around in ViewPageAction, and the CaptchaManager field was only in there for historical reasons, so I’ve removed it, which should fix your immediate problem when the next EAP comes out.
More generally, though, using ViewPageAction in your own plugin is going to be brittle, since that class (and most of the other action classes) are not intended for re-use outside Confluence core.
What bundle it actually cannot resolve? osgi.wiring.package or bucket.user
In my manifest there is not import for both of these packages, so I am very confused what it is complaining about?
@RomanStoffel I believe it’s referenced transitively from com.atlassian.confluence.user, which extends the package. Maybe it’s depending on how your imports are constructed with resolution and version?
I still do not understand how the mechanism works though. There is nothing in the manifest. In his post he mentioned that he can see the difference in some imports.
Basically, what I’m curious about: How can I see the ‘real imports’, if somehow stuff is sneaked in by magic? Because again, that bucket.user does not show up in the generated OSGi manifest. So there is some secret mechanism in OSGi / or Atlassian which adds stuff?
Is so, how can I inspect that?
Ok:
Yes, there is some mechanism which transforms / edits the plugin OSGi bundle. I was not aware of that. Is that documented somewhere?
Basically, if you install the app, the app will be transformed and put into {confluence}/home/plugins-osgi-cache/transformed-plugins/{your-plugin-with-some-extra-timestamps}.jar.
If I open that .jar and inspect the manifest, then I have a gazillion extra imports, including the bucket.user.
I’ll switch to the Spring Config things and I see =). Or is there a way to opt out of any OSGi manifest manipulation?
Update: Trying to switch to Spring Java configuration. But I’m getting unexpected exceptions, see here. Unrelated to Confluence 9 itself, but it blocks me from progressing with Confluence 9 itself.
