myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Wessendorf <>
Subject Re: [MyFaces 2.0] how to handle _SystemEventServletRequest and _SystemEventServletResponse classes (attn:Werner)
Date Tue, 01 Dec 2009 22:07:44 GMT

Sent from my iPod.

On 01.12.2009, at 22:48, Michael Concini <> wrote:

> I need some help with the best way to handle updating the dummy  
> request/response objects that we use for system event listeners  
> kicked off when there isn't a request context.  Currently, we're  
> implementing ServletRequest and ServletResponse directly.  This is  
> broken when using a servlet 3.0 runtime though since we're not  
> implementing the new methods added by the servlet 3.0 spec.
> I tried already updating the classes to extend the request/response  
> wrapper classes, but that turned out to be problematic since the  
> constructor requires a request/response object to be passed.  Since  
> we don't have access to that as we're outside of a request I hit an  
> NPE try to use FacesContext that wasn't there.
> I've come up with a couple of potential solutions on this and would  
> like some input as to the best way to go.
> 1) We could also extend the wrapper classes, but add a no-arg  
> constructor to the dummy classes that would just call super(null).   
> This would be fine in most cases, but if an application tried to  
> call any of the new ServletContext methods from Servlet 3.0 we'd get  
> an NPE instead of a runtime exception (not ideal)
> 2) We can simply add the new methods from the Servlet 3.0 API to our  
> dummy classes.  I think as long as we don't include the @Override  
> annotation it should build and run in either a 2.5 or 3.0 environment.

I think I like that. We should test 2.5 env


> 3) We could implement a dynamic proxy to handle the calls.  Would be  
> a little more complex to implement, but might be the most elegant  
> solution.  Not fully sure if there are performance implications here  
> though.
> Personally, I'd lean towards (2), I'd like to here from Werner as  
> well since he was the one that initially implemented this.  Any  
> additional feedback from others in the community is of course welcome.
> Thanks,
> Mike

View raw message