I think, at the very least, we need to handle the null case better,
with a message that explains what property of what object/service is
null.
Further, it's looking like the current approach is a little
heavy-handed; perhaps the Request and Response objects should be
created earlier and stored int
Hi Richard,
Thanks a lot for your response! on your first point, I have tried this
with no luck... so your second observation may be more likely, although
the documentation just leaves me with more questions, i'm not convinced
that the state manager should ever turn up null, but it's not a bi
Hi Peter,
My guess is that for a RequestFilter, you need to ensure that your
filter is contributed after the default Tap5 filter that wires up the
HttpServletRequest object to the Tap5 Request object (which is what is
causing the NPE). However, I think on reading the RequestHandler
pipeline s
Hi,
Perhaps I haven't phrased this question quite right since I didn't get a
response... Let me try it again.
What I have is two contributions, a RequestFilter and a Dispatcher (the
code is just about identicle) both services have a dependancy on the
ApplicationStateManager, so I wire it by
Hi All,
I can get hold of the ApplicationStateManager using the Dispatcher
interface without a problem, however the same code fails using the
Tapestry RequestFilter interface? specifically
*if(asm_.exists(**UserAsoObject.class)**)) *returns a NPE. Would this be
a bug or shouldn't I be using
