Skip to content

Conversation

@ThrawnCA
Copy link
Contributor

  • Extend org.apache.struts2.interceptor.MethodFilterInterceptor instead of com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.

- Extend org.apache.struts2.interceptor.MethodFilterInterceptor instead of com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.
@lukaszlenart
Copy link
Member

What's the purpose of this change? We keep "xwork" packages to support older apps and to avoid migration burden. If you want to use the new "struts2" packages it's better to migrate to Struts 7.x as Struts 6.x is maintenance mode and only some of the fixes are going to be ported into it.

@ThrawnCA
Copy link
Contributor Author

ThrawnCA commented Feb 1, 2026

What's the purpose of this change? We keep "xwork" packages to support older apps and to avoid migration burden.

Currently, if you extend TokenInterceptor, then you're still reliant on the xwork package (because you must accept an xwork ActionInvocation) and can't migrate. That is inconsistent with the behavior of AbstractInterceptor.

Moving to Struts 7 requires a full migration to EE9+, which means changing a whole lot of components at once. The aim here is to break it into smaller pieces.

@kusalk
Copy link
Member

kusalk commented Feb 2, 2026

Moving to Struts 7 requires a full migration to EE9+, which means changing a whole lot of components at once. The aim here is to break it into smaller pieces.

It shouldn't come at the cost of breaking existing applications which consume Struts 6.x. Fortunately, in this case, we can make the dependency on the xwork2 package optional whilst retaining backwards compatibility. See #1565 - feel free to test it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants