so here's the scenario.
entity Type has a 1:M relation to Op and this goes into
the value object
/**
* @ejb:interface-method
* @ejb:relation
* name="op-type"
* role-name="one-type-has-many-op"
* target-ejb="Op"
* target-role-name="many-op-one-type"
* target-cascade-delete="yes"
* @ejb:transaction type="SUPPORTS"
* @ejb:value-object
* match="*"
* type="Set"
* relation="external"
* aggregate="test.shared.OpValue"
* aggregate-name="OpValue"
* members="test.shared.OpLocal"
* members-name="Op"
* @jboss:target-relation
* fk-column="TYPE_ID"
* related-pk-field="id"
*/
the following code snippet won't work as expected
set.add(op1);
set.add(op2);
set.add(op3);
type.addOps(set);
type.getTypeValue(); // force creation of the value object.
// by
doing TypeCMP.java will
// force
the value object
// to
populate it's private
// Op
Set with three elements.
set2.add(op2);
type.removeOps(set2);
type.getTypeValue(); // here TypeCMP.java will notice
// the
value object already exists so
// it
doesn't create a new one.
// so,
the value object's private Op Set
// still
contains three elements, not two.
i'll submit a patch.
Logged In: YES
user_id=360347
I've checked this against the current code in CVS and this
bug doesn't seems to be valid. There is no references
mantained to the VO in the getter method -- it's
reconstructed every time it's requested.
Anyway, I've just removed the last "if" on the VO getter
code. If for any reason it was keeping references, it
shouldn't be doing it anymore.
I'm marking this item as "Fixed" but "Pending" as I'm not
sure it was valid from the beginning.