Yes +1 for 1.0.4. Thanks for explaining all of this.
On 2/21/06, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> +1 for dependency on commons-logging 1.0.4
>
> BTW, Stan (Silvert), how do you solve these logging issues in JBoss?
> AFAIK, JBoss has only one central log4j configuration. However, is
> there a way to config logging per eapp or webapp? If yes, how does
> JBoss address those issues with shared classes?
>
> Thanks,
> Manfred
>
>
>
> On 2/21/06, Simon Kitching <[EMAIL PROTECTED]> wrote:
> > On Mon, 2006-02-20 at 21:47 -0800, Craig McClanahan wrote:
> > > No, I was not aware of that change ... but does it actually work?
> > > Declaring something Serializable is not by itself sufficient if there
> > > are transient variables inside the implementation. (On a separate
> > > thread on commons-dev, I recommended that there be unit tests to
> > > validate this behavior: use a Log instance, serialize it, deserialize
> > > it, and use it some more).
> >
> > I believe Serializable is correctly implemented for all standard
> > adapters except possibly AvalonLog [will follow that up on commons-dev].
> > The deserialized objects correctly locate a fresh "underlying" log
> > object to forward calls to.
> >
> > Yes there need to be unit tests for this; I'll look for them and add
> > some if not already present.
> >
> > >
> > >
> > > The 1.0.4 release occurred around June 2004 so perhaps there
> > > are a few
> > > containers out there capable of running MyFaces but which are
> > > still on
> > > JCL 1.0.3. In addition there might be a few custom Log
> > > adapters around
> > > which *might* not implement Serializable.
> > >
> > > However in view of the complicated/ugly workaround for
> > > non-serializable
> > > Log implementations, it seems ok to me for MyFaces to just
> > > declare a
> > > dependency on JCL 1.0.4. If people don't comply then there is
> > > a very
> > > obvious "NotSerializableException: logAdapterClassName"
> > > message
> > > generated. The fix is then to upgrade to 1.0.4 (which is
> > > binary
> > > compatible with earlier releases) or a later release.
> > >
> > > Comments/Opinions?
> > >
> > > +1 on declaring a dependency on Commons Logging 1.0.4 ... anything
> > > prior to that is just asking for trouble. I use 1.0.4 exclusively for
> > > eveything that has a C-L dependency ... works fine, lasts a long
> > > time :-).
> >
> > So the conclusion seems to be that if/when using commons-logging in
> > MyFaces, use:
> > private Log foo = LogFactory.getLog("foo");
> > everywhere except in short-lived and frequently-created objects. In
> > those cases, either call LogFactory.getLog as needed or have some
> > longer-lived object store the Log object.
> >
> > For StateHolder classes, things "just work"; the logger isn't saved in
> > saveState; it gets recreated in the new component and that works.
> >
> > For Serializable classes, the Log object handles its own serialization
> > correctly. No need for "transient", no need for any other special hacks.
> >
> > MyFaces does need to declare a dependency on commons-logging 1.0.4 (not
> > earlier versions) in order for things to work this simply. Release 1.0.4
> > was in June 2004.
> >
> > Do NOT use "static Log" anywhere.
> >
> > Is this all ok?
> >
> > Cheers,
> >
> > Simon
> >
> >
>
