Perhaps a history lesson is in order; Originally, the Module of the UnitOfWork creation defined the visibility. That was a serious design flaw in the early days. After that, there are 2 parts of a UnitOfWork, the guy that deals with the state and a wrapper that deals with visibility. Each time a Module.currentUnitOfWork() is called, the wrapper of that Module is placed around the underlying UoW. So, visibility for the UoW changes as the call trickle down through the layers.
So, for the DCI sample, the entity are high up and have visibility to values in lower layers. However, those values has a reference to entities. This should be Ok, as long as access only happens in the ContextLayer, which it seems. So, I think there are no actual problems in the Sample. The problem is related to the dereferencing of Entity during Value creation (wrong module is engaged, i,e module.currentModule() is not the right access at that point.) Cheers Niclas On Sun, Jun 24, 2012 at 10:18 PM, marcgrue <[email protected]> wrote: > > Niclas Hedhman wrote >> >> 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. >> > > Hi Niclas, Kent and Paul - first, thanks for looking at and updating my > dci-cargo samples!!! I've been absorbed by Scala and functional programming > so I'm a bit far from qi4j/java and the dci-cargo project these days... > > I think I thought back then that having the DATA-Structure module > visibilityIn "application" allowed the CarrierMovement to reference the > Location within LocationEntity in the CONTEXT-RoleMapCandidates module. But > maybe that shouldn't have worked? > > My intention was generally that no resource should have any dependencies > "upwards", and I must admit that I cheated a bit (and only there, I > promise!) by having the entity files within the data directory, but > /assembling/ them in the ContextLayer! The dependencies looked correct and > good at compile time but at runtime the entities within the DataLayer were > actually belonging to the ContextLayer. You can of course see all this in > the assembly, but it's kind of a hack that goes against the intentions and > that won't show up if you analyze module dependencies. I don't know if/how > that could be avoided. Would be cool if the type system or "something" could > somehow prevent this situation at compile time - but that's opening another > chapter, I guess. > > Another simpler option is of course to move the entity files up into the > context directory, but then it's not that beautiful anymore... :-| Maybe you > can find a more clean/correct way of organizing the assembly? > > Cheers, > Marc > > > > -- > View this message in context: > http://qi4j-dev.23929.n6.nabble.com/Test-Failure-in-DCI-sample-tp6925p6931.html > Sent from the Qi4j-dev mailing list archive at Nabble.com. > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev -- 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
