Mailing-List: contact user-help@shiro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@shiro.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4E81BCBD.8060909@metaphysis.net>
Date: Tue, 27 Sep 2011 14:08:29 +0200
From: =?UTF-8?B?QW5kcmVhcyBQcmllw58=?= <ap@metaphysis.net>
Organization: metaphysis
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.21) Gecko/20110901 Lightning/1.0b2 Thunderbird/3.1.13
MIME-Version: 1.0
To: user@shiro.apache.org
Subject: Re: SimpleSession serialization - fields written twice
References: <1316819991340-6826037.post@n2.nabble.com>
 <CAETPiXZGGruWCSyTnUFFtkzmaQWUWcUNBuctP-9_ZeQuRFPY2A@mail.gmail.com>
In-Reply-To: 
 <CAETPiXZGGruWCSyTnUFFtkzmaQWUWcUNBuctP-9_ZeQuRFPY2A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Hi Les,

I just had a look at the chapter about serialization in "Effective Java"
to see what the rationale is about. As you mentioned
defaultWriteObject() should be used, but the example in the book also
clearly shows that all fields with customized serialization must not be
serializable for the default mechanism executed by defaultWriteObject(),
so they should normally be transient.

The problem with shiros SimpleSession is that the fields are _not_
marked transient and are therefore in fact written out twice.

The solution should not be to remove defaultWriteObject() but to mark
all the fields transient.

(Looked at source checked out on 2011-09-06.)


HTH,

Andreas


On 25.09.2011 20:02, Les Hazlewood wrote:
> Wrt Java serialization, in.defaultReadObject() and
> out.defaultWriteObject() should pretty much always be called as the
> very first line in the readObject and writeObject implementations,
> respectively.
> 
> Josh Bloch covers this in his Effective Java book (2nd edition), page
> 299.  While too lengthy to repeat here, it boils down to ensuring the
> class functions properly even as future modifications occur, as well
> as for real security reasons.
> 
> I can't comment as to whether or not your solution is fine for your
> needs, but this explains the reason why they are in Shiro's current
> implementation.
> 
> Cheers,
> 
> Les
> 
> P.S. As an aside if anyone finds this next comment helpful, there are
> two Java books that I have at my desk that are indispensable to me:
> Josh Bloch's Effective Java (2nd edition) and Brian Goetz (et. al.)'s
> Java Concurrency in Practice.
>