struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
Subject RE: composable RequestProcessor
Date Wed, 04 Jun 2003 18:26:03 GMT
I don't see anything in the ActionServlet that couldn't be provided by some 
other class.

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:dgraham1980@hotmail.com]
>Sent: Wednesday, June 04, 2003 12:01 PM
>To: struts-dev@jakarta.apache.org
>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:dgraham1980@hotmail.com]
> >Sent: Wednesday, June 04, 2003 11:44 AM
> >To: struts-dev@jakarta.apache.org
> >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: struts-dev-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > >
> >
> >_________________________________________________________________
> >MSN 8 with e-mail virus protection service: 2 months FREE*
> >http://join.msn.com/?page=features/virus
> >
> >
> >---------------------------------------------------------------------
> >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
> >
>
>_________________________________________________________________
>Tired of spam? Get advanced junk mail protection with MSN 8.
>http://join.msn.com/?page=features/junkmail
>
>
>---------------------------------------------------------------------
>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
>

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message