DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on GF v3 Final

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on GF v3 Final

Nikolaos Giannopoulos
As Nicholas pointed out in a comment on 29/Oct/2009 on this issue:
http://www.stripesframework.org/jira/browse/STS-678

"This is happening in GlassFish v3 as well"

I experienced this same issue just today on GlassFish v3 Final.  As this
is still unresolved and the last update states IBM is working on a patch
for WAS and the title includes "WAS 6.1" AND nobody wants to open
tickets that will be closed as duplicates:

Should I open a ticket specifically for GlassFish v3?

I also wonder if more than one app server is experiencing this issue
perhaps a cross container solution should be considered?

Thoughts?

--Nikolaos

------------------------------------------------------------------------------

_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development
Reply | Threaded
Open this post in threaded view
|

Re: DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on GF v3 Final

Ben Gunter
No, another ticket isn't necessary. It's the same problem on all of the affected containers. I didn't come up with a solution that I liked when I was looking at this a while back, and I haven't had time to look into it in a while.

On Mon, May 10, 2010 at 2:32 AM, Nikolaos Giannopoulos <[hidden email]> wrote:
As Nicholas pointed out in a comment on 29/Oct/2009 on this issue:
http://www.stripesframework.org/jira/browse/STS-678

"This is happening in GlassFish v3 as well"

I experienced this same issue just today on GlassFish v3 Final.  As this is still unresolved and the last update states IBM is working on a patch for WAS and the title includes "WAS 6.1" AND nobody wants to open tickets that will be closed as duplicates:

Should I open a ticket specifically for GlassFish v3?

I also wonder if more than one app server is experiencing this issue perhaps a cross container solution should be considered?

Thoughts?

--Nikolaos


------------------------------------------------------------------------------


_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development
Reply | Threaded
Open this post in threaded view
|

Re: DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on GF v3 Final

Nikolaos Giannopoulos
Ben,

I understand.  For the time being I have simply done what was suggested as not being optimal but is the only work around that I know of which is as follows:

    <filter-mapping>
        <filter-name>StripesFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
    </filter-mapping>
   
    <filter-mapping>
        <filter-name>DynamicMappingFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>FORWARD</dispatcher>
        <dispatcher>INCLUDE</dispatcher>
    </filter-mapping>

If I understand the issue correctly it appears that the an instance of the StripesFilter servlet needs to be initialized before the DynamicFilterMapping.  If that is the case then why doesn't the DynamicMappingFilter extend the StripesFilter vs. not extending it yet depending on it to be initialized before hand but crossing your fingers it gets initialized before hand and is available for use (I realize that it appears that the spec is OK with this and it is more than crossing your fingers but it still seems like a perhaps unnecessary leap of faith)?


I'll also reply to the ticket to point out that I too have experienced the issue on GlassFish v3 Final.  When I become more experienced with Stripes I'll look into trying to resolve this as well... .



Ben Gunter wrote:
No, another ticket isn't necessary. It's the same problem on all of the affected containers. I didn't come up with a solution that I liked when I was looking at this a while back, and I haven't had time to look into it in a while.

On Mon, May 10, 2010 at 2:32 AM, Nikolaos Giannopoulos <[hidden email]> wrote:
As Nicholas pointed out in a comment on 29/Oct/2009 on this issue:
http://www.stripesframework.org/jira/browse/STS-678

"This is happening in GlassFish v3 as well"

I experienced this same issue just today on GlassFish v3 Final.  As this is still unresolved and the last update states IBM is working on a patch for WAS and the title includes "WAS 6.1" AND nobody wants to open tickets that will be closed as duplicates:

Should I open a ticket specifically for GlassFish v3?

I also wonder if more than one app server is experiencing this issue perhaps a cross container solution should be considered?

Thoughts?

--Nikolaos



------------------------------------------------------------------------------


_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development
Reply | Threaded
Open this post in threaded view
|

Re: DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on GF v3 Final

Ben Gunter
Believe me, I have tried to extend StripesFilter for DMF. It doesn't work. And then a few months will pass, and I'll think to myself, "Self, why was it that I couldn't extend StripesFilter again?" And then I work on it for about twenty minutes or so before I run into the same brick wall. I've repeated that loop a few times already. It's difficult for me to remember exactly what the problem is, but I think I have a handle on it right now.

DMF works by passing the request through, buffering the response, and checking the status code. If the code is anything other than 404 it passes the response directly back to the client. This allows it to serve up static files (HTML, CSS, images, etc.) normally as well as dynamic content that is statically mapped.

Only when DMF spies a 404 response does it intervene. When it sees a 404, it asks the ActionResolver if any ActionBeans map to the requested URL. If not, then it returns the 404 to the client. However, if an ActionBean does map then it discards the 404 response and directly invokes StripesFilter and then DispatcherServlet to serve up the response.

So here's the problem with extending StripesFilter to do this. Take, for example, a JSP that needs StripesFilter. (This was not unusual in the early days of Stripes; see the Bugzooky example app in any released version.) The first thing DMF would do would be to execute the request normally ... which, for a JSP that needs StripesFilter, would result in a 500 response. How do you solve that problem? Map DMF to *.jsp? Nope, DMF is already mapped to /* so that wouldn't help anything. Similarly, if DispatcherServlet were statically mapped (e.g., to *.action or /action/*) then DMF would also pass through the request and get back a 500 response.

One solution would be to just execute all the StripesFilter goodness for every request, but that's a terrible solution. We wouldn't do that for the same reason we don't map StripesFilter to /*. That's a lot of stuff you don't want to execute for every single request. Another solution would be to define a configuration parameter to specify some mappings for which to revert to the current StripesFilter behavior, but that feels really dirty, which is why I chose not to do it that way. Not that that decision looks all that great now ...

Anyway, suggestions on how to solve the problem are welcome. I had a solution worked out, but I never checked it in because it, too, felt a little bit dirty. (Parsing web.xml and things of that nature.) I might just have to check that in and be done with it.

-Ben

On Mon, May 10, 2010 at 5:13 PM, Nikolaos Giannopoulos <[hidden email]> wrote:
Ben,

I understand.  For the time being I have simply done what was suggested as not being optimal but is the only work around that I know of which is as follows:

    <filter-mapping>
        <filter-name>StripesFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
    </filter-mapping>
   
    <filter-mapping>
        <filter-name>DynamicMappingFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>FORWARD</dispatcher>
        <dispatcher>INCLUDE</dispatcher>
    </filter-mapping>

If I understand the issue correctly it appears that the an instance of the StripesFilter servlet needs to be initialized before the DynamicFilterMapping.  If that is the case then why doesn't the DynamicMappingFilter extend the StripesFilter vs. not extending it yet depending on it to be initialized before hand but crossing your fingers it gets initialized before hand and is available for use (I realize that it appears that the spec is OK with this and it is more than crossing your fingers but it still seems like a perhaps unnecessary leap of faith)?


I'll also reply to the ticket to point out that I too have experienced the issue on GlassFish v3 Final.  When I become more experienced with Stripes I'll look into trying to resolve this as well... .



Ben Gunter wrote:
No, another ticket isn't necessary. It's the same problem on all of the affected containers. I didn't come up with a solution that I liked when I was looking at this a while back, and I haven't had time to look into it in a while.

On Mon, May 10, 2010 at 2:32 AM, Nikolaos Giannopoulos <[hidden email]> wrote:
As Nicholas pointed out in a comment on 29/Oct/2009 on this issue:
http://www.stripesframework.org/jira/browse/STS-678

"This is happening in GlassFish v3 as well"

I experienced this same issue just today on GlassFish v3 Final.  As this is still unresolved and the last update states IBM is working on a patch for WAS and the title includes "WAS 6.1" AND nobody wants to open tickets that will be closed as duplicates:

Should I open a ticket specifically for GlassFish v3?

I also wonder if more than one app server is experiencing this issue perhaps a cross container solution should be considered?

Thoughts?

--Nikolaos




------------------------------------------------------------------------------


_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development
Reply | Threaded
Open this post in threaded view
|

Re: DynamicMappingFilter fails with "Could not get a reference to StripesFilter" on GF v3 Final

Ben Gunter-2
I just wanted to follow up with a point I intended to make in my previous message but forgot. DMF does not buffer the entire response before deciding whether to pass it to the client. It buffers up to a certain amount (default 1024 bytes) and if that buffer overflows then DMF assumes it's a valid response and passes everything directly through. Just in case my description had you worried about that.

-Ben

On Mon, May 10, 2010 at 11:16 PM, Ben Gunter <[hidden email]> wrote:
Believe me, I have tried to extend StripesFilter for DMF. It doesn't work. And then a few months will pass, and I'll think to myself, "Self, why was it that I couldn't extend StripesFilter again?" And then I work on it for about twenty minutes or so before I run into the same brick wall. I've repeated that loop a few times already. It's difficult for me to remember exactly what the problem is, but I think I have a handle on it right now.

DMF works by passing the request through, buffering the response, and checking the status code. If the code is anything other than 404 it passes the response directly back to the client. This allows it to serve up static files (HTML, CSS, images, etc.) normally as well as dynamic content that is statically mapped.

Only when DMF spies a 404 response does it intervene. When it sees a 404, it asks the ActionResolver if any ActionBeans map to the requested URL. If not, then it returns the 404 to the client. However, if an ActionBean does map then it discards the 404 response and directly invokes StripesFilter and then DispatcherServlet to serve up the response.

So here's the problem with extending StripesFilter to do this. Take, for example, a JSP that needs StripesFilter. (This was not unusual in the early days of Stripes; see the Bugzooky example app in any released version.) The first thing DMF would do would be to execute the request normally ... which, for a JSP that needs StripesFilter, would result in a 500 response. How do you solve that problem? Map DMF to *.jsp? Nope, DMF is already mapped to /* so that wouldn't help anything. Similarly, if DispatcherServlet were statically mapped (e.g., to *.action or /action/*) then DMF would also pass through the request and get back a 500 response.

One solution would be to just execute all the StripesFilter goodness for every request, but that's a terrible solution. We wouldn't do that for the same reason we don't map StripesFilter to /*. That's a lot of stuff you don't want to execute for every single request. Another solution would be to define a configuration parameter to specify some mappings for which to revert to the current StripesFilter behavior, but that feels really dirty, which is why I chose not to do it that way. Not that that decision looks all that great now ...

Anyway, suggestions on how to solve the problem are welcome. I had a solution worked out, but I never checked it in because it, too, felt a little bit dirty. (Parsing web.xml and things of that nature.) I might just have to check that in and be done with it.

-Ben

On Mon, May 10, 2010 at 5:13 PM, Nikolaos Giannopoulos <[hidden email]> wrote:
Ben,

I understand.  For the time being I have simply done what was suggested as not being optimal but is the only work around that I know of which is as follows:

    <filter-mapping>
        <filter-name>StripesFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
    </filter-mapping>
   
    <filter-mapping>
        <filter-name>DynamicMappingFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>FORWARD</dispatcher>
        <dispatcher>INCLUDE</dispatcher>
    </filter-mapping>

If I understand the issue correctly it appears that the an instance of the StripesFilter servlet needs to be initialized before the DynamicFilterMapping.  If that is the case then why doesn't the DynamicMappingFilter extend the StripesFilter vs. not extending it yet depending on it to be initialized before hand but crossing your fingers it gets initialized before hand and is available for use (I realize that it appears that the spec is OK with this and it is more than crossing your fingers but it still seems like a perhaps unnecessary leap of faith)?


I'll also reply to the ticket to point out that I too have experienced the issue on GlassFish v3 Final.  When I become more experienced with Stripes I'll look into trying to resolve this as well... .



Ben Gunter wrote:
No, another ticket isn't necessary. It's the same problem on all of the affected containers. I didn't come up with a solution that I liked when I was looking at this a while back, and I haven't had time to look into it in a while.

On Mon, May 10, 2010 at 2:32 AM, Nikolaos Giannopoulos <[hidden email]> wrote:
As Nicholas pointed out in a comment on 29/Oct/2009 on this issue:
http://www.stripesframework.org/jira/browse/STS-678

"This is happening in GlassFish v3 as well"

I experienced this same issue just today on GlassFish v3 Final.  As this is still unresolved and the last update states IBM is working on a patch for WAS and the title includes "WAS 6.1" AND nobody wants to open tickets that will be closed as duplicates:

Should I open a ticket specifically for GlassFish v3?

I also wonder if more than one app server is experiencing this issue perhaps a cross container solution should be considered?

Thoughts?

--Nikolaos





------------------------------------------------------------------------------


_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development