Sure, I have a version that takes "backLogSize" as an option. I just need
to figure out how to write a unit test case for it. Who can I send it to
when I've done this?
At 09:16 PM 6/6/2002 +0200, you wrote:
>This is nice and easy. How about supporting the size of the backlog as an
>option?
>
>At 12:07 06.06.2002 -0500, you wrote:
>>The TelnetAppender is extremely convenient, providing access to the
>>running log no matter where you are, since nearly all operating systems
>>now have a basic telnet client built into them. Unfortunately I was
>>unable to live with the most glaring shortcoming, that the appender
>>forces you to wait until you have sufficient lines of output to make a
>>judgement about the context in which things are happening. You would not
>>be able to tell someone to connect to serverX to see what you've found
>>without also saying "ok, you're connected yet? Lemme do it again,
>>watch..." What the TelnetAppender needs is a backlog of lines so that any
>>newly connecting client will immediately show more of what's happening,
>>making things that much easier on the user.
>>
>>Unfortunately the changes need to be made to the inner class, so I was
>>unable to subclass the TelnetAppender to make a, say, TelnetTailAppender.
>>The class I have been using has been a direct derivative of the original.
>>The changes I am suggesting could easily be added to the existing
>>TelnetAppender without incurring any backward incompatibilities - if you
>>added a setter to assign the number of lines to backlog and default to
>>zero, then a program that expected the old behavior and did not set the
>>backlog count would experience that behavior.
>>
>>The following are the changes to TelnetAppender.SocketHandler, in which I
>>have hard-coded to 100 lines of backlog.
>>
>> private String[] backLog = new String[100];
>> private int backLogIndex = 0;
>>
>> /**
>> * New method, adds a message to the backlog and moves the index
>> */
>> private void appendBackLog(String message){
>> synchronized(backLog){
>> backLog[backLogIndex] = message;
>> if(++backLogIndex == backLog.length){
>> backLogIndex = 0;
>> }
>> }
>> }
>>
>> /**
>> * New method, sends the contents of the backlog (if any) to the
>> * specified print writer, presumably the newly connected telnet
>> * client
>> */
>> private void sendBackLog(PrintWriter pw){
>> synchronized(backLog){
>> for(int i=backLogIndex;i<backLog.length;i++){
>> if(backLog[i]!=null){
>> pw.print(backLog[i]);
>> }
>> }
>> for(int i=0;i<backLogIndex;i++){
>> pw.print(backLog[i]);
>> }
>> }
>> }
>>
>>In run() method, after a new connection has been accepted:
>>
>> sendBackLog(pw);
>>
>>in send(String message) method, at first line:
>>
>> appendBackLog(message);
>>
>>
>>
>>Any comments? Reasons of why this is not a good solution? Features of
>>another appender that I am not aware of?
>>
>>Regards,
>>John Churchill
>>
>>
>>--
>>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>--
>Ceki
>
>SUICIDE BOMBING - A CRIME AGAINST HUMANITY
>Sign the petition: http://www.petitiononline.com/1234567b
>I am signatory number 22106. What is your number?
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
