Logging problem.

Question

Hi,
I when I upgraded from edtftpj-1.5.2 to edtftp-1.5.5 it stopped logging. I

Answer 1

It should work, unless we've made a change that has broken log4j integration. Any clues that point to anything? Is the only change the new edtftpj.jar file?

Answer 2

Thanks for the quick response.
Yes, all I did to get it to work again was to rebuild and deploy with the old jar (1.5.2).
I

Answer 3

Hi,
I found what caused the problem.
In the 1.5.2 version loggers were obtained as follows:
private Logger log = Logger.getLogger(FTPControlSocket.class);
In the 1.5.5:
private static Logger log = Logger.getLogger("FTPControlSocket");

Setting logging for the classes in the

Answer 4

Ah, that explains it. Thanks for looking into the problem.

This is an intentional change but the affects you are experiencing aren't what we intended. We have changed to using strings rather than the actual class because if the class is obfuscated, you get a nonsensical logger name.

We're not sure of the best solution here - perhaps the whole package name needs to be hard coded in the logger name.

Answer 5

Yes, including the whole package name would work.

Regards
Lars

Answer 6

I just ran into this same issue. It's really painful having the Loggers named by the class name only without the package name because it makes it nearly impossible to control the logging level. As above, Log4j (and most other) logging systems are designed to be hierachical making it easy to turn on/off logging at the package level. I'm using v2.0.5, is there a plan to fix this anytime soon. Do you accept patches? I would point out that if you're using obfuscation for some reason but keep the Loggers named with their actual class name you've mostly defeated the obfuscation anyhow so I'm not sure why you don't just go back to using class.getName()?

Thanks,
Corey

Answer 7

We do use this in proprietary code which gets obfuscated. The name of the class is only a minor part of obfuscation.

However we'll discuss use of package names ... that obviously would be useful.