polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Visibility, again...
Date Sun, 28 May 2017 08:50:17 GMT
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.



On Sun, May 28, 2017 at 1:45 PM, Niclas Hedhman <niclas@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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message