Ok, I have figured out why I ended up writing the above. There is a small inconsistency when it comes to Configuration.
ConfigurationComposites as they are formally called, is a subtype of EntityComposite that is tied to a ServiceComposite, and can be pre-populated with values from other sources, such as properties files. Now, if I register the ConfigurationComposite in Config Module/Layer, the ConfigurationMixin will use the Module of the ServiceComposite to locate deserializer when reading those external files. I think the consistent behavior should be that the Deserializer visible from the module of the ConfigurationComposite should be used. WDYT? Niclas On Sun, May 28, 2017 at 1:45 PM, Niclas Hedhman <nic...@hedhman.org> wrote: > Hi, > > ( If someone wants low-hanging fruit; Take the information below, and > rewrite it as documentation in markdown, under some internal-ish page. Or, > extract what the user really need to know and check that we have that > documented already or add it.) > > I am getting more and more uncertain on how the Visibility rules work. > This mail is writing my notes trying to figure out what actually happens, > and whether that is semantically correct. > > Let's say we have; > > Connectivity Layer > MemoryEntityStore > Restlet does a newUnitOfWork() > > Service Layer > FileEntityStore > DomainService doing uow.get( DomainEntity.class, "123" ) > > Domain Layer > JdbmEntityStore visibiliy application > DomainEntity > > Infrastructure Layer > LevelDBEntityStore > > And all of them have the DefaultUnitOfWorkAssembler in effect. > > > So, from which EnittyStore will the entity be read from? > > > Connectivity Layer ==?, the Restlet would have a module local > UnitOfWorkFactory which will create a UnitOfWorkInstance with "Connectivity > Layer" as Module argument. It will also create a ModuleUnitOfWork as a > Transient and therefor receive ModuleDescriptor for Connectivity Layer. > > > Service Layer ==> The DomainService will do call its UnitOfWorkFactory, > which will "find" the UnitOfWorkInstance from above (with the Connectivity > Layer module in it) and then instantiate a new ModuleUnitOfWork, which will > have the ModuleDescriptor of Service Layer > > > Domain and Infrastructure Layers ==> are totally passive. > > > So what happens at uow.get() in DomainService? > > EntityDescriptor for DomainEntity is looked up inside ModuleUnitOfWork in > Service Layer, useing the module in Service Layer as visibility argument. > I.e. the DomainEntity must be Visibility.application. > > Then UnitOfWorkInstance.get() is called, with identity, potentialModels > and the ModuelUnitOfWork as arguments. It loops through the potential > models, takes the Module in these, creates a EnityStoreUnitOfWork with that > EntityStore and tries to load the state. If successful create a > EntityInstance with this; > > model = (EntityModel) entityState.entityDescriptor(); > > entityInstance = new EntityInstance( uow, model, entityState ); > > > where uow is the ModuleUnitOfWork, i.e. from the module in the Service > Layer and the model containing a Module of potentialModel > selected/successful. > > > So, my conclusion is; it seems that the Entity Store that is visible to > the DomainEntity will be used... And that is what I think has been the > intention all the while since back in 2007/2008 somewhere when the > Visibility design was utterly flawed in the first iteration of Qi4j (the > above would require the Restlet to see everything). > > > > > -- > Niclas Hedhman, Software Developer > http://polygene.apache.org - New Energy for Java > -- Niclas Hedhman, Software Developer http://polygene.apache.org - New Energy for Java
