myfaces-dev mailing list archives

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

> 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
> -Matthias
I like number 2 too, because it keeps things simple.

Leonardo Uribe

>  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