Oops, I wasn't very clear there. I meant that a Voyage contains a Schedule not that the VoyageRepository contains a Schedule.
Voyage ---> Schedule ---> List<CarrierMovement> I've pushed the project up to GitHub[1]. You can clone it, build and run the jetty-console.war file. Auth is bypass so enter whatever. Run the Voyages > Find All action to see the stack trace. >From your description of what Wicket is doing, however, it sounds like this may not be possible. Another thing that might get in the way of this style of immutability is the pattern of calling newTransientInstance() in a repository then calling some setters and either persisting or returning the object. In this case Schedule has a 1-arg constructor that takes a List<CarrierMovement> and there is no setter to change the List at a later time. In my Fixtures I am able to call getContainer().persistIfNotAlready(new Schedule...) and the objects are persisted. Maybe that will work in the Repository as well. Thanks. -- Adam [1]: https://github.com/adamhoward/onaboat On Wed, Feb 6, 2013 at 1:51 AM, Dan Haywood <[email protected]>wrote: > 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 > > > > > > >
