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/
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 dispatch child on the filter element in web.xml. AFAIK, these advanced interception techniques are not available Paul On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty mgai...@hotmail.com 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 pbened...@apache.org 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 dispatch child on the filter element in web.xml. AFAIK, these advanced interception techniques are not available Paul On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty mgai...@hotmail.com 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
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 davelnew...@gmail.com Date: Mon, 13 Aug 2012 09:49:43 To: Struts Users Mailing Listuser@struts.apache.org Reply-To: Struts Users Mailing List user@struts.apache.org 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 pbened...@apache.org 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 dispatch child on the filter element in web.xml. AFAIK, these advanced interception techniques are not available Paul On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty mgai...@hotmail.com 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
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, umeshawas...@gmail.com 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 davelnew...@gmail.com Date: Mon, 13 Aug 2012 09:49:43 To: Struts Users Mailing Listuser@struts.apache.org Reply-To: Struts Users Mailing List user@struts.apache.org 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 pbened...@apache.org 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 dispatch child on the filter element in web.xml. AFAIK, these advanced interception techniques are not available Paul On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty mgai...@hotmail.com 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
Grabbed me a copy of Servlet Spec 2.4: quote 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. /quote 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: quote 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. /quote 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, umeshawas...@gmail.com 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 davelnew...@gmail.com Date: Mon, 13 Aug 2012 09:49:43 To: Struts Users Mailing Listuser@struts.apache.org Reply-To: Struts Users Mailing List user@struts.apache.org 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 pbened...@apache.org 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 dispatch child on the filter element in web.xml. AFAIK, these advanced interception techniques are not available Paul On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty mgai...@hotmail.com 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
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 rgie...@apache.org Date: Mon, 13 Aug 2012 20:00:04 To: Struts Users Mailing Listuser@struts.apache.org Reply-To: Struts Users Mailing List user@struts.apache.org Subject: Re: Benefits of using Filter as front controller Grabbed me a copy of Servlet Spec 2.4: quote 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. /quote 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: quote 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. /quote 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, umeshawas...@gmail.com 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 davelnew...@gmail.com Date: Mon, 13 Aug 2012 09:49:43 To: Struts Users Mailing Listuser@struts.apache.org Reply-To: Struts Users Mailing List user@struts.apache.org 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 pbened...@apache.org 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 dispatch child on the filter element in web.xml. AFAIK, these advanced interception techniques are not available Paul On Mon, Aug 13, 2012 at 8:14 AM, Martin Gainty mgai...@hotmail.com wrote: A good
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
[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
