On Tue, 2011-09-13 at 09:51 -0700, Rajiv Mordani wrote:
> So you are suggesting to move the InputSource and OutputSink methods to
> ServletInputStream and ServletOutputStream respectively? How would one
> distinguish between
> the traditional IO vs the non blocking API? I was trying to keep the two
> separate. One other thought
> was to have an overridden method for getInputStream that takes a boolean
> which says blocking
> or non-blocking. Keeping the two separate just seemed simpler at this time.
I have a magic trick in my API where it is blocking unless the blocking
flags (like NIOInputSource.isReady() for example) are called, which I
use as a strong hint that the application does not want blocking.
> > + Can you explain more about the life cycle of the listeners? Are
> > these intended to work only with Async requests, or will they work for
> > any request? eg if I call response.addListener(myWriteListener),
> > could it be called back immediately while I'm still dispatched in the
> > servlet? or will any call back only occur if I call startAsync and
> > return from the dispatch?
>
> When I first wrote the sample - I had a startAsync but I think we should
> not enforce
> the users to have to startAsync. I was thinking that the listeners could
> be called
> asynchronously. Whether it is called immediately or not - my first
> reaction is to say yes
> it can be called immediately but I will need to think a little more
> about it.
I think it could be ok to call startAsync after adding any listeners,
but if startAsync is not used, then the processing has to be complete
when the service method returns (so the listeners will never be called).
Since it doesn't make sense, an ISE probably sounds better.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc