[ANN] Struts 2.3.4.1 GA release available
The Apache Struts group is pleased to announce that Struts 2.3.4.1 is available as a "General Availability" release. The GA designation is our highest quality grade. Apache Struts 2 is an elegant, extensible framework for creating enterprise-ready Java web applications. The framework is designed to streamline the full development cycle, from building, to deploying, to maintaining applications over time. This release includes two important security fixes: * improved token mechanism, if used as CSRF attack prevention * restricted parameter name length to reduce DOS attack risks All developers are recommended to update existing Struts 2 applications to Struts 2.3.4.1. Struts 2.3.4.1 is available in a full distribution, or as separate library, source, example and documentation distributions, from the releases page. * http://struts.apache.org/download.cgi#struts2341 The release is also available through the central Maven repository under Group ID "org.apache.struts". The release notes are available online. * https://cwiki.apache.org/confluence/display/WW/Version%20Notes%202.3.4.1 The 2.3.x series of the Apache Struts framework has a minimum requirement of the following specification versions: Servlet API 2.4, JSP API 2.0, and Java 5. Should any issues arise with your use of any version of the Struts framework, please post your comments to the user list, and, if appropriate, file a tracking ticket.appropriate, file a tracking ticket: * https://issues.apache.org/struts/secure/Dashboard.jspa - The Apache Struts Team. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Problem with struts 2.3.4.1 & struts2-rest-showcase on Tomcat
Hello all, I'm having problems running the struts2-rest-showcase WAR that is packaged with Struts 2.3.4.1 (2.3.4 as well). Both Tomcat and Struts should be stock configurations. The other struts showcases seem to work fine. Should this showcase work on a stock Tomcat build for win64? I've tried on Tomcat 6 and 7, both on JDK 1.6.0_33 on Win7 64-bit. Here is the message I get on the default /orders request: There is no Action mapped for namespace / and action name orders. If anyone could point me in the right direction, I would be most grateful. Regards, Mike Request logs for http://localhost:8080/struts2-rest-showcase/orders WARNING: Could not find action or result There is no Action mapped for namespace / and action name orders. - [unknown location] at com.opensymphony.xwork2.DefaultActionProxy.prepare(DefaultActionProxy.java:185) at com.opensymphony.xwork2.DefaultActionProxyFactory.createActionProxy(DefaultActionProxyFactory.java:70) at org.apache.struts2.rest.RestActionProxyFactory.createActionProxy(RestActionProxyFactory.java:51) at org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:501) at org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction(ExecuteOperations.java:77) at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:91) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Thread.java:662) - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Benefits of using Filter as front controller
Rene Thanks for such a detailed explanation and descrbing each and every aspects Now even I can say and explains things in much more and good way Sent from BlackBerry® on Airtel -Original Message- From: Rene Gielen Date: Mon, 13 Aug 2012 20:00:04 To: Struts Users Mailing List Reply-To: "Struts Users Mailing List" Subject: Re: Benefits of using Filter as front controller Grabbed me a copy of Servlet Spec 2.4: SRV.6.1 What is a filter? A filter is a reusable piece of code that can transform the content of HTTP requests, responses, and header information. Filters do not generally create a response or respond to a request as servlets do, rather they modify or adapt the requests for a resource, and modify or adapt responses from a resource. "do not generally" is way different from "may not", right? Reading both the relevant parts of the spec and the API docs again, I cannot see any violation of the servlet specification by using a Filter for doing the dispatching, rather than a Servlet. The other part is how requests are mapped, which imposes the question if a servlet mapping matching the request URL must exist: SRV.11.1 Use of URL Paths [...] 1. The container will try to find an exact match of the path of the request to the path of the servlet. A successful match selects the servlet. 2. The container will recursively try to match the longest path-prefix. This is done by stepping down the path tree a directory at a time, using the ’/’ character as a path separator. The longest match determines the servlet selected. (ad 2.: Previous versions of this specification made use of these mapping tech- niques as a suggestion rather than a requirement, allowing servlet con- tainers to each have their different schemes for mapping client requests to servlets.) 3. If the last segment in the URL path contains an extension (e.g. .jsp), the servlet container will try to match a servlet that handles requests for the extension. An extension is defined as the part of the last segment after the last ’.’ character. 4. If neither of the previous three rules result in a servlet match, the container will attempt to serve content appropriate for the resource requested. If a "default" servlet is defined for the application, it will be used. Point 4 is crucial. As to my opinion, it doesn't state clearly if a default mapping must exist or not, which leaves it IMO up to the container. That said, most frameworks use dispatcher servlets, and WebWork / Struts 2 once did as well. The rationale behind switching to the Filter architecture was to deal better with integrating technologies such a Sitemesh or Portlet, which both profit from splitting the dispatching in more than one phase. This could only be accomplished by using filters rather than servlets. Since then, e.g. all major problems with sitemes integration magically disappeared. So my point of view is that there is nothing wrong with using filters for dispatching. If the container interprets the servlet spec in an opposite way, a dummy default servlet mapping should do the trick. Nevertheless I'm happy to hear about points I might have missed or misinterpreted. - René Am 8/13/12 16:01 , schrieb Paul Benedict: > I'll take back what I said and reserve opinion until further research. > I'll be interested in what you all find. For the record, the Spring > Framework has its front-controllers as servlets. > > http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/web/servlet/package-summary.html > > Paul > > On Mon, Aug 13, 2012 at 8:53 AM, wrote: >> Yes this was one of the point I was thinking >> Same question was today asked on SO and this lead me to reaseach as what >> advantages and reasons was there to use filter as controller >> Sent from BlackBerry® on Airtel >> >> -Original Message- >> From: Dave Newton >> Date: Mon, 13 Aug 2012 09:49:43 >> To: Struts Users Mailing List >> Reply-To: "Struts Users Mailing List" >> Subject: Re: Benefits of using Filter as front controller >> >> IIRC it states filters shouldn't be used to serve resources. I can't look >> it up at the moment, but will later today. >> >> Dave >> >> (pardon brevity, typos, and top-quoting; on cell) >> On Aug 13, 2012 9:44 AM, "Paul Benedict" wrote: >> >>> With all due respect, I think saying Struts 2 violates the Servlet >>> Spec is a grand stretch of the imagination. >>> >>> http://stackoverflow.com/questions/2957165/servlet-vs-filter >>> >>> Struts has a filter gives greater control over the kind of dispatching >>> needed. You can then intercept processing not just web requests, but >>> forwards, includes, and container errors. See the child on >>> the element in web.xml. AFAIK, these advanced interception >>> techniques are not available >>> >>> Paul >>> >>> On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty >>> wrote: A good question! The issue of "direct access of filters as resources" does appear to >>> break the 2.4 Servlet spec fo
Re: Benefits of using Filter as front controller
Grabbed me a copy of Servlet Spec 2.4: SRV.6.1 What is a filter? A filter is a reusable piece of code that can transform the content of HTTP requests, responses, and header information. Filters do not generally create a response or respond to a request as servlets do, rather they modify or adapt the requests for a resource, and modify or adapt responses from a resource. "do not generally" is way different from "may not", right? Reading both the relevant parts of the spec and the API docs again, I cannot see any violation of the servlet specification by using a Filter for doing the dispatching, rather than a Servlet. The other part is how requests are mapped, which imposes the question if a servlet mapping matching the request URL must exist: SRV.11.1 Use of URL Paths [...] 1. The container will try to find an exact match of the path of the request to the path of the servlet. A successful match selects the servlet. 2. The container will recursively try to match the longest path-prefix. This is done by stepping down the path tree a directory at a time, using the ’/’ character as a path separator. The longest match determines the servlet selected. (ad 2.: Previous versions of this specification made use of these mapping tech- niques as a suggestion rather than a requirement, allowing servlet con- tainers to each have their different schemes for mapping client requests to servlets.) 3. If the last segment in the URL path contains an extension (e.g. .jsp), the servlet container will try to match a servlet that handles requests for the extension. An extension is defined as the part of the last segment after the last ’.’ character. 4. If neither of the previous three rules result in a servlet match, the container will attempt to serve content appropriate for the resource requested. If a "default" servlet is defined for the application, it will be used. Point 4 is crucial. As to my opinion, it doesn't state clearly if a default mapping must exist or not, which leaves it IMO up to the container. That said, most frameworks use dispatcher servlets, and WebWork / Struts 2 once did as well. The rationale behind switching to the Filter architecture was to deal better with integrating technologies such a Sitemesh or Portlet, which both profit from splitting the dispatching in more than one phase. This could only be accomplished by using filters rather than servlets. Since then, e.g. all major problems with sitemes integration magically disappeared. So my point of view is that there is nothing wrong with using filters for dispatching. If the container interprets the servlet spec in an opposite way, a dummy default servlet mapping should do the trick. Nevertheless I'm happy to hear about points I might have missed or misinterpreted. - René Am 8/13/12 16:01 , schrieb Paul Benedict: > I'll take back what I said and reserve opinion until further research. > I'll be interested in what you all find. For the record, the Spring > Framework has its front-controllers as servlets. > > http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/web/servlet/package-summary.html > > Paul > > On Mon, Aug 13, 2012 at 8:53 AM, wrote: >> Yes this was one of the point I was thinking >> Same question was today asked on SO and this lead me to reaseach as what >> advantages and reasons was there to use filter as controller >> Sent from BlackBerry® on Airtel >> >> -Original Message- >> From: Dave Newton >> Date: Mon, 13 Aug 2012 09:49:43 >> To: Struts Users Mailing List >> Reply-To: "Struts Users Mailing List" >> Subject: Re: Benefits of using Filter as front controller >> >> IIRC it states filters shouldn't be used to serve resources. I can't look >> it up at the moment, but will later today. >> >> Dave >> >> (pardon brevity, typos, and top-quoting; on cell) >> On Aug 13, 2012 9:44 AM, "Paul Benedict" wrote: >> >>> With all due respect, I think saying Struts 2 violates the Servlet >>> Spec is a grand stretch of the imagination. >>> >>> http://stackoverflow.com/questions/2957165/servlet-vs-filter >>> >>> Struts has a filter gives greater control over the kind of dispatching >>> needed. You can then intercept processing not just web requests, but >>> forwards, includes, and container errors. See the child on >>> the element in web.xml. AFAIK, these advanced interception >>> techniques are not available >>> >>> Paul >>> >>> On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty >>> wrote: A good question! The issue of "direct access of filters as resources" does appear to >>> break the 2.4 Servlet spec for the reason that Struts needs access to all >>> (attributes) from the Request Another important issue is "who is doing the dispatching" under Strut2 Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehe
Re: Benefits of using Filter as front controller
I'll take back what I said and reserve opinion until further research. I'll be interested in what you all find. For the record, the Spring Framework has its front-controllers as servlets. http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/web/servlet/package-summary.html Paul On Mon, Aug 13, 2012 at 8:53 AM, wrote: > Yes this was one of the point I was thinking > Same question was today asked on SO and this lead me to reaseach as what > advantages and reasons was there to use filter as controller > Sent from BlackBerry® on Airtel > > -Original Message- > From: Dave Newton > Date: Mon, 13 Aug 2012 09:49:43 > To: Struts Users Mailing List > Reply-To: "Struts Users Mailing List" > Subject: Re: Benefits of using Filter as front controller > > IIRC it states filters shouldn't be used to serve resources. I can't look > it up at the moment, but will later today. > > Dave > > (pardon brevity, typos, and top-quoting; on cell) > On Aug 13, 2012 9:44 AM, "Paul Benedict" wrote: > >> With all due respect, I think saying Struts 2 violates the Servlet >> Spec is a grand stretch of the imagination. >> >> http://stackoverflow.com/questions/2957165/servlet-vs-filter >> >> Struts has a filter gives greater control over the kind of dispatching >> needed. You can then intercept processing not just web requests, but >> forwards, includes, and container errors. See the child on >> the element in web.xml. AFAIK, these advanced interception >> techniques are not available >> >> Paul >> >> On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty >> wrote: >> > >> > A good question! >> > The issue of "direct access of filters as resources" does appear to >> break the 2.4 Servlet spec for the reason that Struts needs access to all >> (attributes) >> > from the Request >> > >> > Another important issue is "who is doing the dispatching" under Strut2 >> > >> > Martin >> > __ >> > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité >> > >> > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene >> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte >> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht >> dient lediglich dem Austausch von Informationen und entfaltet keine >> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von >> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. >> > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas >> le destinataire prévu, nous te demandons avec bonté que pour satisfaire >> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie >> de ceci est interdite. Ce message sert à l'information seulement et n'aura >> pas n'importe quel effet légalement obligatoire. Étant donné que les email >> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter >> aucune responsabilité pour le contenu fourni. >> > >> > >> >> Date: Mon, 13 Aug 2012 11:30:05 +0530 >> >> Subject: Benefits of using Filter as front controller >> >> From: umeshawas...@gmail.com >> >> To: user@struts.apache.org >> >> >> >> Hi All, >> >> >> >> I was reading this thread >> >> >> http://struts.1045723.n5.nabble.com/Servlet-filter-as-front-controller-td3497275.html >> >> regarding the intentions of using Filter as front controller while it >> seems >> >> to violate even *Servlet specification*. >> >> >> >> Can any one throw light on this? >> >> >> >> -- >> >> With Regards >> >> Umesh Awasthi >> >> http://www.travellingrants.com/ >> > >> >> - >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> >> > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Benefits of using Filter as front controller
Yes this was one of the point I was thinking Same question was today asked on SO and this lead me to reaseach as what advantages and reasons was there to use filter as controller Sent from BlackBerry® on Airtel -Original Message- From: Dave Newton Date: Mon, 13 Aug 2012 09:49:43 To: Struts Users Mailing List Reply-To: "Struts Users Mailing List" Subject: Re: Benefits of using Filter as front controller IIRC it states filters shouldn't be used to serve resources. I can't look it up at the moment, but will later today. Dave (pardon brevity, typos, and top-quoting; on cell) On Aug 13, 2012 9:44 AM, "Paul Benedict" wrote: > With all due respect, I think saying Struts 2 violates the Servlet > Spec is a grand stretch of the imagination. > > http://stackoverflow.com/questions/2957165/servlet-vs-filter > > Struts has a filter gives greater control over the kind of dispatching > needed. You can then intercept processing not just web requests, but > forwards, includes, and container errors. See the child on > the element in web.xml. AFAIK, these advanced interception > techniques are not available > > Paul > > On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty > wrote: > > > > A good question! > > The issue of "direct access of filters as resources" does appear to > break the 2.4 Servlet spec for the reason that Struts needs access to all > (attributes) > > from the Request > > > > Another important issue is "who is doing the dispatching" under Strut2 > > > > Martin > > __ > > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité > > > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht > dient lediglich dem Austausch von Informationen und entfaltet keine > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas > le destinataire prévu, nous te demandons avec bonté que pour satisfaire > informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie > de ceci est interdite. Ce message sert à l'information seulement et n'aura > pas n'importe quel effet légalement obligatoire. Étant donné que les email > peuvent facilement être sujets à la manipulation, nous ne pouvons accepter > aucune responsabilité pour le contenu fourni. > > > > > >> Date: Mon, 13 Aug 2012 11:30:05 +0530 > >> Subject: Benefits of using Filter as front controller > >> From: umeshawas...@gmail.com > >> To: user@struts.apache.org > >> > >> Hi All, > >> > >> I was reading this thread > >> > http://struts.1045723.n5.nabble.com/Servlet-filter-as-front-controller-td3497275.html > >> regarding the intentions of using Filter as front controller while it > seems > >> to violate even *Servlet specification*. > >> > >> Can any one throw light on this? > >> > >> -- > >> With Regards > >> Umesh Awasthi > >> http://www.travellingrants.com/ > > > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > >
Re: Benefits of using Filter as front controller
IIRC it states filters shouldn't be used to serve resources. I can't look it up at the moment, but will later today. Dave (pardon brevity, typos, and top-quoting; on cell) On Aug 13, 2012 9:44 AM, "Paul Benedict" wrote: > With all due respect, I think saying Struts 2 violates the Servlet > Spec is a grand stretch of the imagination. > > http://stackoverflow.com/questions/2957165/servlet-vs-filter > > Struts has a filter gives greater control over the kind of dispatching > needed. You can then intercept processing not just web requests, but > forwards, includes, and container errors. See the child on > the element in web.xml. AFAIK, these advanced interception > techniques are not available > > Paul > > On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty > wrote: > > > > A good question! > > The issue of "direct access of filters as resources" does appear to > break the 2.4 Servlet spec for the reason that Struts needs access to all > (attributes) > > from the Request > > > > Another important issue is "who is doing the dispatching" under Strut2 > > > > Martin > > __ > > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité > > > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene > Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte > Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht > dient lediglich dem Austausch von Informationen und entfaltet keine > rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas > le destinataire prévu, nous te demandons avec bonté que pour satisfaire > informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie > de ceci est interdite. Ce message sert à l'information seulement et n'aura > pas n'importe quel effet légalement obligatoire. Étant donné que les email > peuvent facilement être sujets à la manipulation, nous ne pouvons accepter > aucune responsabilité pour le contenu fourni. > > > > > >> Date: Mon, 13 Aug 2012 11:30:05 +0530 > >> Subject: Benefits of using Filter as front controller > >> From: umeshawas...@gmail.com > >> To: user@struts.apache.org > >> > >> Hi All, > >> > >> I was reading this thread > >> > http://struts.1045723.n5.nabble.com/Servlet-filter-as-front-controller-td3497275.html > >> regarding the intentions of using Filter as front controller while it > seems > >> to violate even *Servlet specification*. > >> > >> Can any one throw light on this? > >> > >> -- > >> With Regards > >> Umesh Awasthi > >> http://www.travellingrants.com/ > > > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > >
Re: Benefits of using Filter as front controller
With all due respect, I think saying Struts 2 violates the Servlet Spec is a grand stretch of the imagination. http://stackoverflow.com/questions/2957165/servlet-vs-filter Struts has a filter gives greater control over the kind of dispatching needed. You can then intercept processing not just web requests, but forwards, includes, and container errors. See the child on the element in web.xml. AFAIK, these advanced interception techniques are not available Paul On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty wrote: > > A good question! > The issue of "direct access of filters as resources" does appear to break the > 2.4 Servlet spec for the reason that Struts needs access to all (attributes) > from the Request > > Another important issue is "who is doing the dispatching" under Strut2 > > Martin > __ > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger > sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung > oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich > dem Austausch von Informationen und entfaltet keine rechtliche > Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen > wir keine Haftung fuer den Inhalt uebernehmen. > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le > destinataire prévu, nous te demandons avec bonté que pour satisfaire informez > l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci > est interdite. Ce message sert à l'information seulement et n'aura pas > n'importe quel effet légalement obligatoire. Étant donné que les email > peuvent facilement être sujets à la manipulation, nous ne pouvons accepter > aucune responsabilité pour le contenu fourni. > > >> Date: Mon, 13 Aug 2012 11:30:05 +0530 >> Subject: Benefits of using Filter as front controller >> From: umeshawas...@gmail.com >> To: user@struts.apache.org >> >> Hi All, >> >> I was reading this thread >> http://struts.1045723.n5.nabble.com/Servlet-filter-as-front-controller-td3497275.html >> regarding the intentions of using Filter as front controller while it seems >> to violate even *Servlet specification*. >> >> Can any one throw light on this? >> >> -- >> With Regards >> Umesh Awasthi >> http://www.travellingrants.com/ > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: Benefits of using Filter as front controller
A good question! The issue of "direct access of filters as resources" does appear to break the 2.4 Servlet spec for the reason that Struts needs access to all (attributes) from the Request Another important issue is "who is doing the dispatching" under Strut2 Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Date: Mon, 13 Aug 2012 11:30:05 +0530 > Subject: Benefits of using Filter as front controller > From: umeshawas...@gmail.com > To: user@struts.apache.org > > Hi All, > > I was reading this thread > http://struts.1045723.n5.nabble.com/Servlet-filter-as-front-controller-td3497275.html > regarding the intentions of using Filter as front controller while it seems > to violate even *Servlet specification*. > > Can any one throw light on this? > > -- > With Regards > Umesh Awasthi > http://www.travellingrants.com/
