I'm writing a library and would like to use perf4j mainly to expose JMX performance counters.
According to the instructions here http://perf4j.codehaus.org/devguide.html perf4j is meant to be used in conjunction with log4j, however since I'm writing a library I have no control over log4j usage, users of the library may or may not wish to use log4j and I don't want to make this a requirement.
Is there a way to use perf4j, specifically expose perf4j JMX counters programatically without requiring use of log4j?
views:
75answers:
1
A:
I would say yes. I followed the link you posted and noticed that the first paragraph said
Some of the the Perf4J tools require additional dependencies (for example, the custom log4j appenders require the log4j jar to also be in your classpath).
That suggests to me that not having log4j in your classpath is a normal thing.
Paul Clapham
2010-02-28 05:44:11
Specifically JMX appenders look like they can only work with log4j.xml so I was wondering if there's an example without log4j. The page I linked doesn't have this but maybe it's out there somewhere...
Ran
2010-02-28 06:03:24
Well, there do seem to be a couple of examples that don't use log4j, but most of them do use it. However most people don't hesitate to specify dependencies when they exist (as that page you linked to does, often) so I'm not sure why you hesitate to do that.
Paul Clapham
2010-03-03 04:12:47
The features in perf4j I'd like to use require log4j.xml (and not log4j.properties) which, although is the preferred way, isn't very common in many existing applications so I don't want to overload the requirements by making my users move from .properties to .xml. I was forced to do that once and it wasn't peasant...
Ran
2010-03-07 08:01:06
So now you know the requirements which perf4j imposes upon you for this thing you want to do. You can accept them or not. If the cost of accepting them exceeds the benefit that perf4j would produce, then don't use perf4j. Otherwise accept the costs knowing that you get a greater benefit in the end.
Paul Clapham
2010-03-07 22:05:05