Re: [S2] Can't setBufferSize on StreamResult from action configuration (Struts2 2.1.6)

[Francisco José Aquino García <fj...@gmail.com>]

2009/7/1 Dale Newfield <da...@newfield.org>:
> The problem is that there is no evaluation going on for that value.  If you
> need to dynamically set the buffer size, you'll need to use a different
> result implementation that accepts a string and evaluates it.  Extending
> StreamResult would get you most of the way there.  If you'd like to
> contribute your improvements back to the community, you can add those
> patches to a JIRA request.  May I ask why you need to dynamically change the
> buffer size?

ThumbnailAction uses a resolve() method that translates a document id
into a thumbnail filename to get the stream to the client. When I saw
that StreamResult uses a bufferSize parameter I thought that perhaps
it would be a good idea to use the filesystem block size where the
thumbnail resides as the bufferSize, as different thumbnails may
reside in different filesystems (it's hardcoded into the action in the
first post, but that path/filename will come out of a DB.) It will be
a very frequently used action, with anywhere between 2-200 thumbnails
per page.

That's it. I didn't think very much about it really, I'm not an expert
in Java IO so maybe this makes not much sense (the same goes for using
BufferedInputStream instead of just the default InputStream.)

-Fran Aquino

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [S2] Can't setBufferSize on StreamResult from action configuration (Struts2 2.1.6)

[Dale Newfield <da...@newfield.org>]

Francisco José Aquino García wrote:
> 2009/7/1 Dale Newfield <da...@newfield.org>:
>> May I ask why you need to dynamically change the buffer size?
> 
> to use the filesystem block size where the thumbnail resides as the
> bufferSize, as different thumbnails may reside in different
> filesystems

That sounds like a reasonable motivation.  Unfortunately as we've 
previously discussed, the current stream result object won't support 
dynamic values for this.  An evil workaround could be to configure a 
bunch of nearly identical results "success-stream-512", 
"success-stream-1024", "success-stream-8192", etc. and dispatch to the 
appropriate one.  A better solution would be to modify the stream 
result.  Patches are welcome to change that, and if you're quick (and if 
you smile sweetly at Musachy) you might be able to get that change into 
2.1.8...

> That's it. I didn't think very much about it really, I'm not an expert
> in Java IO so maybe this makes not much sense (the same goes for using
> BufferedInputStream instead of just the default InputStream.)

BufferedInputStream adds much more complexity and probably isn't 
necessary, but as long as it works...

-Dale

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org