2009/12/1 Matthias Wessendorf <mwessend...@gmail.com>

>
>
> Sent from my iPod.
>
>
> On 01.12.2009, at 22:48, Michael Concini <mconc...@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
>>
>

Reply via email to