Take a look at the documentation at Preparing for Confluence 8.8 | Confluence Data Center 8.8 | Atlassian Documentation, where a newly introduced Struts OGNL Allowlist is described and how you can add entries to it.
thanks, I seen that doc, but I am not clear how and where to configure them as I don’t have <struts> tag at the moment in my code base. If you have any sample handy that will be helpful
1 Like
Okay, I’m officially confused, and I think not because I’m just too dumb.
Can someone please confirm or deny the following:
- Can I build a single version of an app that is compatible for both 7.x (possibly only from 7.13 or 7.19 on) AND 8.x including 8.8 at all
- Can I build a single version of an app that is compatible for both 8.x and future 9.x at all
- Can I, at least, build a single version of an app that is compatible for both 8.7 and earlier and 8.8? Surely that should be possible, right?
It is incredibly hard to piece together all those bits of information - sometimes it’s buried in a thread here, sometimes on a page multiple levels down the hierarchy. Sometimes it seems you need to change some dependencies out of the blue (e.g. switching from javax.servlet-api to the jakarta packages - I could only find this here in some thread).
It’s not helped by the fact that a lot of the official documentation out there is woefully outdated or just plain wrong and that there is never any indication for which versions it actually applies.
Is there any comprehensive migration guide? Is there any version of the SDK+assorted tools that doesn’t drive you nuts? E.g. I can see the official SDK still refers to the old deprecated (?) atlassian maven repo while apparently you are supposed to migrate?
We understand the need for change and we would even be willing to support two branches. However, the current state of the ecosystem makes it near impossible to maintain an application for someone who isn’t prepared to spend all their time (and maybe also isn’t a Spring/j2EE wizard) onto fixing these issues.
We don’t even integrate with confluence on a level that is comparable to what you other guys do and still we have to invest so much time into these framework issues that I have to question whether it’s economically feasible at all.
5 Likes
Can I build a single version of an app that is compatible for both 7.x (possibly only from 7.13 or 7.19 on) AND 8.x including 8.8 at all
@JasmineMller It seems yes, here is a personal example of mine, which works with 7.19-to-8.8: GitHub - requirement-yogi/demo-confluence-polyfills
1 Like
I believe I saw an Atlassian mention somewhere (although I can’t find it buried in one of the dozen 8.x-related breaking change threads) that the <struts> type is the same as the <xwork> module for 8.x+, so you can try adding it there.
I seem to remember that too… there is a thread around here someplace that talks about <struts> vs <xwork> and their possible equivalence in certain versions.
All of the new docs about OGNL allowlists and <struts> config could use some enhancement to explain the story… and tell devs exactly what to do and when to do it… the story about <xwork> vs <struts>.
I had the same thoughts as @ramakrishna when I read the OGNL docs… I saw <struts> and added it to my notes as a mystery to figure out.
https://developer.atlassian.com/server/confluence/struts-module/
I’m seeing a warning logline in Confluence 8.8.0 for my plugin. The WebResourceTemplateSetFactory thinks there is a missing descriptor for the AUI flag widget:
2024-02-22 19:41:52,447 WARN [myinstance url: /myUrl,
/pages/viewpage.action; user: myUser]
[atlassian.soy.impl.WebResourceTemplateSetFactory]
findRequiredTemplates Some module descriptors are either missing or disabled;
soy compilation may fail.
Missing descriptors: [com.atlassian.auiplugin:flag]
-- page: 460292224 |
referer: https://myBaseUrl/display/myspacekey/mypage |
traceId: ef1e17cebe102329 |
userName: myUser | action: viewpage | url: /display/myspacekey/mypage
It references “com.atlassian.auiplugin:flag”, saying it is a missing descriptor, but the proper web resource key is “com.atlassian.auiplugin:aui-flag”
Not sure why the warning mentions a web resource key that I am not using and is not proper for using the AUI flag widget.
I do use the AUI flag widget but it is not used in a web-resource that has a soy template, so I’m also not sure why the warning is talking about soy templates. The one soy template in my plugin is in a web-resource that does not use the AUI flag and that soy template is rendering fine.
I’m ignoring it for now… I need to move on… but I see nothing like this mentioned anywhere so I’ll put it here in case it is a WRM problem that Atlassian needs to know about.
All my Apps broke because of this when releasing compatibility with 8.8.0, and I had no idea it was broken until after I released the new version and customers started screaming, how are we even to test this scenario, what a stupid error by Atlassian!
Risk is high right now. I have a suite of plugins that came from one of the original plugin providers. I think one of them might be the first one published? If not the first, it is close to it.
These plugins have been running smoothly forever with a library of integration tests and unit tests that do not provide 100% code coverage. Now we are in a situation where 100% code coverage is necessary because there are so many runtime breakage scenarios. Maybe it is our fault for not aiming higher in testing, but I have never had 100% coverage for CI testing because I’ve never been in a situation before where it was really beneficial enough to justify the cost.
I am temporarily covering the gaps by extensively testing manually… maybe paying the price for me not having extensive CI coverage but it is hard for me to blame myself for this situation
Hey @clouless, how did you solve the issue with com.atlassian.fugue? I got the same issue with AttachmentManager as it consuming com.atlassian.fugue.Maybe in Confluence 8.8. Mind sharing your workaround? Thanks!
Hi @Leon ,
As mentioned somewhere before I have built my own compat-lib and included it as scope=test.
I stripped the implementations from inside the functions and stripped it down to simply be an empty skeleton of classes, just enough to satisfy the test/compile.
If it is just the fugue, you could more easily try this approach instead of building your own compat lib:
Create these files in src/test/java (TEST not MAIN!)
Here is the src as zip:
I hope this helps.
Cheers,
Bernhard
1 Like
Hi Scott,
Yes, we’re going to retain those User-based methods in Confluence 9.0, probably for the foreseeable future. Removing them is causing enough problems for our own plugins, never mind everyone else’s.
In hindsight, the forRemoval=true was a tad over-optimistic, so we may remove those, and leave them as vanilla @Deprecated.
As you know, sometimes things fall between the cracks, so thanks for letting us know.
1 Like
Hi,
Is anyone using the LocalNotificationService to send in-app notifications? As of 8.8.0 Atlassian has removed the class from the distribution, which means when I try to send a notification I get this error:
Caused by: java.lang.ClassNotFoundException: com.atlassian.mywork.service.LocalNotificationService
My code worked right up to and including 8.7.x, but now is broken.
I can’t add the dependency in the pom either with scope compile, as it is marked as a banned dependency
<dependency>
<groupId>com.atlassian.mywork</groupId>
<artifactId>mywork-api</artifactId>
<version>1.0.2</version>
<scope>provided</scope>
</dependency>
Does anyone know why Atlassian removed this class?
Is anyone else having this issue?
How do other vendors send in-app notifications?
This is blocking my release of 8.8.0 compatible marketplace version of my App!
This package is deprecated 
In versions 8.8 and 8.9 with dev mode enabled, the plugin will not compile when using classes from this package. You can disable it for these two versions, but ultimately in version 9.0+ they will not be available in any way.
List of deprecated packages - Include/exclude list for RFC-24 Data Center grey API removal - #5 by scott.dudley
How to turn off dev mode - Preparing for Confluence 9.0 - EAP coming soon - #82 by rr1
Cheers
Adam
Thanks Adam,
That list of depreciated API’s (from Scott) is different (more extensive) than what Atlassian has published… I did not know mywork was gray, and hence I’ve been wasting so much time.
Gray API’s should be able to be included as dependencies in my POM, HOWEVER the mywork dependency for scope compile has been marked as BANNED, so the documented workaround for gray API’s does not apply to mywork
Turning off dev mode at this stage just kicks the can down the road until I hit the same problem with 9.x, so vendors need an alternative for sending in-app notifications.
Does anyone have a workaround?
For reference, you can get around the banned dependency issue by telling the build tooling to exempt the artifact from the bans, as shown below in the POM. This won’t actually help with the mywork dependency, because you actually need to access the version of the package within Confluence. So, even though this type of change would fix the compile-time error, it still wouldn’t do what you want in this case. (It’s still useful if you need to use packages that aren’t part of the Confluence core though.)
I note in passing that there seems to be a REST API for the mywork package. I have no experience with it though.
<plugin>
<groupId>com.atlassian.maven.plugins</groupId>
<artifactId>confluence-maven-plugin</artifactId>
<!-- ... -->
<configuration>
<banningExcludes>
<exclude>com.google.code.gson:gson</exclude>
<exclude>commons-io:commons-io</exclude>
<!-- ... -->
</banningExcludes>
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.