You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2003/02/09 00:23:23 UTC
[Bugzilla #16603] Discussion Please
OK, I've assigned myself the following bugzilla ticket:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16603
and am trying to decide how to deal with it. I think I understand what
the reporter (cc'd above) is proposing. What's not clear is whether we
should make any change now, or perhaps ever. I'd like to discuss
that here before deciding.
Background:
----------
For a while now, we have supported the "forwardPattern" and "pagePattern"
properties on the ControllerConfig object. These patterns support
certain substitutions so that you can, for example, declare that you
want your JSP pages under /WEB-INF so that they can be accessible only
via RequestDispatcher.forward() calls.
Example scenario (assume a module prefix of "/mymodule"):
<global-forwards>
...
<forward name="Main Menu" path="/mainmenu.jsp"
contextRelative="false"/>
...
</global-forwards>
<controller ... forwardPattern="/WEB-INF/pages$M$P" .../>
If an Action returns the "Main Menu" ActionForward (nee ForwardConfig)
object, the request procesor will ultimately call
RequestUtils.forwardURL() to calculate the context-relative path
of "/WEB-INF/pages/mymodule/mainmenu.jsp". If no forward pattern had been
specified, the default mechanism would have returned
"/mymodule/mainmenu.jsp" instead.
So far, so good. Now we've got a way to "globally redirect" the URLs
within a module, without having to modify all of the individual paths in
our forward directives.
The problem pointed out by the Bugzilla ticket, though, is that we do not
respect forwardPattern universally; it is *only* used in the scenario
described above, plus in a couple of other special cases.
Other Potential Remapping Scenarios:
-----------------------------------
Scanning the code for the core Struts controller (I didn't check the Tiles
request processor, but suspect it might have similar issues), there are
several other scenarios where one might argue that the remapping through
the specified forwardPattern would make sense. The ones I found are as
follows, numbered for reference in later discussion:
(1) <action ... forward="/foo" .../>
Tells request processor to handle this request by performing
a RequestDispatcher.forward() to the specified "module-relative
path of the servlet or other resource that will process this
request", instead of invoking an Action. This path is not currently
processed by any specified "forwardPattern", instead a pattern
of "$M$P" is assumed.
(2) <action ... include="/foo" .../>
Tells request processor to handle this request by performing
a RequestDispatcher.include() to the specified "module-relative
path of the servlet or other resource that will process this
request", instead of invoking an Action. This path is not currently
processed by any specified "forwardPattern", instead a pattern
of "$M$P" is assumed.
(3) <action ... input="/foo" .../>
There are actually two subcases here, depending on the state of
the "inputForward" property of our module's ControllerConfig:
(3a) <controller ... inputForward="true" .../>
The value of the "input" property is treated as the name
of a local or global ForwardConfig, which is then processed
through the forwardPattern remapping just like an ActionForward
returned from an Action would be.
(3b) <controller ... inputForward="false" .../>
The value of the "input" property is treated as the
"module-relative path of the action or other resource
to which control should be returned if the form bean
returns validation errors. This path is not currently
processed by any specified "forwardPattern", instead a
pattern of "$M$P" is assumed.
Note that 3b is the default for backwards compatibility:
(4) <action ... path="/foo" .../>
This is the module-relative path that is used to match a
request to a particular action. It is not currently mapped through
any specified "forwardPattern", instead a pattern of "$M$P" is assumed.
(5) <exception ... path="/foo" .../>
This is the module-relative path of the resource that should
complete this request/response if an Action throws an exception
of the specified type. Whether remapping occurs or not is up to
the ExceptionHandler that is invoked; the default implementation
constructs an ActionForward based on this path (but sets the
contextRelative property, which looks like a bug but isn't related
to the issue at hand here), which will get processed through the
"forwardPattern" remapping if we fixed the contextRelative bug.
So, we currently do the remapping in case (3b), and ought to be doing it
in case (5). But what about the other scenarios?
Analysis:
--------
The underlying issue is that we have fallen into the (bad, but that's
hindsight for you) habit of using ActionForward instances to point at
(at least) three very different kinds of things:
(a) The view tier component that should actually render
the response (typically a JSP page)
(b) The next action to execute, if you are doing action
chaining
(c) The "application resource" that should handle a thrown
exception from an action (which could be a view tier
component, an arbitrary servlet, or an action)
The original intent of "forwardPattern" was to cover case (a) only,
because it was (in theory) only the view tier components that you'd want
to redirect for (i.e. to put JSP pages under /WEB-INF, or otherwise remap
the set of view components for a particular module). Case (b) seems like
it should NOT be mapped, for consistency with how case (4) is handled
(mapping the original request to the original action in the first place).
Case (c) should probably be remapped if it's a view component, but not if
it's an action.
But there is nothing about an ActionForward that lets you unambiguously
determine whether it points at a view component or not. :-(
Recommendation:
--------------
If we were not imminently trying to release a 1.1 final, I would be
tempted to design and work out a strategy for dealing with this ambiguity
problem, and hash out what the right behavior should be in each case.
However, at this point in time, I'm going to suggest that we resolve this
one as LATER and put it into the "1.2 Family" camp. We're going to need
to deal with it in a 1.2 time frame anyway, especially if we try to
implement any sort of "module configuration inheritance" mechanisms, which
are only going to make the problem worse.
In a 2.0 time frame, the lesson I draw from this is that we will want to
be very specific in defining how mapping of logical paths to physical
paths is performed, including a way to distinguish what kind of logical
path you're talking about (so that you can apply different rules for view
components and for action components, for example).
Does this sound like a plan that we (committers) can agree to?
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Bugzilla #16603] Discussion Please
Posted by Martin Cooper <ma...@apache.org>.
On Sat, 8 Feb 2003, Craig R. McClanahan wrote:
<big-snip/>
> Recommendation:
> --------------
>
> If we were not imminently trying to release a 1.1 final, I would be
> tempted to design and work out a strategy for dealing with this ambiguity
> problem, and hash out what the right behavior should be in each case.
> However, at this point in time, I'm going to suggest that we resolve this
> one as LATER and put it into the "1.2 Family" camp. We're going to need
> to deal with it in a 1.2 time frame anyway, especially if we try to
> implement any sort of "module configuration inheritance" mechanisms, which
> are only going to make the problem worse.
>
> In a 2.0 time frame, the lesson I draw from this is that we will want to
> be very specific in defining how mapping of logical paths to physical
> paths is performed, including a way to distinguish what kind of logical
> path you're talking about (so that you can apply different rules for view
> components and for action components, for example).
>
> Does this sound like a plan that we (committers) can agree to?
+1
I'm not particularly concerned about case (b), and don't believe we should
go out of our way to provide a nice solution for it. I realise that some
people will want to continue to use action chaining, so we will need to
allow for it in some shape or form. However, I have a scheme that allows
me to achieve the same effect without chaining actions, and I'm hoping to
be able to contribute that at some point.
--
Martin Cooper
>
> Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Bugzilla #16603] Discussion Please
Posted by Malik Recoing <m....@almerys.com>.
Sunday, February 09, 2003 12:55 AM , Craig R. McClanahan
<cr...@apache.org> a écrit :
> On Sat, 8 Feb 2003, Craig R. McClanahan wrote:
>
> > Date: Sat, 8 Feb 2003 15:23:23 -0800 (PST)
> > From: Craig R. McClanahan <cr...@apache.org>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>
> > To: struts-dev@jakarta.apache.org
> > Cc: malik.recoing@wanadoo.fr
> > Subject: [Bugzilla #16603] Discussion Please
> >
> > OK, I've assigned myself the following bugzilla ticket:
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16603
> >
> > and am trying to decide how to deal with it. I think I understand
> > what the reporter (cc'd above) is proposing. What's not clear is
> > whether we should make any change now, or perhaps ever. I'd like
> > to discuss that here before deciding.
> >
>
> As extra added enhancement to decide on this one quickly, please note
> that it is the last non-enhancement Bugzilla ticket we have open
> against 1.1. Woo hoo :-).
I'm sorry about that. It was not my goal delay the 1.1 ;-)
Malik.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Bugzilla #16603] Discussion Please
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 8 Feb 2003, Craig R. McClanahan wrote:
> Date: Sat, 8 Feb 2003 15:23:23 -0800 (PST)
> From: Craig R. McClanahan <cr...@apache.org>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Cc: malik.recoing@wanadoo.fr
> Subject: [Bugzilla #16603] Discussion Please
>
> OK, I've assigned myself the following bugzilla ticket:
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16603
>
> and am trying to decide how to deal with it. I think I understand what
> the reporter (cc'd above) is proposing. What's not clear is whether we
> should make any change now, or perhaps ever. I'd like to discuss
> that here before deciding.
>
As extra added enhancement to decide on this one quickly, please note that
it is the last non-enhancement Bugzilla ticket we have open against 1.1.
Woo hoo :-).
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Bugzilla #16603] Discussion Please
Posted by Ted Husted <hu...@apache.org>.
Craig R. McClanahan wrote:
> Recommendation:
> --------------
>
> If we were not imminently trying to release a 1.1 final, I would be
> tempted to design and work out a strategy for dealing with this ambiguity
> problem, and hash out what the right behavior should be in each case.
> However, at this point in time, I'm going to suggest that we resolve this
> one as LATER and put it into the "1.2 Family" camp. We're going to need
> to deal with it in a 1.2 time frame anyway, especially if we try to
> implement any sort of "module configuration inheritance" mechanisms, which
> are only going to make the problem worse.
>
> In a 2.0 time frame, the lesson I draw from this is that we will want to
> be very specific in defining how mapping of logical paths to physical
> paths is performed, including a way to distinguish what kind of logical
> path you're talking about (so that you can apply different rules for view
> components and for action components, for example).
>
> Does this sound like a plan that we (committers) can agree to?
+1
The ActionForward object does need to be extended, but this is not the
iteration to get started on that.
We might be able to resolve several issues, whether modules are being
used or not, if the ActionFoward could specify either an "action" or an
"page" property, following the current design of the link tag.
The key use case is forwarding to an action that "fronts" a page (it
needs to seed the request with certain objects before displaying the
page), the token I use for the ActionForward ("\something.do") is not
the same token I used for the ActionMapping path ("\something").
So my first suggestion, for a future iteration, would be to deprecate
"path" in favor of separate "page" and "action" properties, which would
be resolved in the same manner as the link tag.
As with most things, Struts has always contained the right pattern, we
just haven't applied to every case (yet) =:0)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: [Bugzilla #16603] Discussion Please
Posted by James Turner <tu...@blackbear.com>.
+1 to holding off until 1.2
James
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Bugzilla #16603] Discussion Please
Posted by Rob Leland <rl...@apache.org>.
Craig R. McClanahan wrote:
>However, at this point in time, I'm going to suggest that we resolve this
>one as LATER and put it into the "1.2 Family" camp.
>
+1, We have a good product and have uncovered some inconsistent behaviour.
The 1.2 relase time seems appropiate.
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org