Hi, First, sorry for my late reply, and for my horrible planning (adding this just before a release ;-).
I've created the StreamReader (discussed here [1]). I've copied the ResourceReader, and made modifications where required: where the ResourceReader uses a source, I use (configurable) JXPath expressions to look up the information required: * the input stream * the mime type * the content length. The implementation can be found here [2]. The rest of the code is copied from the ResourceReader implementation, and could thus be shared in an abstract class. For example, an AbstractResourceReader class which has three methods: getInputStream() getContentLength() getMimeType() -> already required by a Reader, right? The current resource reader can implement these methods with the source it looks up. The StreamReader can implement these methods and return values found by Xpath expressions. I can make the change, if it is a good idea of course (other ideas are also welcome). Please let me know what others think. Thanks, Bart. [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110872385503566&w=2 [2] http://issues.apache.org/bugzilla/attachment.cgi?id=14534&action=edit > -----Original Message----- > From: Alfred Nathaniel [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 02, 2005 5:30 PM > To: [email protected] > Subject: Re: AbstractResourceReader? > > On Wed, 2005-03-02 at 15:38, Bart Molenkamp wrote: > > Hi, > > > > A while ago I was discussing how to build a reader that could get it's > > input stream from the context object using JXPath. It gets the following > > information from the context object using configurable Xpath > > expressions: > > - the content stream > > - the mime type > > - the content length > > > > I've created the reader by simply copying the existing ResourceReader > > and replaced all the code where a Source was used to use the content > > input stream, the content length and the content type that are passed in > > the context object. > > > > The reader is working this way, but I was wondering if it makes sense to > > create another abstract reader that handles things that are common to > > the ReasourceReader and the StreamReader (the reader I've created). It > > concers many HTTP specific code such as byte range, content expiration, > > etc. I've used all that code (only difference is that my reader isn't > > cacheable, don't know how to generate a key yet). > > > > Can someone tell me what code would be common (as I don't have specific > > knowledge about these http byte range, expiration etc things), or if it > > doesn't make sense at all. > > > > Bart. > > I think it would be more elegant to wrap your input stream in a Source > object (StreamSource extends o.a.excalibur.source.impl.AbstractSource). > Then your StreamReader can extend ResourceReader and just needs to > override the setup method. > > However, ResourceReader.setup must be refactored to move the inputSource > resolving into a separate method which a derived class can override. > Otherwise StreamReader.setup cannot call super.setup. This is necessary > not only to avoid duplicating the parameter decoding in > ResourceReader.setup but also because you would need to call > super.super.setup which is not allowed in Java. > > Cheers, Alfred.
