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.
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.
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.
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.
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!
Thanks @ggautam, that sounds promising! I’ll be looking forward to the compatibility layer
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
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.
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.