On 5/22/07, Tom Nichols <[EMAIL PROTECTED]> wrote:
Wow, committed already! I think that was the easiest patch I've ever
submitted :)
Any speculation on when this might be released?
Difficult to say - since this was the first change for 1.4, so it will
probably be a while before there is motivation for a new release. I
could ask the IO 1.3.2 release manager if he minds me porting it to
the 1.3 branch (so that it makes 1.3.2) but unless he agrees it could
be a while.
btw I just renamed the method to resetByteCount() to make it more
explict what its function is.
Niall
Thanks.
-Tom
On 5/22/07, Tom Nichols <[EMAIL PROTECTED]> wrote:
> Done. https://issues.apache.org/jira/browse/IO-121
>
> Thanks!
> -Tom
>
> On 5/22/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
> > On 5/22/07, Tom Nichols <[EMAIL PROTECTED]> wrote:
> > > Hi --
> > >
> > > I wanted to use ThresholdingOutputStream to basically split output
> > > over multiple files when a byte count is reached (Similar to a rolling
> > > file log). I could do this easily by implementing thresholdReached().
> > > The method would close the current stream, create a new stream, and
> > > then reset the written and thresholdExceeded values. The problem, of
> > > course, is that I can't change the values of written and
> > > thresholdExceeded. Basically I want to be able to hit a byte
> > > threshold multiple times instead of just once.
> > >
> > > In order to do the same thing with the current implementation, I need
> > > to override checkThreshold( int ) and then try to keep track of how
> > > many bytes were written to all previous output streams:
> > > protected void checkThreshold(int count) throws IOException
> > > {
> > > if ( getByteCount() - writtenToPreviousStreams + count >
threshold )
> > > {
> > > writtenToPreviousStreams = getByteCount();
> > > //switch to new output stream
> > > }
> > > }
> > >
> > > And I would have to override isThresholdExceeded() otherwise it would
> > > return true even though it is not true for the current stream. And
> > > then thresholdReached() is never called and has to be an empty method.
> > > So you can see this becomes a little more cumbersome.
> > >
> > > So would there be any problems with adding:
> > > protected setThresholdExceeded( boolean thresholdExceeded ) and
> > > setByteCount( long written )
> > > or maybe just a protected reset() method?
> > >
> > > The only other change that would need to be made: currently in
> > > checkThreshold(int), thresholdExceeded needs to be set to true before
> > > the call to thresholdReached() so that the value may be reset to false
> > > inside thresholdReached(). But this should not cause any problem
> > > AFAIK since thresholdExceeded is private anyway.
> > >
> > > protected void checkThreshold(int count) throws IOException
> > > {
> > > if (!thresholdExceeded && (written + count > threshold))
> > > {
> > > thresholdExceeded = true; //this was previously set after the
> > > thresholdReached() call
> > > thresholdReached();
> > > }
> > > }
> > >
> > > Any comments? Thanks.
> >
> > Adding setters for thresholdExceeded and byteCount is allowing people
> > to shoot themselves in the foot IMO - but I think reset() is a good
> > idea. Best thing is to create a Jira ticket for this:
> >
> > http://jakarta.apache.org/commons/io/issue-tracking.html
> >
> > Niall
> >
> > > -Tom
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
