Originally posted by Ryan Wong:
From spec 10.3.8, you will actually get a IllegalStateException if you assign a null in a cmr relation that takes in collection as a field.
Can you quote where exactly in 10.3.8 you may read that the Container will throw an IllegalStateException? I haven't found it.
And following the specs, it seems that nothing will happen, but I am not sure, that why I posted this question.
From specs 10.3.7.3:
Before change:
Collection b1 = a1.getB();
Collection b2 = a2.getB();
B b11, b12, ... , b1n; // members of b1
B b21, b22, ... , b2m; // members of b2
Change:
a1.setB(a2.getB());
Expected result:
(a2.getB().isEmpty()) &&
(b2.isEmpty()) &&
(b1 == a1.getB()) &&
(b2 == a2.getB()) &&
(a1.getB().contains(b21)) &&
(a1.getB().contains(b22)) && ... &&
(a1.getB().contains(b2m)) &&
(b11.getA() == null) &&
(b12.getA() == null) && ... &&
(b1n.getA() == null) &&
(a1.isIdentical(b21.getA())) &&
(a1.isIdentical(b22.getA())) && ...&&
(a1.isIdentical(b2m.getA()))
[That's all right so far...]
Change:
b2m.setA(b1n.getA());
Expected result:
(b1.contains(b11)) &&
(b1.contains(b12)) && ... &&
(b1.contains(b1n)) &&
(b1.contains(b2m)) && ----> This is where the magic happens. If you look at the expected results during the first change, (b1n.getA() == null), therefore the above change is equivalent to say: b2m.setA(null);
But as you can see, b1.contains(b2m) is still true, result of the first change, therefore nothing had happened.
(b2.contains(b21)) &&
(b2.contains(b22)) && ... &&
(b2.contains(b2m_1)) &&
(a1.isIdentical(b11.getA())) &&
(a1.isIdentical(b12.getA())) && ... &&
(a1.isIdentical(b1n.getA())) &&
(a2.isIdentical(b21.getA())) &&
(a2.isIdentical(b22.getA())) && ... &&
(a2.isIdentical(b2m_1.getA())) &&
(a1.isIdentical(b2m.getA()))
The only cases when the Container throws an IllegalStateException, in 10.3.8. is when the client tries to modified a CMR-valued field using the Collection API or java.util.Iterator in a transaction context other than the one that originally generated the cmr-valued field.