By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,203 Members | 1,401 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,203 IT Pros & Developers. It's quick & easy.

Logging with Jakarta log4j - How to avoid depencies?

P: n/a
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.
Jul 17 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
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.

Jul 17 '05 #2

P: n/a
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.

Jul 17 '05 #3

P: n/a
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.
Jul 17 '05 #4

P: n/a
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.
Jul 17 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.