I'd also prefer 2) Regards,
Jakob Korherr 2009/12/2 Leonardo Uribe <lu4...@gmail.com> > > > 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 >>> >> >
