Hi @aovsyannikov ,
Happy to know that your problem is resolved. Please let us know if you face any further problems.
Thanks
1 Like
We came across this too and refactored things to use the plain AJS.I18n.getText. I think AJS.I18n.get was never documented anywhere and we just found it by coincidence a long time ago. I liked it much better though because it doesn’t rely on JS transformers.
1 Like
@fgrund, ah, interesting, and good to know that others stumbled over this as well.
@Kusal, @MarekTokarski, any insights you can share regarding the absence of AJS.I18n.get (see comment #475 for details)? If you’re not responsible for this, may I ask that you forward this question to whoever is responsible and can answer my inquiry. Thanks.
Hi @fgrund,
Thanks for spotting this. The com.atlassian.config.util package has been restored to the public API, this will be fixed in the next milestone.
1 Like
I’ve tried to reproduce this, without success. Could you come up with a reproducible example I can run, Or even just the pom.xml file?
@scott.dudley did you manage to get ServiceExceptionMapper to work for both Confluence 8 and 9?
I don’t think reflection can be used in this case. How did you solve this situation?
It is out of scope of my expertise, but I forwarded your question to the proper team. So far I’ve got an information the function you were asking was removed in Confluence 9 - Deprecated code paths removed in 9.0 | Confluence Data Center 8.9 | Atlassian Documentation
1 Like
The method AJS.I18n.get(pluginKey, successCallback, errorCallback) was deprecated back in Confluence 5.7, and finally removed in 9.0, so it will no longer interfere with the standard functions provided by WRM. You can find it listed in the Deprecated code paths removed in 9.0 page linked from the Preparing for Confluence 9.0 page you linked. This paves the way for us to enable the two phase i18n translation injection support in WRM and AMPS in a future Confluence 9.x release.
As @fgrund mentioned, switching to AJS.I18n.getText and the jsI18nTransformer is the best replacement today, as it will make it easy for your app to take advantage of two phase i18n translation injection as soon as that’s enabled.
1 Like
@richatkins, cool, thanks for the explanation. Makes sense 
Also thanks for pointing to the right documentation, and possible alternative. (also @MarekTokarski)
We’ll switch to AJS.I18n.getText() as well. Cheers. UPDATE: Fyi, we decided to create our own REST resource for fetching I18n texts from Javascript instead; was the easier solution for our codebase.
No reflection is required, because the base ExceptionMapper being extended is still defined in both JAX-RS v1 and v2. You do have to write the code to handle the exception though, as well as return a response object of the same shape that Confluecne would normally. The form outlined in my earlier post works for me on both Confluence 7 and 9.
You could alternatively try @aragot 's trick of declaring two <rest> resources, <restrict>ing each resource to a specific range of Confluence versions, and also scoping each <rest> resource to a different <package>.
1 Like
Hi Developer Community,
Just a general announcement that this week has been our final planned RC with us targeting GA next week.
In preparation for going GA we’ve made Confluence 9.0 available to be selected for app compatibility in marketplace.atlassian.com ahead of time for marketplace vendors. Huge thanks to you all for the hard work uplifting onto our new platform, we’re excited to start building on top of it with you and can’t wait to see customers benefit from the future value that it will unlock.
Cheers.
Thousands of lines of UPM log spam for clusters
When uploading apps onto a clustered DC instance, I also get a few thousand messages like this in the logs when installing an app (also with devmode enabled, if that makes a difference):
WARN [http-nio-8400-exec-4 url: /confluence/rest/plugins/1.0/installed-marketplace; user: admin] [atlassian.confluence.cache.TransactionalCacheFactory] logNonTxUsageWarning Update operation performed on transactional cache [HostLicenseCache] outside of a transaction. All updates to this cache should be performed from a thread with a valid transaction context.
@scott.dudley This kind of behaviour was there for years. It is not the new thing in Confluence 9.0
The purpose of it is to raise awareness if uppdate operation performed on transactional cache outside of a transaction. In this case, it is HostLicenseCache
It means we need to revisit the plugin and correct it
Hi Atlassian Team,
we are using InlineComments in our Confluenceapp and I am getting the following exceptions
as below
Caused by: java.lang.ClassNotFoundException: com.atlassian.confluence.notifications.batch.service.NotificationStoreService not found by MEMacro [316]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1591)
at org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1976)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:2116)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:986)
at org.eclipse.gemini.blueprint.util.BundleDelegatingClassLoader.findClass(BundleDelegatingClassLoader.java:136)
… 35 more
I don’t have any direct reference to the NotificationStoreService class in the app code .
I am not sure where to refer to and how to achieve the existing functionality in 9.0. I could see that the rest api is providing every less functionality.
Can someone help me in resolving the above error or directing me to the correct path with respect to changes on InlineComments ?
Thanks,
Aparna
Hi Atlassian!
While checking the compatibility of our plugins with Confluence 9 (using “9.0.0-rc2”), we currently get the following error which keeps the plugin from being enabled:
Package com.atlassian.json.jsonorg is internal and is not available for export to plugin
I saw some posts above that such issue might be caused by Confluence and should be resolved there, however, can you confirm this, or suggest anything I should try to resolve this issue?
Thanks a lot for any suggestions!
Alessio.
1 Like
Keeping apps compatible across major versions vs @AnonymousAllowed
Hi everybody!
We’ve managed to get our app in shape so the same JAR works for 9.0.0-rc2 as well as Confluence 6-8. This is important to us, we want to avoid having to care for multiple app versions, OBR builds etc. We had to do some hacky things to accomplish that, but that’s okay I guess.
The last thing missing is replacing @AnonymousAllowed annotations. As stated in the upgrade guide, @AnonymousAllowed is no longer available for import. The replacement @AnonymousSiteAccess requires using the new REST v2 component, so this would kill downwards compatibility. We want to avoid that at all costs.
Does anybody have a solution on how to make REST endpoints accessible to anonymous without having to maintain two app versions? I think it’s ridiculous having to maintain two different versions just because of one annotation. Any ideas are welcome. Hacky reflection modifications maybe?
1 Like
Hey @SteffenMueller,
I did it like described here by @AndrewMorton, and it worked well for me.
But I noticed, that somehow the @AnonymousSiteAccess was not working exactly like @AnonymousAllowed for me, so we used @UnrestrictedAccess instead of AnonymousSiteAccess, but I think this depends on the use case.
1 Like
Can you share your approach, please?
Especially about java version. Confluence 7 uses java 8, Confluence 8 can use java 11, Confluence 9 requires java 17. We tried to use different settings for compiler, but we still have errors like that:
Caused by: java.lang.UnsupportedClassVersionError: com/atlassian/confluence/plugins/highlight/service/DefaultSelectionStorageFormatModifier has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0.
Any thoughts would be appreciated.
Kind regards.
Hey @aorlov,
normally, you can set up your maven plugin to compile with Java 17 and set the target version to Java 8. It should work then on both platforms.
Described here: Apache Maven Compiler Plugin – Setting the -source and -target of the Java Compiler
For sure, you have to take care, that you do not use any features, that are not available on Java 8, but there are configurations in IDEs that take care of highlighting those, if you use Java 17 for building, but the language level could be set to Java 8.
2 Likes
Hello,
If I’m not wrong and following the page https://developer.atlassian.com/platform/marketplace/dc-apps-platform-7-preparing-for-secure-endpoints/, you can use the annotations under the package com.atlassian.plugins.rest.common.security, as this package will be accepted for the duration of Platform 7 for REST endpoints.
Gorka.
I would be interested if anyone has any other solutions for this. Having to depend on both REST v1 and REST v2 for one annotation is a bit bothersome.
@GorkaGalloBustinza @UnrestrictedAccess and other security-related annotations seem to only have been added to com.atlassian.annotations:atlassian-annotations at v4.0.2.
So depending on how far back you wish to support, you may not be able to use that package.
Confluence 7.19(.25) seems to export v2.2.1, which only has .security.XsrfProtectionExcluded. I couldn’t find any other replacement for @AnonymousAllowed / @UnrestrictedAccess in that version.
There may be a chance that one could bundle a newer version of com.atlassian.annotations:atlassian-annotations (at compile scope)? I’m unsure how that may conflict with the version exported by Confluence, though.
Looking around the place I couldn’t find any other annotations that could replace those, at least any that are still available as far back as Confluence 7.19. I thought about attempting to write a custom filter, but haven’t given it a shot after my previously mentioned solution worked OK.
Also, it is worth noting that the replacement for @AnonymousAllowed does seem to be @UnrestrictedAccess, as @m.frank said. I was unaware of @nunoMSsantos’ use case, so stuck with what they asked in their post.
2 Likes