I think it also depends on the unknown mapping handler in Codebehind. The class takes care of determining the jsp to use when nothing is specified in the configurations.
<bean type="com.opensymphony.xwork2.UnknownHandler" class="org.apache.struts2.codebehind.CodebehindUnknownHandler" /> On Fri, May 16, 2008 at 1:50 PM, Musachy Barroso <[EMAIL PROTECTED]> wrote: > As far as I can see the only dependency between REST and Codebehind is > this class: > > > http://svn.apache.org/viewvc/struts/struts2/trunk/plugins/rest/src/main/java/org/apache/struts2/rest/ControllerClasspathPackageProvider.java?view=markup > > which all it does is use Codebehind to detect actions that end in > "Controller", and optionally disable package scanning. These 2 > settings could be constants declared in Codebehind and overwritten by > REST and the hard dependency would be gone(that's what I did with > Convention in order to plug REST in). > > I think the problem with REST is easy to fix; one blocker down. Now, > about supporting Codebehind from Convention, any other opinions > (before pulling a vote on it)? > > musachy > > On Fri, May 16, 2008 at 2:30 AM, Jeromy Evans > <[EMAIL PROTECTED]> wrote: > > Jeromy Evans wrote: > >> > >> I wouldn't rush into this decision. > >> > >> Users of the REST plugin require @Namespace, @Result, etc annotations. > >> Creating a duplicate set of annotations with the same purpose is not > >> sensible. > >> > >> It's appropriate that the REST plugin has a dependency on the plugin > that > >> auto-populates the Configuration, despite the contrary statement on the > >> plugins page. > >> Merging the REST plugin with Convention is also not possible as the > >> implementation of ActionInvocation and ActionMapper are entirely > different > >> (the conventions cannot currently be mixed). > >> > >> There are several issues here: > >> - creating a Configuration (via XML, via Annotation) > >> - ActionMapping (no problems here, each plugin sets up their own) > >> - ActionInvocation (standard or RESTful; they are incompatible) > >> - handling unknowns > >> > >> One situation could be that Configuration is separate from Convention; > so > >> the developer can choose how the Configuration is setup and then choose > >> which mapping & invocation, and unknown handling approach to use. > However > >> that would require another refactoring. > >> > >> I think making REST dependent on the Convention plugin is the way to go, > >> such that the Configuration is created by Convention (but customized for > >> REST *Controller class) and extended with the REST ActionMapper and > >> RestActionInvocation. > > > > On further thought, if it is possible to split up the Convention plugin, > > then it could be solved like so: > > - Zero Configuration: for all annotations relating to the setup of > > Configuration (merge from Convention) > > - CodeBehind: implements action mapping, invocation, unknown handling, > index > > handling (the other half of Convention) > > - REST alternative implementation of action mapping, invocation, unknown > > handling > > > > Ideally then REST can be used with ZeroConf or XMLConf, or CodeBehind > used > > with ZeroConf or XMLConf. Sweet. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > "Hey you! Would you help me to carry the stone?" Pink Floyd > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
