The only conflict between codebehind and convention is on the
UnknownHandler. If struts would support multiple UnknownHandler(s),
like it supports multiple PackageProvider(s), we wouldn't have a
problem at all, and they could be able to co-exist without knowing
anything about each other. Given a re
It is an interesting situation. I think its clear that majority of mind
share an momentum on the configuration side is with the Convention plugin.
REST is hot and so people are going to want to try an use the REST plugin
for action invocation. Ideally, we would want the best of both worlds in
With 2.1.2 beta out the door, I think it is time we consider the
branch feature-complete, which means our focus should now be on
working out the bugs so we can get a stable, GA-quality 2.1.x release
ASAP.
I'm going to start going through our tickets and push them around
accordingly. At this point
I agree it is important to present a solid convention and REST
solution, and am glad you agree backwards-compatibility is important.
For Struts developers, they probably don't care what happens, as long
as they can drop the right combination of jars into their application
and their application cont