David
In the past the argument for creating redundant services from within Struts was that it allowed for easier and condensed configuration management of Struts stuff from non-struts stuff. For example, we have the plugin (lifecylce) config which is essentially the same as using a servlet for initialization. But, it is cleaner to manage these thing from within the Struts lifecycle.
I guess this situation is different in the sense that the filters may be
working where the ActionServlet used to (pre RP). So, it's like coming full
circle, except now the RP has fully replaced the ActionServlet as a chain of
filters and we lose the <controller> tag in the struts-config.
Yet, if we are talking about ditching the ActionServlet then we will have to
pass a reference of some sort to the Action classes. Currently they have an
ActionServlet reference in order to access the container methods. So, it
still might be a good thing to retain it. Don't you think?
Brandon Goodin
-----Original Message----- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 12:01 PM To: [EMAIL PROTECTED] Subject: RE: composable RequestProcessor
>If we use Filters in lieu of the RP wouldn't that require that we move the
>ActionServlet to a filter as well? Where does the ActionServlet fit in to
>this?
The ActionServlet initializes Struts from the config files but all
processing goes through the RP. So, we could still have the servlet init.
everything if we wanted but then step aside and let the filters process
requests. Alternatively, we could remove the ActionServlet and init. Struts
some other way.
David
>
>Brandon Goodin
>
>-----Original Message-----
>From: David Graham [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, June 04, 2003 11:44 AM
>To: [EMAIL PROTECTED]
>Subject: Re: composable RequestProcessor
>
>
>
> >David Graham wrote:
> >>Why should we duplicate the effort of the container inside Struts?
> >
> >We often duplicate the effort of the container. Actions duplicate
>servlets.
> >Modules duplicate multiple applications.
> >
> >In each of these cases, the effect of the container feature is the same,
> >but the justification has always been "it more lightweight".
>
>In this case it's more heavyweight. We would have to alter the DTD,
>transform the new DTD elements to objects, code up the chaining mechanism,
>write unit tests, and deal with the bugs.
>
>Adding a RequestHandler interface is *much* simpler and acheives the
>desired
>results (if not in the xml configuration manner some would prefer). It
>doesn't make sense to me, to disregard all the work that containers have
>put
>into Filters and write our own.
>
>Even after implementing our own approach we would have to spend time
>supporting and modifying it. This especially seems like a waste of time
>given there's already a standard solution out there.
>
>This reminds me of modules where they sounded like a great idea and then
>there's nobody to support the bugs.
>
>David
>
> >
> >*If someone wanted to write it*, I don't see that a composable request
> >processor would have to be a 2.x change. The major changes could all take
> >place within the process method, and the original RequestProcessor could
> >remain available.
> >
> >Things like the DTD may have to be expanded, but it would not be anything
> >more radical than what we did between 1.0 and 1.1. [As if that's a good
> >justification for anything =:0)]
> >
> >-Ted.
> >
> >
> >--
> >Ted Husted,
> >Struts in Action <http://husted.com/struts/book.html>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE*
>http://join.msn.com/?page=features/virus
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
_________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
