[ 
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development

Reply via email to