A Simple Logging Service
Logging stuff in enterprise applications is really a tough task. Actually, logging introduces a paradox: on one hand logging is really critical when something went wrong ; on the other hand, nobody cares about logging when everything is just fine. We, as developers, have to really take that into account.
Honestly, choosing a logging framework in Java is an easy task: log4j is a reasonable choice as it is widely used. The only advice that I have in mind is to take attention to resource consumption, especially if you are logging to several files. Let's say that you have found a critical bug in production and you need more logging on a particular piece of code. You need to be able to act on your logging configuration live, right? Well, all frameworks have their own Log4jService: JBoss, Spring, Geronimo, whatever. What I am proposing you is a very simple logging service that you could deploy in any environment, even as an MBean if you want. The interface of this service is really basic:JAVA:
-
public interface Log4jServiceMBean {
-
-
-
throws IllegalArgumentException;
-
-
-
-
}
If you know me, you would be surprised to see that the interface is lacking of Javadoc. Well it has, I just remove it to improve readability
. The reason why the interface is named MBean is to allow the service to be deployed as an MBean.
- a remote URL: http://stephane.nicoll.net/stuff/log4j-service/another-log4j.properties
- a file on your file system: file:/D:/log4j-service/log4j.properties
- a resource on your classpath: classpath:/net/nicoll/another-log4j.properties
JAVA:
The code is released as LGPL so feel free to use it.
-
Log4jService log4jService = new Log4jService();
-
MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer();
-
serviceObjectName = new ObjectName("nicoll.net:service=Logging");
-
mBeanServer.registerMBean(log4jService, serviceObjectName);
Sunday 18 Dec 2005 | Stéphane | Java
This service seems *really* usefull. My thought is this will become a “must use” … after testing it of course :p
There are already test cases you know
You don’t need to actually expose it as a JMX object it is a very *simple* facade above log4j functionnalities. You can just test yourself.
Who needs Javadoc anyway ?
Cool. I needed something exactly like that.
Actually, at some point, there was (maybe there still is) some jmx stuff built in log4j. From what I’ve found in mail archives, they just left it in limbo, because they couldn’t decide what to do with the updated configuration - which is something your service doesn’t solve either: if your app server restarts, you’re back to the default log config. I can personally live with that, though
So, had you seen / have you looked at the jmx stuff provided with log4j ? (hmm, even seems they might have actually worked on it : http://logging.apache.org/log4j/docs/api/org/apache/log4j/jmx/package-summary.html)
3 more things:

- I expect you’ll use the xdoclet2 maven2 plugin once it’s ready, to generate your mbean interface
- Is this available on any maven repository somewhere ?
- Build with 1.5, the jmx api is built-in, and you won’t need to rely on jboss dependencies
Hi Greg,
Yes, I have seen log4j jmx stuff. Actually, many open source products such as Jboss for instance are far beyond in term of functionnalities. The purpose of this small service is simply to provide a way to install this in any environment (app-server agnostic, desktop application, whatever). Regarding your questions:
- I am already watching your plugin and will use it as soon as I see it’s ready (do not hesitate to ping me when it’s released)
- No but if you want to I will deploy it somewhere as soon as I can
- I know and it’s actually build locally with Tiger but as I said previously, I want something which works on as much env as possible (i.e. JDK 1.3+ is supported)
Funny you’re intereseted in this actually because I am planning to upgrade it in a near future. Planned functionnalities are:
- Delegate configuration of log4j to the service instead of the boostrap (you can still bootstrap and then initialize the service with your real configuration)
- One annoying bug I did not fix so far. If you set a custom logger and then you use the reconfigure method, your custom logger is still there (it seems there is not reset logging functionnality in log4j :/)
re: the build on tiger : the user running on 1.4 or 1.3 will need the jmx api somehow, and the ones shipped with jboss (for instance) are the same as the ones with tiger, I believe.
thumbs up for the rest.
You can just use the service using the singleton pattern. Exposing it as a JMX object provides simply a way to access it “remotely”. If you have a simple web front end or a frame in your desktop application, that’s just the same.
(I have a preference for JMX for this kind of functionnality thought).
The API is not the same (well depending on the JBoss version we are talking about 1.0 for 3.2, 1.2 for 4.0) but it’s fully compatible. Anyway, I don’t use any JMX stuff in my code so we don’t care
[…] The idea started a couple of months ago in one of my post. Logging stuff in enterprise applications is really a tough task. Actually, logging introduces a paradox: on one hand logging is really critical when someting went wrong ; on the other hand, nobody cares about logging when everything is just fine. We, as developers, have to really take that into account. […]