On 6 February 2013 07:28, Adam Howard <[email protected]> wrote: > Thanks Dan. Agree with all your comments and suggestions. > > One more hiccup I ran into was the modeling of Schedule[1]. A schedule has > a List of CarrierMovement but the list is immutable by being passed into > the Schedule constructor, having no setter or addTo/removeFrom methods, and > the getter returns a Collections.unmodifiableList wrapping the list. >
Presumably you also modelling this as an entity? Although theoretically possible, it wouldn't be rather unusual for a value to reference a list of entities. > > I have a repository for finding Voyages (which hold a reference to a > Schedule.) Can you just explain this to me... I don't think it's correct for a repo to hold a reference to an entity. > When I run the find action in the Wicket viewer I get an > exception: > > java.lang.UnsupportedOperationException > at > java.util.Collections$UnmodifiableCollection.remove(Collections.java:1019) > at > > org.apache.isis.core.progmodel.facets.collections.modify.CollectionRemoveFromFacetViaAccessor.remove(CollectionRemoveFromFacetViaAccessor.java:76) > at > > org.apache.isis.core.runtime.transaction.facets.CollectionRemoveFromFacetWrapTransaction.remove(CollectionRemoveFromFacetWrapTransaction.java:50) > at > > org.apache.isis.core.metamodel.specloader.specimpl.OneToManyAssociationImpl.removeElement(OneToManyAssociationImpl.java:180) > at > > org.apache.isis.core.runtime.memento.Memento.updateOneToManyAssociation(Memento.java:366) > at > org.apache.isis.core.runtime.memento.Memento.updateField(Memento.java:337) > ... > > By debugging, I see that my firstMatch query finds the correct Voyage with > the Schedule and CarrierMovements intact. But the above code tries to > iterate over the CarrierMovements collection and remove the elements > throwing the above exception. > > Is there something I can do to keep the immutability constraints in place? > > This is perhaps caused by that repo reference the entity, but even if you got rid of that I think you might still see this. What's going on here - I think - is that Wicket is serializing this reference (as it always does) at the end of the interaction, and attempting to deserialize it at the beginning of the next. So this is an infrastructure-level rehydration and mutation of state, akin to using an ORM. Could you paste the code for your ported version of Schedule so I can study it some more? Thx Dan > Thanks. > -- > Adam > > [1]: > > https://github.com/joolu/ddd-sample/blob/master/src/main/java/se/citerus/dddsample/domain/model/voyage/Schedule.java > > >
