You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Tim Williams <wi...@gmail.com> on 2006/01/30 00:02:45 UTC
Extending the image reader
I want the image reader to accept a variant name (e.g. "thumb",
"small") and then write the newly created image variant to disk before
sending the output. In other words, so that a given image
"IMG001.jpg" might be "read" with a variant "thumb" and on disk would
now be:
IMG001.jpg
IMG001.thumb.jpg
Obviously, a hefty cost for the first time through on each image but
just reading afterwards. I've initially done this by just copying the
entire ImageReader into a new PersistentImageReader and inserting the
applicable code in setup() and processStream(). Now that it's working
how I'd like, I figured I'd just extend the ImageReader and only
implement these two methods. The only way I can think to do it is
somehow redirect the output into a buffer, write the buffer, then send
it out. Is there a better way to extend a reader? Anyone have any
clues as to how I might be able to buffer the ImageReader's output?
Thanks,
--tim
Re: Extending the image reader
Posted by Upayavira <uv...@odoko.co.uk>.
Jean-Baptiste Quenot wrote:
> * Upayavira:
>
>
>>Ah. And currently the cache doesn't survive restarts in the CLI,
>>which it should. So your approach is now more understandable.
>
>
> AFAICT it does not survive restarts in servlet mode either,
> notwithstanding the before-to-last argument set to true
> (corresponds to diskPersistent argument) passed to the Cache()
> constructor called from EHDefaultStore.
Yes, but it is more important in the CLI, where each invocation involves
creating and disposing Cocoon, so the cache persistance is a much bigger
deal.
Regards, Upayavira
Re: Extending the image reader
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Upayavira:
> Ah. And currently the cache doesn't survive restarts in the CLI,
> which it should. So your approach is now more understandable.
AFAICT it does not survive restarts in servlet mode either,
notwithstanding the before-to-last argument set to true
(corresponds to diskPersistent argument) passed to the Cache()
constructor called from EHDefaultStore.
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Re: Extending the image reader
Posted by Upayavira <uv...@odoko.co.uk>.
Tim Williams wrote:
> On 1/30/06, Upayavira <uv...@odoko.co.uk> wrote:
>
>>Tim Williams wrote:
>>
>>>I want the image reader to accept a variant name (e.g. "thumb",
>>>"small") and then write the newly created image variant to disk before
>>>sending the output. In other words, so that a given image
>>>"IMG001.jpg" might be "read" with a variant "thumb" and on disk would
>>>now be:
>>>IMG001.jpg
>>>IMG001.thumb.jpg
>>>
>>>Obviously, a hefty cost for the first time through on each image but
>>>just reading afterwards. I've initially done this by just copying the
>>>entire ImageReader into a new PersistentImageReader and inserting the
>>>applicable code in setup() and processStream(). Now that it's working
>>>how I'd like, I figured I'd just extend the ImageReader and only
>>>implement these two methods. The only way I can think to do it is
>>>somehow redirect the output into a buffer, write the buffer, then send
>>>it out. Is there a better way to extend a reader? Anyone have any
>>>clues as to how I might be able to buffer the ImageReader's output?
>>
>>Well, sounds like you're trying to achieve something similar to caching.
>>I wonder if the caching system might be an alternative approach to
>>achieving the same thing.
>>
>>Anyway, to answer your question directly...
>>
>>The AbstractReader class has a setOutputStream method. You could, in
>>your generate() method:
>> * check to see if the resource has already been generated. If it has,
>> set the inputSource to that of your cached version and proceed as
>> normal (calling super.generate())
>> * Otherwise, take a copy of the existing output stream, set the output
>> stream (using setOutputStream) to your own buffering version. Proceed
>> as normal. At the end of the generate method you write the contents
>> of buffer to disc, then copy contents of buffer to original output
>> stream.
>>
>>I think that would work. And this should work as an extension of the
>>ImageReader class as you suggest.
>>
>>Have I understood your question?
>>
>>Regards, Upayavira
>
>
> Exactly, I'll give these a try and see what I can manage. It is
> essentially the same as caching but I need something that can work in
> both webapp and cli modes in forrest.
Ah. And currently the cache doesn't survive restarts in the CLI, which
it should. So your approach is now more understandable.
Regards, Upayavira
Re: Extending the image reader
Posted by Tim Williams <wi...@gmail.com>.
On 1/30/06, Upayavira <uv...@odoko.co.uk> wrote:
> Tim Williams wrote:
> > I want the image reader to accept a variant name (e.g. "thumb",
> > "small") and then write the newly created image variant to disk before
> > sending the output. In other words, so that a given image
> > "IMG001.jpg" might be "read" with a variant "thumb" and on disk would
> > now be:
> > IMG001.jpg
> > IMG001.thumb.jpg
> >
> > Obviously, a hefty cost for the first time through on each image but
> > just reading afterwards. I've initially done this by just copying the
> > entire ImageReader into a new PersistentImageReader and inserting the
> > applicable code in setup() and processStream(). Now that it's working
> > how I'd like, I figured I'd just extend the ImageReader and only
> > implement these two methods. The only way I can think to do it is
> > somehow redirect the output into a buffer, write the buffer, then send
> > it out. Is there a better way to extend a reader? Anyone have any
> > clues as to how I might be able to buffer the ImageReader's output?
>
> Well, sounds like you're trying to achieve something similar to caching.
> I wonder if the caching system might be an alternative approach to
> achieving the same thing.
>
> Anyway, to answer your question directly...
>
> The AbstractReader class has a setOutputStream method. You could, in
> your generate() method:
> * check to see if the resource has already been generated. If it has,
> set the inputSource to that of your cached version and proceed as
> normal (calling super.generate())
> * Otherwise, take a copy of the existing output stream, set the output
> stream (using setOutputStream) to your own buffering version. Proceed
> as normal. At the end of the generate method you write the contents
> of buffer to disc, then copy contents of buffer to original output
> stream.
>
> I think that would work. And this should work as an extension of the
> ImageReader class as you suggest.
>
> Have I understood your question?
>
> Regards, Upayavira
Exactly, I'll give these a try and see what I can manage. It is
essentially the same as caching but I need something that can work in
both webapp and cli modes in forrest.
Thanks,
--tim
Re: Extending the image reader
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 01 February 2006 23:24, Jean-Baptiste Quenot wrote:
> About this patch, could someone explain how I can add a block in
> Cocoon 2.1? Does it involve adding the new block in gump.xml?
> Does the build depend on gump.xml directly, or is there an
> intermediate step required?
I recalled vaguely that I built under the 2.2 branch but it was deployed on
2.1.6 system at the end of the day. Not sure how gump.xml are handled these
days in respect to the Cocoon build system, but IIRC it was the opposite
direction before, i.e. the gump.xml was generated from the build system.
Cheers
Niclas
Re: Extending the image reader
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Niclas Hedhman:
> On Monday 30 January 2006 18:00, Upayavira wrote:
>
> > Well, sounds like you're trying to achieve something similar
> > to caching. I wonder if the caching system might be an
> > alternative approach to achieving the same thing.
>
> There is an ImageOpReader sitting in JIRA[1] as a contribution,
> which didn't gain enough interest to be included in the
> main/block distro.
About this patch, could someone explain how I can add a block in
Cocoon 2.1? Does it involve adding the new block in gump.xml?
Does the build depend on gump.xml directly, or is there an
intermediate step required?
TIA,
--
Jean-Baptiste Quenot
http://caraldi.com/jbq/
Re: Extending the image reader
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 30 January 2006 18:00, Upayavira wrote:
> Well, sounds like you're trying to achieve something similar to caching.
> I wonder if the caching system might be an alternative approach to
> achieving the same thing.
There is an ImageOpReader sitting in JIRA[1] as a contribution, which didn't
gain enough interest to be included in the main/block distro.
I never got to complete the parts that I don't use, but essentially we
generate any sized image (out of really high-res tiff images), including
thumbs, for browsing, for computer view and print. I am surprised at how
quick the Java2D libraries can be and the caching in Cocoon seems to work
nicely (at least for our relatively low traffic sites).
Cheers
Niclas
[1] http://issues.apache.org/jira/browse/COCOON-1301
Re: Extending the image reader
Posted by Upayavira <uv...@odoko.co.uk>.
Tim Williams wrote:
> I want the image reader to accept a variant name (e.g. "thumb",
> "small") and then write the newly created image variant to disk before
> sending the output. In other words, so that a given image
> "IMG001.jpg" might be "read" with a variant "thumb" and on disk would
> now be:
> IMG001.jpg
> IMG001.thumb.jpg
>
> Obviously, a hefty cost for the first time through on each image but
> just reading afterwards. I've initially done this by just copying the
> entire ImageReader into a new PersistentImageReader and inserting the
> applicable code in setup() and processStream(). Now that it's working
> how I'd like, I figured I'd just extend the ImageReader and only
> implement these two methods. The only way I can think to do it is
> somehow redirect the output into a buffer, write the buffer, then send
> it out. Is there a better way to extend a reader? Anyone have any
> clues as to how I might be able to buffer the ImageReader's output?
Well, sounds like you're trying to achieve something similar to caching.
I wonder if the caching system might be an alternative approach to
achieving the same thing.
Anyway, to answer your question directly...
The AbstractReader class has a setOutputStream method. You could, in
your generate() method:
* check to see if the resource has already been generated. If it has,
set the inputSource to that of your cached version and proceed as
normal (calling super.generate())
* Otherwise, take a copy of the existing output stream, set the output
stream (using setOutputStream) to your own buffering version. Proceed
as normal. At the end of the generate method you write the contents
of buffer to disc, then copy contents of buffer to original output
stream.
I think that would work. And this should work as an extension of the
ImageReader class as you suggest.
Have I understood your question?
Regards, Upayavira