More info on this; So, the reason for the failure in the test is due to the serialize/deserialize of Values that happens on creation. This is not the way it should be handled, and Marc's original code may not be incorrect.
It boils back to that cloning is hard, and Kent took the easiest approach, albeit an incorrect one. Now, the solution can be; 1. Record the actions on the ValueBuilder instead of settings of state, then the replay of those set actions are used to build the state on a new ValueInstance each time. This is a straight-forward approach with a wrapper around the builder. 2. A more interesting case would be to introduce a delta inside the ValueInstance. So after the first ValueInstance is built, any changes are recorded as deltas and the 'primary' state (the first value instance) is shared across all value instances that was built using the same builder. This could save quite a bit of memory if values has many properties and only small variants. 3. Prototyping support is removed. I am leaning towards 3. myself at the moment, to reduce scope and get nearer 2.0 -- Niclas On Sun, Jun 24, 2012 at 3:19 PM, Niclas Hedhman <[email protected]> wrote: > FYI, > IF I also add LocationEntity and VoyageEntity to the Domain Layer, > with Visibility.module, the tests pass. But not sure if that is > correct design. > > On Sun, Jun 24, 2012 at 3:16 PM, Niclas Hedhman <[email protected]> wrote: >> I took a look at the test failure in DCI sample B. >> >> The CarrierMovement in layer "DomainLayer" VALUE has a Property to a >> Location, but the only Location defined is a LocationEntity sitting in >> a higher layer ("ContextLayer"). >> >> Marc!!! >> How is this intended to work? >> CarrierMovement is not allowed to access higher layers like that. It >> might have worked previously due to the creation of the UnitOfWork >> happening in the ContextLayer, but since the ValueBuilder was changed >> to support prototyping, this is surfacing as a probable bug in the >> sample. >> >> >> Cheers >> -- >> Niclas Hedhman, Software Developer >> http://www.qi4j.org - New Energy for Java >> >> I live here; http://tinyurl.com/3xugrbk >> I work here; http://tinyurl.com/6a2pl4j >> I relax here; http://tinyurl.com/2cgsug > > > > -- > Niclas Hedhman, Software Developer > http://www.qi4j.org - New Energy for Java > > I live here; http://tinyurl.com/3xugrbk > I work here; http://tinyurl.com/6a2pl4j > I relax here; http://tinyurl.com/2cgsug -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/6a2pl4j I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
