Hmm... didn't we settle on JDK 1.4 a while ago?
Simon has some other arguments on not using JDK logging, see above.
regards,
Martin
On 2/20/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
>
> On 2/19/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
> > Indeed.
> >
> > this really means I'd be willing to switch to JDK logging. What was
> > the reason again we couldn't do that?
>
> If we are willing to live with a "JDK 1.4 or later" restriction, no reason
> at all. That, however, would seem to be an issue for some current users.
>
> > regards,
> >
> > Martin
>
> Craig
>
> > On 2/20/06, Adam Winer <[EMAIL PROTECTED]> wrote:
> > > Weeellll.... if you implement StateHolder, this isn't an issue.
> > > The public no-arg constructor will be used, variable initializer
> > > expressions will run, etc.
> > >
> > > If you implement Serializable instead, then Craig's totally right -
> > > transient variables will not be re-initialized. You can deal with
> > > this by adding the log() method, or by providing an implementation
> > > of:
> > >
> > > private void readObject(ObjectInputStream in)
> > >
> > > ... which can re-initialize any transient values.
> > >
> > > I am *so* thankful that java.util.logging doesn't force any of
> > > this pain on its users.
> > >
> > > -- Adam
> > >
> > >
> > >
> > > On 2/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >
> > > > On 2/19/06, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > > > > 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?
> > > >
> > > > No, AIUI. When an object is deserialized, it does *not* execute the
> > > > variable initializer expressions. Since it was declared transient,
> there's
> > > > no state for that object to be restored.
> > > >
> > > > > 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].
> > > >
> > > > You can reduce that by one call by protecting only the conditional
> > > > expression, because if you get inside you know there's an object ...
> but
> > > > that means you are relying on the implicit contract between the log
> instance
> > > > variable and the log() method.
> > > >
> > > > > Cheers,
> > > > >
> > > > > Simon
> > > > >
> > > > >
> > > > Craig
> > > >
> > > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
