You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stefan Bodewig <bo...@apache.org> on 2009/03/28 16:34:15 UTC
Re: svn commit: r759472 - in /commons/proper/compress/trunk/src/site: site.xml xdoc/examples.xml xdoc/index.xml xdoc/zip.xml
On 2009-03-28, sebb <se...@gmail.com> wrote:
>>> <p>Reading entries from an ar archive:</p>
>>> <source><![CDATA[
>>> ArArchiveEntry entry = (ArArchiveEntry) arInput.getNextEntry();
>>> byte[] content = new byte[entry.getSize()];
>>> LOOP UNTIL entry.getSize() HAS BEEN READ {
> I thought the idea was that the ArchiveInputStreams would not allow
> one to read past the end of the entry, so one can just read until
> read() returns -1?
I wrote that on the train last night while I was offline and committed
it this afternoon before reading my mail 8-)
I don't think AR is the only archiver that does not return -1 once you
read past the end of the current entry, nor am I convinced that it is
a good idea to expect the streams to do so.
The code of the examples should work and IMHO the API user should
rather rely on the entry's size than on the stream returning -1. Are
we sure our streams return -1 on directory entries immediately?
BTW, while catching up with mail I saw a lot of discussion going on
inside JIRA instead of on the dev list. This may be a project
cultural thing, but to me JIRA is not the correct place for that.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r759472 - in /commons/proper/compress/trunk/src/site:
site.xml xdoc/examples.xml xdoc/index.xml xdoc/zip.xml
Posted by sebb <se...@gmail.com>.
On 30/03/2009, Stefan Bodewig <bo...@apache.org> wrote:
> On 2009-03-28, sebb <se...@gmail.com> wrote:
>
> > On 28/03/2009, Stefan Bodewig <bo...@apache.org> wrote:
> >> On 2009-03-28, sebb <se...@gmail.com> wrote:
>
>
> >>> I thought the idea was that the ArchiveInputStreams would not allow
> >>> one to read past the end of the entry, so one can just read until
> >>> read() returns -1?
>
>
> >> I don't think AR is the only archiver that does not return -1 once you
> >> read past the end of the current entry, nor am I convinced that it is
> >> a good idea to expect the streams to do so.
>
> > I thought that was the main idea of the archive input stream.
> > IMO, it makes using the classes much easier.
>
>
> It probably does. If this is the intended behaviour, we should
> document it properly. Ideally at the ArchiveInputStream level.
>
I already did that ;-)
The Output Javadoc still needs to be done; I'll make a start later.
> >> BTW, while catching up with mail I saw a lot of discussion going on
> >> inside JIRA instead of on the dev list. This may be a project
> >> cultural thing, but to me JIRA is not the correct place for that.
>
> > I tend to agree, but it can be useful.
>
> > I've seen JIRA issues that have almost no information and so are hard
> > to follow; probably there was other information on the mailing list,
> > but if it's not referenced from the JIRA it can be hard to find later.
>
>
> Personally I prefer to have the JIRA entry point to the mailing list
> archive of the dev list in such a case. Not everybody who might be
> innterested in the discussion may be subscribed to the issues list.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r759472 - in /commons/proper/compress/trunk/src/site: site.xml xdoc/examples.xml xdoc/index.xml xdoc/zip.xml
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-03-28, sebb <se...@gmail.com> wrote:
> On 28/03/2009, Stefan Bodewig <bo...@apache.org> wrote:
>> On 2009-03-28, sebb <se...@gmail.com> wrote:
>>> I thought the idea was that the ArchiveInputStreams would not allow
>>> one to read past the end of the entry, so one can just read until
>>> read() returns -1?
>> I don't think AR is the only archiver that does not return -1 once you
>> read past the end of the current entry, nor am I convinced that it is
>> a good idea to expect the streams to do so.
> I thought that was the main idea of the archive input stream.
> IMO, it makes using the classes much easier.
It probably does. If this is the intended behaviour, we should
document it properly. Ideally at the ArchiveInputStream level.
>> BTW, while catching up with mail I saw a lot of discussion going on
>> inside JIRA instead of on the dev list. This may be a project
>> cultural thing, but to me JIRA is not the correct place for that.
> I tend to agree, but it can be useful.
> I've seen JIRA issues that have almost no information and so are hard
> to follow; probably there was other information on the mailing list,
> but if it's not referenced from the JIRA it can be hard to find later.
Personally I prefer to have the JIRA entry point to the mailing list
archive of the dev list in such a case. Not everybody who might be
innterested in the discussion may be subscribed to the issues list.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: svn commit: r759472 - in /commons/proper/compress/trunk/src/site:
site.xml xdoc/examples.xml xdoc/index.xml xdoc/zip.xml
Posted by sebb <se...@gmail.com>.
On 28/03/2009, Stefan Bodewig <bo...@apache.org> wrote:
> On 2009-03-28, sebb <se...@gmail.com> wrote:
>
> >>> <p>Reading entries from an ar archive:</p>
> >>> <source><![CDATA[
> >>> ArArchiveEntry entry = (ArArchiveEntry) arInput.getNextEntry();
> >>> byte[] content = new byte[entry.getSize()];
> >>> LOOP UNTIL entry.getSize() HAS BEEN READ {
>
> > I thought the idea was that the ArchiveInputStreams would not allow
> > one to read past the end of the entry, so one can just read until
> > read() returns -1?
>
>
> I wrote that on the train last night while I was offline and committed
> it this afternoon before reading my mail 8-)
>
> I don't think AR is the only archiver that does not return -1 once you
> read past the end of the current entry, nor am I convinced that it is
> a good idea to expect the streams to do so.
I thought that was the main idea of the archive input stream.
IMO, it makes using the classes much easier.
AFAICS, the test cases currently assume it.
If users are not prevented from reading past the entry without calling
getNextEntry(), the input stream class can easily get lost.
> The code of the examples should work and IMHO the API user should
> rather rely on the entry's size than on the stream returning -1. Are
> we sure our streams return -1 on directory entries immediately?
That needs to be tested and fixed if not.
> BTW, while catching up with mail I saw a lot of discussion going on
> inside JIRA instead of on the dev list. This may be a project
> cultural thing, but to me JIRA is not the correct place for that.
I tend to agree, but it can be useful.
I've seen JIRA issues that have almost no information and so are hard
to follow; probably there was other information on the mailing list,
but if it's not referenced from the JIRA it can be hard to find later.
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org