Add an OSGi import for the required package.
This is a test setting, so I am still unsure how I am supposed to fix this in my test? Could you please explain? 
Using m119 the jakarta.mail dependency is provided by Confluence again - thank you!
However, when I try to OSGi-import one one the following:
com.sun.mail.imap,
com.sun.mail.pop3,
com.sun.mail.smtp,
I get the classic BundleException:
Unable to resolve plugin: missing requirement [plugin] osgi.wiring.package; (osgi.wiring.package=com.sun.mail.pop3) Unresolved requirements: [plugin] osgi.wiring.package; (osgi.wiring.package=com.sun.mail.pop3)]
Can you please make these importable?
In that case, it seems like a generic Maven project dependency issue rather than any actual issue with the EAP.
These libraries are no longer included with the product, please bundle them with your plugin if required.
@AndreasEbert, I understand that the Bandana is deprecated, I was just wondering which table is now storing the data to confirm that my implementation is correct.
Anyway, I found from the previous post that the data is now being stored in the PLUGIN_SETTING table. Thank you very much for your help.
1 Like
@Kusal regarding the jakarta.mail imports 
regarding the error when calling new com/atlassian/confluence/setup/settings/Settings.class it seems that my maven repo was corrupted.
Now I realize the error is a bit deeper: The AttachmentSecurityLevel.class uses com.atlassian.http.mime.DownloadPolicy
However, this dependency is not provided by confluence. If I add the following dependency, its working fine:
<groupId>com.atlassian.http</groupId>
<artifactId>atlassian-http</artifactId>
Will this dependency also be provided by Confluence in a future milestone?
It won’t be made a transitive dependency of the main confluence artifact if that’s what you’re asking - specify it explicitly as you’ve done if you depend upon it.
If you’re asking whether it can be OSGi imported from your plugin, yes the packages within this artifact are already OSGi available.
Thank you, @Kusal
Yes, I was wondering whether you would make this a transitive dependency of confluence. Thanks for the explanation. This answers all my questions then
We are aware of an issue installing plugins during development with AMPS 9.4.0 - please refrain from upgrading until further notice.
Please also note that in the next EAP we will be removing the org.apache.commons.fileupload2 packages from OSGi availability. If you rely on these packages you should bundle (compile scope) the corresponding dependency instead.
Hi,
We received this error upon crowd setup from Confluence (m-96). It’s a custom crowd directory. I just wanted to see if this error is familiar and perhaps fixed in newer versions? I wondered if this has something to do with bundled crowd version or if there is another explanation. Thanks!
Hi @EliasBrattliSorensen
The error seems to suggest the response from the directory is malformed. Have you confirmed this custom directory works with other Confluence versions? If so, could you also confirm whether the problem is still reproducible with the latest Confluence EAP?
AMPS 9.4.1 is now available with a fix.
Hi all,
We’re wrapping up the EAP program for Confluence DC 10.0, with the beta release scheduled in the coming days. Your valuable feedback throughout this process has been instrumental in improving the release quality and ensuring compatibility with marketplace plugins. Please continue to report any new issues you discover in the upcoming beta release thread.
On a related note, I’m pleased to announce the release of Jakarta Adapters v0.2.5. We’ve lowered the minimum Java version requirement to Java 11, which enables its use in potential cross-major compatible plugin JARs. Special thanks to @jens for contributing this improvement!
Just to reiterate our stance on cross-major plugin compatibility: while our official recommendation is to publish separate major versions of your plugin for each major product version (and update your marketplace compatibility matrix accordingly), you’re welcome to pursue cross-major plugin JAR compatibility if you prefer. We won’t provide technical support for this approach, but we know several plugins have successfully implemented it.
As a helpful tip, remember you can restrict plugin modules by application version using the following syntax:
<rest key="rest" path="/myplugin">
<restrict application="confluence" version="[10,)"/>
<package>com.atlassian.marketplace.rest.jakarta</package>
</rest>
2 Likes
Hi @Kusal
I was wondering what Atlassian’s plans are for the ContentPropertyManager (not ConfluencePropertySetManager). In Confluence 10 it seems you’ve just reduced the API by removing the accessors for text properties but otherwise it seems to remain fully functional.
In contrast to that the ConfluencePropertySetManager has been announced to be read-only in 10.x and scheduled for removal in Confluence 11.
I understand that the overall goal here is to get rid of the OS propertyset infrastructure eventually.
Some of our apps store a lot of properties in this storage (10-15 per Confluence page). If you remove OS propertyset in 11.0, will you also automatically migrate the existing data to a new storage, similar to what you have done with Bandana?
We also use the PropertySet.getKeys() API for listing property keys in scenarios where they are dynamic and we can’t hardcode them. It doesn’t seem like there is any replacement API for this yet, but we’d need it latest when the PropertySet APIs are finally removed.
Wouldn’t it therefore make sense to introduce something like ContentPropertyManager.getPropertyKeys(ceo) in Confluence 10.0 so that apps can switch as quickly as possible to only the ContentPropertyManager API? Similar to what you’ve done in the Bandana->PluginSettings transition, where you’ve added a similar getKeys method.
Even if we were to later on manually migrate properties in a plugin upgrade task to a different storage, we’d also need such a key-iterating API.
Tbh. I really hope it doesn’t come to this, because a PluginUpgradeTask migrating properties of millions of pages (I know of several such big instances) using the current high-level APIs will run a very long time …
Thanks,
Jens
Hi @jens
Great questions.
ContentPropertyManager and ConfluencePropertySetManager were both backed by the PropertySet library. However, the latter exposed the PropertySet APIs directly, whereas the former kept them as an implementation detail.
While our intention is indeed to remove the PropertySet library entirely, the database storage format it uses isn’t problematic in itself (unlike Bandana which uses XML).
From Confluence 9.4 onwards, ContentPropertyManager is no longer backed by the PropertySet library but continues to use the same database table - we now interact with it directly and have unified the String and Text types for simplicity. We will remove ConfluencePropertySetManager alongside the PropertySet library in 11.0, but String/Text properties will remain accessible via ContentPropertyManager. No data migration will be required.
Regarding the suggestion to add a #getKeys API - this is a sensible addition, but unfortunately it’s too late to commit to this for 10.0. I’ve added it to our backlog to implement prior to 11.0.
Thanks, this is good news, looking forward to the new API in Confluence 11 then
One more question: Is the modified ContentPropertyManager still using the same cache (wrt. the cache management screen) as in previous versions? That’s important to know for our support folks, because we often have to instruct customers to tune their content property caches.
Yes, it is still using the ‘Content Properties’ cache in the UI (although the internal cache identifier has changed).
1 Like
Hello,
While injecting com.atlassian.confluence.themes.persistence.PersistentDecoratorDao in one of our classes, we ran into this exception:
org.eclipse.gemini.blueprint.service.ServiceUnavailableException: service matching filter=[(objectClass=com.atlassian.confluence.themes.persistence.PersistentDecoratorDao)] unavailable
at org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceDynamicInterceptor.getTarget(ServiceDynamicInterceptor.java:405)
at org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:60)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:137)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:124)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
at org.eclipse.gemini.blueprint.service.util.internal.aop.ServiceTCCLInterceptor.invokeUnprivileged(ServiceTCCLInterceptor.java:70)
at org.eclipse.gemini.blueprint.service.util.internal.aop.ServiceTCCLInterceptor.invoke(ServiceTCCLInterceptor.java:53)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
at org.eclipse.gemini.blueprint.service.importer.support.LocalBundleContextAdvice.invoke(LocalBundleContextAdvice.java:57)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:137)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:124)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:223)
Is this service no longer provided?
Advices on how to fix this would be appreciated.
Thank you,
Sasha
1 Like
@Kusal Will there be an update to https://mvnrepository.com/artifact/com.atlassian.plugins/atlassian-plugins-osgi-javaconfig that is not using javax.annotation?
1 Like
No, please use the com.atlassian.confluence.themes.CustomLayoutManager instead.
Please explicitly exclude those packages from your plugin <Import-Package> instructions for the time being with: !javax.annotation.*,