On Sun, 2006-02-19 at 17:56 -0800, Craig McClanahan wrote: > Simon, > > Could you do me a favor and publicize this in the Struts community as > well? The framework code there is littered with static log instances > to.
Will do. > You might also want to add some notes related to using Log instances > in Serializable classes (see below). Will do that also. > > MyFaces folks, > > There *is* a JSF-specific consideration to think about, if you have > classes that implement StateHolder (like a UIComponent > implementation). Log instances will generally *not* be serializable, > so you will need to deal specially with them in saveState() and > restoreState() methods. The simplest thing is to just not save them, > and do a "new" operation again in restoreState(). Sorry but I don't understand. Why won't the normal approach work? public class SomeComponent .... { private Log log = LogFactory.getLog(SomeComponent.class); ... } AIUI, the log object won't be saved in the saveState method, but it will be recreated nicely during the RestoreView phase when a new instance is created for the state to be restored into. > > Along the same lines, if your class implements Serializable, you will > need to mark the instance variable transient. I've started using the > following pattern in my Serializable classes, which would work inside > a StateHolder as well: > > private transient Log log = null; > > private Log log() { > if (log == null) { > log = LogFactory.getLog(...); > } > return log; > } > > and a typical call looks like: > > if (log().isDebugEnabled()) { > log().debug("..."); > } Ok, transient is needed here. But apart from that why won't the standard approach work? public class SomeThing implements Serializable { private transient Log log = LogFactory.getLog(SomeThing.class); ... if (log.isDebugEnabled()) { log.debug("..."); } } Doesn't the log object get recreated when the deserialization occurs? The log() method is quite a lot of boilerplate, and also imposes an additional method call for every isDebugEnabled() call. [The extra call inside the guard is not really relevant as output *is* going to occur at this point which greatly outweighs the price of the method call]. Cheers, Simon