Make TokenInterceptor use the struts package instead of xwork

[ThrawnCA]

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

[lukaszlenart]

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]

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]

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.

[kusalk]

@ThrawnCA have you had a chance to test the linked alternative PR to see if it is suitable for your needs?

[ThrawnCA]

@ThrawnCA have you had a chance to test the linked alternative PR to see if it is suitable for your needs?

No, we have had other priorities. It does look like it should work, though.

[kusalk]

Going ahead and closing this PR in favour of #1565 then. We can't merge this breaking change into Struts 6.x regardless