I'm not sure number 2 would work, you should try it out. I know that
when I tried to do this for Trinidad, it complained that I was not
implementing the right version of the interfaces, even though the
methods were there. If this is the case then perhaps you should use a
Proxy Object. We did that in Trinidad to handle differences of several
objects and the interface isn't applied until runtime. Your
InvocationHandler can then call into the real methods as they are
called if you wish, but it's the most foolproof way I found of
implementing this.
If #2 works for you, though, then I say go for it. If it doesn't,
Proxy's aren't a bad alternative.
Scott
Jakob Korherr wrote:
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
|
