PSA - Confluence moves to Struts in 8.0 - EAP

Confluence Development Confluence Data Center Announcements
, , , , , ,
#1

Hello everyone,

We are excited to announce that our team is working on moving to Struts 2 from Webwork/XWork in Confluence 8.0.

Let’s first look at a brief history, Webwork2 is an unmaintained library with fairly no public release in more than a decade(last released 2007) and hence we are vulnerable to new exploits and also have to maintain it ourselves. However, on the contrary Struts2 basically, a fork of Webwork2 and an extension get far more active contribution and active security releases. Hence, we are making the move to Struts2.

We have drafted a page to maintain all the updates to the Struts work in 8.0: Struts 2 upgrade. For EAP, 8.0.0-struts-m020 has been released as an 8.0 milestone with Struts.

For full 8.0 EAP updates, please watch Preparing for Confluence 8.0

Note: We will release Struts EAPs as well as regular 8.0 EAPs until Struts work is merged with 8.0.

Thanks,
Ganesh
Senior Engineer, Confluence DC

1 Like
#2

Hi @ggautam

in version 8.0.0-struts-m20 on every administration page I get errors like in a file error.txt (137.6 KB)


ATLAS Version:    8.2.7
ATLAS Home:       /Applications/Atlassian/atlassian-plugin-sdk
ATLAS Scripts:    /Applications/Atlassian/atlassian-plugin-sdk/bin
ATLAS Maven Home: /Applications/Atlassian/atlassian-plugin-sdk/apache-maven-3.8.6
AMPS Version:     8.1.2
--------
Executing: /Applications/Atlassian/atlassian-plugin-sdk/apache-maven-3.8.6/bin/mvn --version -gs /Applications/Atlassian/atlassian-plugin-sdk/apache-maven-3.8.6/conf/settings.xml
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /Applications/Atlassian/atlassian-plugin-sdk/apache-maven-3.8.6
Java version: 11.0.15, vendor: Azul Systems, Inc., runtime: /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home
Default locale: en_PL, platform encoding: UTF-8
OS name: "mac os x", version: "12.5", arch: "aarch64", family: "mac"

pom.xml

...
            <plugin>
                <groupId>com.atlassian.maven.plugins</groupId>
                <artifactId>confluence-maven-plugin</artifactId>
                <version>${amps.version}</version>
                <extensions>true</extensions>
                <configuration>
                    <productVersion>${confluence.version}</productVersion>
                    <productDataVersion>${confluence.data.version}</productDataVersion>
                    <jvmArgs>-Xms2048m -Xmx6072m -Duser.language=en -Duser.country=US -Dconfluence.browser.language.enabled=false</jvmArgs>
                    <enableQuickReload>true</enableQuickReload>
                    <instructions>
                        <Spring-Context>*</Spring-Context>
                    </instructions>
                </configuration>
            </plugin>
...
<amps.version>8.6.0</amps.version>

Cheers
Adam

1 Like
#3

Hi @adam.labus,

Thanks for reporting it. Its a known issue: [CONFSERVER-79610] Fix Classcast (class java.math.BigInteger cannot be cast to class java.lang.String) - PluginResourceDownload.serveFile - Create and track feature requests for Atlassian products.. We plan to work on it in next sprints. I would recommend you to watch this issue for further updates.

Thanks,
Ganesh

2 Likes
#4

Hi @ggautam, thanks a lot for the heads-up, but this is a bit out of the blue tbh.

Will there be a compatibility library for this? Several of our apps use classes from the packages mentioned in the upgrade guide (especially ServletActionContext which is used in task threads to re-establish context used by other 3rd party apps etc.).

Of course I understand the need for updating libraries and frameworks in major versions, but given that these classes were never marked deprecated (obviously, because they aren’t from Atlassian) I suspect that more vendors are using them in their apps.

It would be nice if this could be upgraded in a backwards compatible way (for example using a shim library delegating to the new classes), because otherwise you put a lot of effort on each vendor who still needs to support Confluence 7 - which is likely each of us. The effort we’d be facing would be either in re-implementing a compatibility lib, using reflection hacks, or in the worst case the need to maintain two code branches for Confluence 7 & 8.

Looking forward to your response.
Jens

6 Likes
#5

+1 on a backwards-compat solution for migration.

IMO, forking plugin source code to support 7.x and 8.x is not a fair requirement to put on partners.

Please reconsider the migration plan and see if it would be possible to provide a compat-lib that we can use for a backwards compatible code refactor.

Thanks!

2 Likes
#6

Hi @jens / @turehoefner_appfire,
Thanks for providing the valuable feedback. We are committed to minimise vendor friction.

We have raised CONFSERVER-79630 to provide a layer in confluence-compat-lib to cover >90% plugin cases for compatibility.
We would provide an update in this forum and Jira once we have a working version of the compat library.

Meanwhile, we would still recommend plugin devs to evaluate their plugin with changed class on 8.0.0-struts-m020 just to see the scale of issues(if any) with the upgrade.
Please reach out here if you face any issues with this upgrade.

Thanks,
Ganesh

2 Likes
#7

This is great @ggautam, thank you for responding to vendor feedback.

We only have a couple of simple Webwork actions in our app so this change likely won’t impact us, but there are many apps on marketplace that I’m sure would have felt a lot of compatibility pain.

1 Like
#8

That is fantastic news @ggautam !!!

I think a 90% target for the compat lib functionality coverage is a good target. The last 10% is probably impractical and super difficult to implement and we wouldn’t want to slow the 90% solution with that last little piece.

Thank you, I had a nightmare last night related to forking our code… stuff like this keeps me awake. I will sleep better now!

1 Like
#9

Thanks @ggautam, that sounds promising! I’ll be looking forward to the compatibility layer :slight_smile:

Given that we’ll need to support Confluence 7 I don’t currently see a way to test compatibility until the compatibility layer is available, though. At least not without migrating to struts classes, but then the apps won’t run on Confluence 7 anymore, which defeats the purpose of this whole discussion :wink:

Btw:
Did you consider bundling the compatibility classes directly with Confluence rather than in confluence-compat-lib? That way they could follow the regular Confluence deprecation cycle AND 3rd party apps wouldn’t need to pull in confluence-compat-lib as a bundled dependency.

Cheers,
Jens

#10

Hi @jens,

Thanks for the suggestion. We did look at bundling compat layer, but the whole idea is to bring balance between tech-debt and modernisation. Unfortunately, exposing old Xwork/Webwork based packages delegating to new classes would be not just problematic with IP things(which can be worked with), but also long-term maintenance required for that layer. However, with compat-lib, we get the liberty to make breaking changes with lesser friction and impact.

Cheers,
Ganesh

1 Like