Return-Path: Delivered-To: apmail-jakarta-struts-dev-archive@apache.org Received: (qmail 50277 invoked from network); 4 Jun 2003 17:44:00 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 4 Jun 2003 17:44:00 -0000 Received: (qmail 16447 invoked by uid 97); 4 Jun 2003 17:46:17 -0000 Delivered-To: qmlist-jakarta-archive-struts-dev@nagoya.betaversion.org Received: (qmail 16440 invoked from network); 4 Jun 2003 17:46:17 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 4 Jun 2003 17:46:17 -0000 Received: (qmail 49519 invoked by uid 500); 4 Jun 2003 17:43:49 -0000 Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list struts-dev@jakarta.apache.org Received: (qmail 49502 invoked from network); 4 Jun 2003 17:43:49 -0000 Received: from law15-f68.law15.hotmail.com (HELO hotmail.com) (64.4.23.68) by daedalus.apache.org with SMTP; 4 Jun 2003 17:43:49 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Jun 2003 10:43:53 -0700 Received: from 32.97.110.142 by lw15fd.law15.hotmail.msn.com with HTTP; Wed, 04 Jun 2003 17:43:53 GMT X-Originating-IP: [32.97.110.142] X-Originating-Email: [dgraham1980@hotmail.com] From: "David Graham" To: struts-dev@jakarta.apache.org Bcc: Subject: Re: composable RequestProcessor Date: Wed, 04 Jun 2003 11:43:53 -0600 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jun 2003 17:43:53.0848 (UTC) FILETIME=[DDB8F780:01C32AC0] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N >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 > > > >--------------------------------------------------------------------- >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