|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
|
|
[JIRA] Created: (STS-678) DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on WAS 6.1DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on WAS 6.1
--------------------------------------------------------------------------------------- Key: STS-678 URL: http://www.stripesframework.org/jira/browse/STS-678 Project: Stripes Issue Type: Bug Components: ActionBean Dispatching Affects Versions: Release 1.5.1 Environment: WebSphere Application Server 6.1.0.0, JDK 1.5, Servlet 2.4 Reporter: Jan Novotný DynamicMappingFilter fails with message: Could not get a reference to StripesFilter from the servlet context. The dynamic mapping filter works in conjunction with StripesFilter and requires that it be defined in web.xml even though StripesFilter is defined in web.xml. Problem lies in following statement in JavaDoc documentation of the filter: * {@link StripesFilter} and {@link DispatcherServlet} need not be mapped to any URL patterns in * {@code web.xml} since this filter will determine at runtime whether or not they need to be * invoked. This is like I have had it: <filter> <display-name>Stripes Filter</display-name> <filter-name>StripesFilter</filter-name> <filter-class>net.sourceforge.stripes.controller.StripesFilter</filter-class> ... proper init params </filter> <filter> <filter-name>DynamicMappingFilter</filter-name> <filter-class>net.sourceforge.stripes.controller.DynamicMappingFilter</filter-class> </filter> <filter-mapping> <filter-name>DynamicMappingFilter</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>FORWARD</dispatcher> <dispatcher>INCLUDE</dispatcher> </filter-mapping> Which is correct according to documentation and works for example on Tomcat. Problem is that StripesFilter init method needs to be called - it writes a specific attribute into the ServletContext that is expected by DynamicMappingFilter (naturaly - because it means StripesFilter has been initialized). But this method is not called on WAS while having this configuration. I found out that WAS applies different lifecycle on the filters (I wonder whether it doesn't violate the Servlet specification?). It doesn't call init methods of filters and servlets on web application start, but delays it up to the time when Filters are really needed (means if there is request to the url the filter participates in). And when no filter-mapping for the StripesFilter is defined - it is never called although its definition is present in web.xml. Solution that works for me is simple - just adding filter mapping for Stripes filter: <filter-mapping> <filter-name>DynamicMappingFilter</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>FORWARD</dispatcher> <dispatcher>INCLUDE</dispatcher> </filter-mapping> <filter-mapping> <filter-name>StripesFilter</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> </filter-mapping> And StripesFilter is initialized at last. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://www.stripesframework.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Stripes-development mailing list Stripes-development@... https://lists.sourceforge.net/lists/listinfo/stripes-development |
|
|
[JIRA] Commented: (STS-678) DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on WAS 6.1[ http://www.stripesframework.org/jira/browse/STS-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11697#action_11697 ] Ben Gunter commented on STS-678: -------------------------------- From servlet spec 2.4: === SRV.6.2.1 Filter Lifecycle After deployment of the Web application, and before a request causes the container to access a Web resource, the container must locate the list of filters that must be applied to the Web resource as described below. The container must ensure that it has instantiated a filter of the appropriate class for each filter in the list, and called its init(FilterConfig config) method... === The behavior you describe seems to be legitimate based on that excerpt. I'll see what I can do about working with it. Mapping StripesFilter to /* is exactly what I was trying to avoid when I chose not to extend StripesFilter to create DynamicMappingFilter. StripesFilter isn't terribly heavyweight, but it's more than you want to do for every single request for an image, stylesheet, javascript file, etc. > DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on WAS 6.1 > --------------------------------------------------------------------------------------- > > Key: STS-678 > URL: http://www.stripesframework.org/jira/browse/STS-678 > Project: Stripes > Issue Type: Bug > Components: ActionBean Dispatching > Affects Versions: Release 1.5.1 > Environment: WebSphere Application Server 6.1.0.0, JDK 1.5, Servlet 2.4 > Reporter: Jan Novotný > > DynamicMappingFilter fails with message: > Could not get a reference to StripesFilter from the servlet context. The dynamic mapping filter works in conjunction with StripesFilter and requires that it be defined in web.xml > even though StripesFilter is defined in web.xml. > Problem lies in following statement in JavaDoc documentation of the filter: > * {@link StripesFilter} and {@link DispatcherServlet} need not be mapped to any URL patterns in > * {@code web.xml} since this filter will determine at runtime whether or not they need to be > * invoked. > This is like I have had it: > <filter> > <display-name>Stripes Filter</display-name> > <filter-name>StripesFilter</filter-name> > <filter-class>net.sourceforge.stripes.controller.StripesFilter</filter-class> > ... proper init params > </filter> > <filter> > <filter-name>DynamicMappingFilter</filter-name> > <filter-class>net.sourceforge.stripes.controller.DynamicMappingFilter</filter-class> > </filter> > <filter-mapping> > <filter-name>DynamicMappingFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > <dispatcher>FORWARD</dispatcher> > <dispatcher>INCLUDE</dispatcher> > </filter-mapping> > Which is correct according to documentation and works for example on Tomcat. > Problem is that StripesFilter init method needs to be called - it writes a specific attribute into the ServletContext that is expected by DynamicMappingFilter (naturaly - because it means StripesFilter has been initialized). But this method is not called on WAS while having this configuration. > I found out that WAS applies different lifecycle on the filters (I wonder whether it doesn't violate the Servlet specification?). It doesn't call init methods of filters and servlets on web application start, but delays it up to the time when Filters are really needed (means if there is request to the url the filter participates in). And when no filter-mapping for the StripesFilter is defined - it is never called although its definition is present in web.xml. > Solution that works for me is simple - just adding filter mapping for Stripes filter: > <filter-mapping> > <filter-name>DynamicMappingFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > <dispatcher>FORWARD</dispatcher> > <dispatcher>INCLUDE</dispatcher> > </filter-mapping> > <filter-mapping> > <filter-name>StripesFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > </filter-mapping> > And StripesFilter is initialized at last. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://www.stripesframework.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Stripes-development mailing list Stripes-development@... https://lists.sourceforge.net/lists/listinfo/stripes-development |
|
|
[JIRA] Updated: (STS-678) DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on WAS 6.1[ http://www.stripesframework.org/jira/browse/STS-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Gunter updated STS-678: --------------------------- Fix Version/s: Release 1.6 Release 1.5.2 > DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on WAS 6.1 > --------------------------------------------------------------------------------------- > > Key: STS-678 > URL: http://www.stripesframework.org/jira/browse/STS-678 > Project: Stripes > Issue Type: Bug > Components: ActionBean Dispatching > Affects Versions: Release 1.5.1 > Environment: WebSphere Application Server 6.1.0.0, JDK 1.5, Servlet 2.4 > Reporter: Jan Novotný > Assignee: Ben Gunter > Fix For: Release 1.5.2, Release 1.6 > > > DynamicMappingFilter fails with message: > Could not get a reference to StripesFilter from the servlet context. The dynamic mapping filter works in conjunction with StripesFilter and requires that it be defined in web.xml > even though StripesFilter is defined in web.xml. > Problem lies in following statement in JavaDoc documentation of the filter: > * {@link StripesFilter} and {@link DispatcherServlet} need not be mapped to any URL patterns in > * {@code web.xml} since this filter will determine at runtime whether or not they need to be > * invoked. > This is like I have had it: > <filter> > <display-name>Stripes Filter</display-name> > <filter-name>StripesFilter</filter-name> > <filter-class>net.sourceforge.stripes.controller.StripesFilter</filter-class> > ... proper init params > </filter> > <filter> > <filter-name>DynamicMappingFilter</filter-name> > <filter-class>net.sourceforge.stripes.controller.DynamicMappingFilter</filter-class> > </filter> > <filter-mapping> > <filter-name>DynamicMappingFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > <dispatcher>FORWARD</dispatcher> > <dispatcher>INCLUDE</dispatcher> > </filter-mapping> > Which is correct according to documentation and works for example on Tomcat. > Problem is that StripesFilter init method needs to be called - it writes a specific attribute into the ServletContext that is expected by DynamicMappingFilter (naturaly - because it means StripesFilter has been initialized). But this method is not called on WAS while having this configuration. > I found out that WAS applies different lifecycle on the filters (I wonder whether it doesn't violate the Servlet specification?). It doesn't call init methods of filters and servlets on web application start, but delays it up to the time when Filters are really needed (means if there is request to the url the filter participates in). And when no filter-mapping for the StripesFilter is defined - it is never called although its definition is present in web.xml. > Solution that works for me is simple - just adding filter mapping for Stripes filter: > <filter-mapping> > <filter-name>DynamicMappingFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > <dispatcher>FORWARD</dispatcher> > <dispatcher>INCLUDE</dispatcher> > </filter-mapping> > <filter-mapping> > <filter-name>StripesFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > </filter-mapping> > And StripesFilter is initialized at last. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://www.stripesframework.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Stripes-development mailing list Stripes-development@... https://lists.sourceforge.net/lists/listinfo/stripes-development |
|
|
[JIRA] Commented: (STS-678) DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on WAS 6.1[ http://www.stripesframework.org/jira/browse/STS-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11840#action_11840 ] Nicholas Stuart commented on STS-678: ------------------------------------- This is happening in Glassfish v3 as well. V2 was working fine with out having a mapping value for StripesFilter. > DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on WAS 6.1 > --------------------------------------------------------------------------------------- > > Key: STS-678 > URL: http://www.stripesframework.org/jira/browse/STS-678 > Project: Stripes > Issue Type: Bug > Components: ActionBean Dispatching > Affects Versions: Release 1.5.1 > Environment: WebSphere Application Server 6.1.0.0, JDK 1.5, Servlet 2.4 > Reporter: Jan Novotný > Assignee: Ben Gunter > Fix For: Release 1.5.3 > > > DynamicMappingFilter fails with message: > Could not get a reference to StripesFilter from the servlet context. The dynamic mapping filter works in conjunction with StripesFilter and requires that it be defined in web.xml > even though StripesFilter is defined in web.xml. > Problem lies in following statement in JavaDoc documentation of the filter: > * {@link StripesFilter} and {@link DispatcherServlet} need not be mapped to any URL patterns in > * {@code web.xml} since this filter will determine at runtime whether or not they need to be > * invoked. > This is like I have had it: > <filter> > <display-name>Stripes Filter</display-name> > <filter-name>StripesFilter</filter-name> > <filter-class>net.sourceforge.stripes.controller.StripesFilter</filter-class> > ... proper init params > </filter> > <filter> > <filter-name>DynamicMappingFilter</filter-name> > <filter-class>net.sourceforge.stripes.controller.DynamicMappingFilter</filter-class> > </filter> > <filter-mapping> > <filter-name>DynamicMappingFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > <dispatcher>FORWARD</dispatcher> > <dispatcher>INCLUDE</dispatcher> > </filter-mapping> > Which is correct according to documentation and works for example on Tomcat. > Problem is that StripesFilter init method needs to be called - it writes a specific attribute into the ServletContext that is expected by DynamicMappingFilter (naturaly - because it means StripesFilter has been initialized). But this method is not called on WAS while having this configuration. > I found out that WAS applies different lifecycle on the filters (I wonder whether it doesn't violate the Servlet specification?). It doesn't call init methods of filters and servlets on web application start, but delays it up to the time when Filters are really needed (means if there is request to the url the filter participates in). And when no filter-mapping for the StripesFilter is defined - it is never called although its definition is present in web.xml. > Solution that works for me is simple - just adding filter mapping for Stripes filter: > <filter-mapping> > <filter-name>DynamicMappingFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > <dispatcher>FORWARD</dispatcher> > <dispatcher>INCLUDE</dispatcher> > </filter-mapping> > <filter-mapping> > <filter-name>StripesFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > </filter-mapping> > And StripesFilter is initialized at last. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://www.stripesframework.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Stripes-development mailing list Stripes-development@... https://lists.sourceforge.net/lists/listinfo/stripes-development |
|
|
[JIRA] Commented: (STS-678) DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on WAS 6.1[ http://www.stripesframework.org/jira/browse/STS-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11875#action_11875 ] david wade commented on STS-678: -------------------------------- It appears that WebSphere does indeed break the servlet spec but not as thought above. It may be relevant here so I will share. The servlet spec states there will be only one instance of a particular named Filter, but we found if requests are already being received by WebSphere _before/during_ the start of of a web application, WebSphere (6.1 FP13 thru FP27) will create multiple instances of the same named filter and initialize each one. However, come application shutdown, only the last instance has the destroy method invoked (because it loses the rest when the filters are put into presumably some map indexed by the filter name). So, delaying Filter creation/initialization until the first request, while not against the servlet spec, is a bad idea because they really need to add synchronization code around the code responsible. Clearly they have not as multiple instances are created. To reproduce, create a very simple web app with a Filter and one JSP. Put a constructor on the Filter that simply increments a static instance counter and outputs that instance number to stdout. Deploy, then stop the web app. Start up multiple clients requesting the JSP, then start the web app. When started, stop the clients and have a look at the SystemOut.log. Both machine the client is running on and the server need to be SMP machines to reliably demonstrate this issue. Am happy to supply an example web app + source if nobody believes me that WebSphere could be so blatantly dumb. IBM currently in denial mode on this issue. > DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on WAS 6.1 > --------------------------------------------------------------------------------------- > > Key: STS-678 > URL: http://www.stripesframework.org/jira/browse/STS-678 > Project: Stripes > Issue Type: Bug > Components: ActionBean Dispatching > Affects Versions: Release 1.5.1 > Environment: WebSphere Application Server 6.1.0.0, JDK 1.5, Servlet 2.4 > Reporter: Jan Novotný > Assignee: Ben Gunter > Fix For: Release 1.5.3 > > > DynamicMappingFilter fails with message: > Could not get a reference to StripesFilter from the servlet context. The dynamic mapping filter works in conjunction with StripesFilter and requires that it be defined in web.xml > even though StripesFilter is defined in web.xml. > Problem lies in following statement in JavaDoc documentation of the filter: > * {@link StripesFilter} and {@link DispatcherServlet} need not be mapped to any URL patterns in > * {@code web.xml} since this filter will determine at runtime whether or not they need to be > * invoked. > This is like I have had it: > <filter> > <display-name>Stripes Filter</display-name> > <filter-name>StripesFilter</filter-name> > <filter-class>net.sourceforge.stripes.controller.StripesFilter</filter-class> > ... proper init params > </filter> > <filter> > <filter-name>DynamicMappingFilter</filter-name> > <filter-class>net.sourceforge.stripes.controller.DynamicMappingFilter</filter-class> > </filter> > <filter-mapping> > <filter-name>DynamicMappingFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > <dispatcher>FORWARD</dispatcher> > <dispatcher>INCLUDE</dispatcher> > </filter-mapping> > Which is correct according to documentation and works for example on Tomcat. > Problem is that StripesFilter init method needs to be called - it writes a specific attribute into the ServletContext that is expected by DynamicMappingFilter (naturaly - because it means StripesFilter has been initialized). But this method is not called on WAS while having this configuration. > I found out that WAS applies different lifecycle on the filters (I wonder whether it doesn't violate the Servlet specification?). It doesn't call init methods of filters and servlets on web application start, but delays it up to the time when Filters are really needed (means if there is request to the url the filter participates in). And when no filter-mapping for the StripesFilter is defined - it is never called although its definition is present in web.xml. > Solution that works for me is simple - just adding filter mapping for Stripes filter: > <filter-mapping> > <filter-name>DynamicMappingFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > <dispatcher>FORWARD</dispatcher> > <dispatcher>INCLUDE</dispatcher> > </filter-mapping> > <filter-mapping> > <filter-name>StripesFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > </filter-mapping> > And StripesFilter is initialized at last. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://www.stripesframework.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-development mailing list Stripes-development@... https://lists.sourceforge.net/lists/listinfo/stripes-development |
|
|
[JIRA] Commented: (STS-678) DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on WAS 6.1[ http://www.stripesframework.org/jira/browse/STS-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11876#action_11876 ] david wade commented on STS-678: -------------------------------- IBM have agreed WebSphere is breaking the servlet spec and is working on patch for the multiple Filter instances issue. Will post an update once the fix is released. > DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on WAS 6.1 > --------------------------------------------------------------------------------------- > > Key: STS-678 > URL: http://www.stripesframework.org/jira/browse/STS-678 > Project: Stripes > Issue Type: Bug > Components: ActionBean Dispatching > Affects Versions: Release 1.5.1 > Environment: WebSphere Application Server 6.1.0.0, JDK 1.5, Servlet 2.4 > Reporter: Jan Novotný > Assignee: Ben Gunter > Fix For: Release 1.5.3 > > > DynamicMappingFilter fails with message: > Could not get a reference to StripesFilter from the servlet context. The dynamic mapping filter works in conjunction with StripesFilter and requires that it be defined in web.xml > even though StripesFilter is defined in web.xml. > Problem lies in following statement in JavaDoc documentation of the filter: > * {@link StripesFilter} and {@link DispatcherServlet} need not be mapped to any URL patterns in > * {@code web.xml} since this filter will determine at runtime whether or not they need to be > * invoked. > This is like I have had it: > <filter> > <display-name>Stripes Filter</display-name> > <filter-name>StripesFilter</filter-name> > <filter-class>net.sourceforge.stripes.controller.StripesFilter</filter-class> > ... proper init params > </filter> > <filter> > <filter-name>DynamicMappingFilter</filter-name> > <filter-class>net.sourceforge.stripes.controller.DynamicMappingFilter</filter-class> > </filter> > <filter-mapping> > <filter-name>DynamicMappingFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > <dispatcher>FORWARD</dispatcher> > <dispatcher>INCLUDE</dispatcher> > </filter-mapping> > Which is correct according to documentation and works for example on Tomcat. > Problem is that StripesFilter init method needs to be called - it writes a specific attribute into the ServletContext that is expected by DynamicMappingFilter (naturaly - because it means StripesFilter has been initialized). But this method is not called on WAS while having this configuration. > I found out that WAS applies different lifecycle on the filters (I wonder whether it doesn't violate the Servlet specification?). It doesn't call init methods of filters and servlets on web application start, but delays it up to the time when Filters are really needed (means if there is request to the url the filter participates in). And when no filter-mapping for the StripesFilter is defined - it is never called although its definition is present in web.xml. > Solution that works for me is simple - just adding filter mapping for Stripes filter: > <filter-mapping> > <filter-name>DynamicMappingFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > <dispatcher>FORWARD</dispatcher> > <dispatcher>INCLUDE</dispatcher> > </filter-mapping> > <filter-mapping> > <filter-name>StripesFilter</filter-name> > <url-pattern>/*</url-pattern> > <dispatcher>REQUEST</dispatcher> > </filter-mapping> > And StripesFilter is initialized at last. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://www.stripesframework.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Stripes-development mailing list Stripes-development@... https://lists.sourceforge.net/lists/listinfo/stripes-development |
| Free embeddable forum powered by Nabble | Forum Help |