myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Korherr <jakob.korh...@gmail.com>
Subject Re: [MyFaces 2.0] how to handle _SystemEventServletRequest and _SystemEventServletResponse classes (attn:Werner)
Date Tue, 01 Dec 2009 23:03:28 GMT
I'd also prefer 2)

Regards,

Jakob Korherr

2009/12/2 Leonardo Uribe <lu4242@gmail.com>

>
>
> 2009/12/1 Matthias Wessendorf <mwessendorf@gmail.com>
>
>
>>
>> Sent from my iPod.
>>
>>
>> On 01.12.2009, at 22:48, Michael Concini <mconcini@gmail.com> 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
>>>
>>
>

Mime
View raw message