Logging with Jakarta log4j - How to avoid depencies?

[Jan van Mansum]

Hello group,

I have just been trying out the log4j library. As far as I understand
the idea is to keep the logging statements in your, even in the release
build. However, obviously you wouldn't want to have to ship the log4j
jar with your app, to avoid class definition not found exceptions. As
a matter of fact you wouldn't want the end user to be able to turn on
logging.

I have been thinking about how to handle this. The only thing I can
come up with so far, is just create a couple wrapper classes round the
log4j classes and replace them with empty onces at build-time.

Is this the only way to handle this problem? Has someone out there found
a more elegant way?

Thanks in advance,
regards,
Jan van Mansum.

[Roman]

Just as a quick idea, could'nt you check if the log4j Logger class exists on
start up through java reflection?
If it exists you would use the logger and if it does not there will be no
logging done.
Of course you can wrap this functionality in a class that would do the
checks upon start up.

You could also try to catch the ClassNotFound exception where ever you use
log4j and do nothing about it.

Not sure if that helps.

Roman.

"Jan van Mansum" <jv*@nospam.com> wrote in message
news:40*********************@news.xs4all.nl...

Hello group,

I have just been trying out the log4j library. As far as I understand
the idea is to keep the logging statements in your, even in the release
build. However, obviously you wouldn't want to have to ship the log4j
jar with your app, to avoid class definition not found exceptions. As
a matter of fact you wouldn't want the end user to be able to turn on
logging.

I have been thinking about how to handle this. The only thing I can
come up with so far, is just create a couple wrapper classes round the
log4j classes and replace them with empty onces at build-time.

Is this the only way to handle this problem? Has someone out there found
a more elegant way?

Thanks in advance,
regards,
Jan van Mansum.

[Roman]

Just as a quick idea, could'nt you check if the log4j Logger class exists on
start up through java reflection?
If it exists you would use the logger and if it does not there will be no
logging done.
Of course you can wrap this functionality in a class that would do the
checks upon start up.

You could also try to catch the ClassNotFound exception where ever you use
log4j and do nothing about it.

Not sure if that helps.

Roman.

"Jan van Mansum" <jv*@nospam.com> wrote in message
news:40*********************@news.xs4all.nl...

Hello group,

I have just been trying out the log4j library. As far as I understand
the idea is to keep the logging statements in your, even in the release
build. However, obviously you wouldn't want to have to ship the log4j
jar with your app, to avoid class definition not found exceptions. As
a matter of fact you wouldn't want the end user to be able to turn on
logging.

I have been thinking about how to handle this. The only thing I can
come up with so far, is just create a couple wrapper classes round the
log4j classes and replace them with empty onces at build-time.

Is this the only way to handle this problem? Has someone out there found
a more elegant way?

Thanks in advance,
regards,
Jan van Mansum.

[Jan van Mansum]

Roman wrote:

Just as a quick idea, could'nt you check if the log4j Logger class exists on
start up through java reflection?
If it exists you would use the logger and if it does not there will be no
logging done.
Of course you can wrap this functionality in a class that would do the
checks upon start up.
That's an idea, only the "hackers" among our end users could still turn
on logging that way. (It wouldn't do them much good, as the release code
gets obfuscated, but anyway ...)

You could also try to catch the ClassNotFound exception where ever you use
log4j and do nothing about it.

That helps, but would force me to write try-catch blocks for every
logging statement, which IMHO is not such a good idea.

In short, I think I'll go for the empty class solution. Thanks anyway
for your comments.

Regards,
Jan van Mansum.

[Jan van Mansum]

Roman wrote:

Just as a quick idea, could'nt you check if the log4j Logger class exists on
start up through java reflection?
If it exists you would use the logger and if it does not there will be no
logging done.
Of course you can wrap this functionality in a class that would do the
checks upon start up.
That's an idea, only the "hackers" among our end users could still turn
on logging that way. (It wouldn't do them much good, as the release code
gets obfuscated, but anyway ...)

You could also try to catch the ClassNotFound exception where ever you use
log4j and do nothing about it.

That helps, but would force me to write try-catch blocks for every
logging statement, which IMHO is not such a good idea.

In short, I think I'll go for the empty class solution. Thanks anyway
for your comments.

Regards,
Jan van Mansum.