Hi, what's a better logging strategy for struts2? In Struts 1, I used to create my own LogService using JDK logging as Struts Plug In, which got initialized when application starts. What my log service did is to archive the past application logs and create new logger&handler for different type of logs for my application. In Struts2's XML file, I didn't find corresponding plugIn place to initialize my own application-wise service at startup, and struts-plugIn.xml seems to talk about a different type of plugIn than my old Struts1 plugIn, or is it? Struts2's ActionSupport has a Log static member using Apache commons, is it a better way to handle logging? What's a better strategy of doing logging in Struts2 application, which will not only archive past logs at startup, but also differentiate a different type of logs to different log files. Thanks!
Personally I'd recommend using something like Log4J, along with its various file-based log appenders.
Joined: Mar 11, 2003
Thanks for your reply. But how could we take advantage of the commons.logging.LOG static member in ActionSupport? I think it exists there for a reason... Reading commons.logging documentation, I know the LogFactory will search for different configuration (such as log4J or JDK), but it does not go into details on how to configure for each so that LOG static member in the AcitionSupport class could be helpful (such as writing log to a file, very common requirement for an application, currently without any configuration, my struts2 application log goes to the stdout). Could you give a little bit instruction and analysis on this? In your book, is it covered? Thanks!
The book does not go into detail about configuring every possible logging implementation. I'm not overly-familiar with the member you're referring to; I generally just declare a static Log instance in each of my actions and follow standard Log4J configuration conventions depending on the application's particular logging needs.
That looks like it's just Commons Loggins Log instance, which would use whatever underlying logging implementation the application is configured to use. It's handy, but in general I'd imagine more-specific logs would be used, allowing for a more fine-grained logging configuration.