Hi Jesse, The signature of this method has been changed with:
commit 4977f66ef55eaa5d89ed5d3751ff6aefc9652c50 Author: Matej Knopp <[email protected]> Date: Mon Jan 4 01:03:29 2010 +0000 Wild attempt to integrate new RequestCycle src/main/java almost builds, definitely doesn't work rest doesn't even build put bunch of classes that will likely be removed to src/main/disabled hopefully will continue working on it shortly I.e. it was changed in the very early early days of 1.5. I'm not sure whether the change is intentional, i.e. whether Matej wanted to improve the API by making it consistent with the rest of the code or it was just part of "make the code compiling" coding session. The javadoc says that IResourceStreamWriter can stream to the client without buffering but looking at the current version I think this is no more true, i.e. the written data IS buffered. I personally have never needed to use this class in my apps and I'm not very familiar with it. @Devs: is this class broken in 1.5.x ? Should we revert the API change for 6.x ? On Thu, Jun 7, 2012 at 6:04 PM, Jesse Long <[email protected]> wrote: > Hi Wicket Devs, > > (wicket 6.0.0-beta2 btw). > > Why does IResourceStreamWriter#write() take a Response and not an > OutputStream? > > As I see it, ResourceStreamResource (which is called from > ResourceStreamRequestHandler) is responsible for setting the headers for the > response, and does. What more could the IResourceStreamWriter want to do > with the response? > > AbstractResource#respond() calls > ResourceStreamResource#newResourceResponse(), which returns all the headers > in the ResourceReponse (using normal IResourceStream calls), and passes back > a wrapped call to IResourceStreamWriter#write() as the writer callback. > AbstractResource#respond() then sets the headers on the Response, then only > calls IResourceStreamWriter#write() via the write callback only if > AbstractResource thinks data needs to be written based on the values > returned from the normal IResourceStream calls. > > So, if the IResourceStreamWriter sets different headers in its write() > method to the values produced by calling lastModifiedTime() etc (I would > consider this a bad idea, and probably wrong), there is a danger that > unexpected behaviour may occur if AbstractResource#respond() decides NOT to > call the writer callback (which will call IResourceStreamWriter#write()). > The IResourceStreamWriter implementer may wonder why his headers are not > being set. > > If the IResourceStreamWriter does not set any headers apart from the data > available via its IResourceStream methods, then it obviously does not need a > Response object, because AbstractResource is setting all the headers > already. All IResourceStreamWriter needs to do is write data to the > OutputStream. > > Could it be a remnant of an era where Response did not have a > getOutputStream() method, and writing to it required using Response#write()? > > Also, AbstractResource.WriteCallback#writeStream() unnecessarily creates an > OutputStream that delegates write() calls to the Response. It could just as > well use the one provided by Response.getOutputStream(). > > Thanks, > Jesse > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
