My JSF application is deployed with a recent version of Glassfish, using EclipseLink as a JPA provider. I wrote a fairly simplistic logging facility that stores log records in the JPA data base. The columns for the Log table includes the timestamp (of course), an enum key field for the log record type, the current User ID, the network address, and a string message.
None of this is broke, so naturally I want to go fix it. (kidding) What I really want to know is am I missing something by not using one of the established logging APIs and packages and using facilities out of Glassfish? I would be interested to learn of any logging perusal and analysis tools I have opted out of by rolling my own. Any commentary would be appreciated.
Update To Question: If I convert to java.util.Logging, is there a path to capturing the log data to my SQL back end? It is very convenient for searching and looking stuff up, and the existing logging facilities seem to be oriented to outputting to text files.
This question has been rolling around in my head, and – like so many – it just begs further questions. Where to start?
java.util.logging (j.u.l), commons-logging, Log4J, etc. and all other variants are traditionally oriented (I’m really trying hard not to say intended) towards diagnostic and admin logs. They’re not ideal for application "event" logs – depending on your definition of event. The primary argument behind that statement is that these tools are oriented strictly towards capturing a textual string from the code.
So, who is your audience?
If:
If you need more "bandwidth" than a line of text, j.u.l & family are NOT for you.
Some of the diagnostic-loggers will allow you to create custom categories – I believe Log4J does, for example. Most of the common alternatives don’t (j.u.l specifically does not do it nicely, if at all).
Final Note
It’s trivial to capture DB/table driven log detail into a diagnostic logging facility by calling the appropriate log.info() statements, it’s going to be a bit more difficult to go in reverse. Don’t throw away the one out of simple curiosity about the other.