myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: svn commit: r378805 - /myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/application/ApplicationFactoryImpl.java
Date Tue, 21 Feb 2006 05:16:29 GMT
Hi Craig,

On Sun, 2006-02-19 at 17:56 -0800, Craig McClanahan wrote:
> 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(). 
> 
> 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("...");
>     }


I've checked, and all the standard commons-logging Log adapter
implementations *are* Serializable (Log4J, JDK14, LogKit, Simple, NoOp).
So AIUI there is no need to declare Log members transient; they should
get serialized and deserialized along with the owning class fine. No
log() method would then be required or any other special handling (other
than ensuring the member is NOT static!).

Serializable support for Log implementations appears to have been
implemented in the JCL 1.0.4 release, ie in JCL 1.0.3 and earlier the
Log implementations were not Serializable. Craig: maybe you weren't
aware of this change?

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?

Cheers,

Simon


Mime
View raw message