The Subject's readObject can get called in one of two scenarios: When a
Subject is deserialized and if a SecureSet is deserialized (because of
the reference to the containing Subject in SecureSet). In the latter
case, accessing the contents of inputPrincs before deserialization is
complete causes NPEs (even in valid cases) because the Subject is being
deserialized before the SecureSet - chicken/egg thing. I believe I
could add that simple null check for the object itself back in without
breaking things, but SecureSet's readObject is now checking the
contents. I'll put it back in and re-run the tests to make sure it'll work.
--Jamil
On 06/12/2014 02:40 AM, Wang Weijun wrote:
Why
@@ -968,14 +963,10 @@
readOnly = gf.get("readOnly", false);
Set<Principal> inputPrincs = (Set<Principal>)gf.get("principals", null);
// Rewrap the principals into a SecureSet
- if (inputPrincs == null) {
- throw new NullPointerException
- (ResourcesMgr.getString("invalid.null.input.s."));
- }
try {
principals = Collections.synchronizedSet(new SecureSet<Principal>
(this, PRINCIPAL_SET, inputPrincs));
} catch (NullPointerException npe) {
// Sometimes people deserialize the principals set only.
It looks you accept principals being null in serialized form. (Of course, the
new object contains a non-null one).
Thanks
Max
On Jun 12, 2014, at 17:26, Jamil Nimeh <jamil.j.ni...@oracle.com> wrote:
Next round: This one incorporates Weijun's comments and cleans up a couple
warnings in the test code.
http://cr.openjdk.java.net/~weijun/8015081/webrev.05/
--Jamil
