On 2/20/06, Simon Kitching <[EMAIL PROTECTED]> 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).
+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 :-).
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?
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).
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 :-).
Cheers,
Simon
Craig
