Re: Problem with LineInputStream.readLine()

Xavier Poinsard wrote:
> I had a problem with POP3 retrieving of a message. After the "RETR 1" 
> commande, readline returns a string with only a LINE_FEED, but if 
> readline is called twice the second time it returns the correct answer.
> To workaround this problem, I had to force (in the code) the char by 
> char read.

Although it's quite likely there are bugs in LineInputStream, have you
ensured that the server is not actually sending a CRLF before the
response? tcpflow is a pretty useful tool for this sort of thing.

> I attached a patch which may not be applied entirely since it contains 
> various things :
> - check returns of readline to report End Of Stream
> - possible offset bug fix in indexOfCRLF()
> - javadoc for readline return
> - my workaround

This mostly looks good, but I'd prefer to try and track down the problem
in LineInputStream if possible, rather than reverting to character
reads.

> By the way, could you describe somewhere how to activate the logging ?

It's all specified in the java.util.logging package, notably in

  http://developer.classpath.org/doc/java/util/logging/LogManager.html

I realise it's a little hard to read, so here's an example. Invoke the
JVM with the system property
   -Djava.util.logging.config.file=logging.properties

In the file logging.properties, configure the logging handlers, e.g.

handlers=java.util.logging.ConsoleHandler
gnu.inet.level=INFO
gnu.inet.pop3.level=FINE

The network debug level for each client is called TRACE, and is
available programmatically as a client constant, but can't be referred
to statically in a properties file. It's between FINE and INFO though,
so if you set FINE you will get the trace messages.

If you're coming in through JavaMail, you can just set the mail.debug
session property instead and all will be handled for you.
-- 
Chris Burdess