polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: What is the meaning of @Structure anyway?
Date Sat, 02 Dec 2017 04:09:18 GMT
Of course you are just babbling... ;-D

Originally the separation was primarily between @Structure and @Invocation,
where the former was a static injection and the latter was something that
potentially changed on ever method. @Service was entering the stage much
later, as we for quite a while couldn't place a good definition on what a
service is, since we were highly corrupted by notions from Avalon and later
Spring, where services had "singleton", "per request" and "session"

Nonetheless... The @Structure injections takes the structure context (i.e.
Module) of the target, where as a @Service injection still has its
structure contrext from where it was declared. Furthermore (and I don't
recall the details here), a UnitOfWork which is created "high up" will
adopt the structure context further "down", and when deserialization takes
place, the ES even further down, will get the "visibility view" of the
"middle", if that makes sense. It is the separation of UnitOfWorkInstance
and ModuleUnitOfWork that deals with this, something that was a painful
learning experience when the first non-trivial app was created. The fact
that the QueryBuilder is passed to UnitOfWork for creation of a Query, is
part of resolving this "structural" problem, as UnitOfWork has enough
information about type visibility (I think).

You are right that there is not a good enough definition of "@Structure",
and because of that, can't allow user-defined types in @Structure scope.
And until then, I am not keen on providing a "global visibility" mechanism
for users, as in general it will be abused. Instead, IF you really need to
find types all over the place, it is somewhat possible to do via the
Polygene SPI and the TypeLookup, but not simple by definition so to speak.

Makes sense?


On Thu, Nov 30, 2017 at 3:08 PM, Kent SĂžlvsten <kent.soelvsten@gmail.com>

> In another thread was written:
> > > I think there is no need for a "LoggerFactory" (I could be wrong), but
> > > that
> > > > we simply introduce a few types to be injectable in @Structure scope,
> > > each
> > > > dedicated for the purpose, instead of the generic "log" that is
> > prevalent
> > > > in logging systems deriving from Log4j.
> > >
> > >
> > > Very much agree that we should avoid another Factory. But I actually
> > would
> > > prefer the types to @Service instead of @Structure - more like eg.
> > > EntityStores.
> > >
> > The reason I wanted @Structure is to capture the caller's module, rather
> > than the service's. And that the implementation ends up being a @Service,
> > just like UnitOfWork ends up delegating to services.
> > But, when thinking about it, UnitOfWorkFactory is now optionally a
> Service.
> > So, I should check how the @Structure semantics are handle or if there
> is a
> > design flaw, and if it is done correctly, perhaps use the same mechanism.
> It dawned on me, that I may not have understood the exact meaning of the
> @Structure.
> What is the meaning of using @Structure as opposed to @Service.
> When should a "singleton" be a service, when should it be a structure?
> So far I have more or less thought of the Structure-stuff as
> "part-of-the-applicationstructure".
> Some of them (application/layer/module) ARE the application-structure
> itself.
> Others are service-like constructs, which are part of the modules (and
> actually implemented by the module itself).
> But should I just focus on "part-of-the-calling-module" instead?
> Maybe a "thing" injected with @Structure should simply be considered as
> "belongs-to-the-module-using-it" regardless of how it is declared ....
> Meaning that if we had an application structure like:
> Module1: Service1, Service3a
> Module2: Service2, Service3b
> Module3: Structure
> with Service1 and Service2 depending on the Structure, and the Structure
> depending on "Service3" (with instances in both modules) then the
> dependency graph would actually be:
> Service1 -> Structure -> Service 3a
> Service2 -> Structure -> Service3b
> I have been missing a feature such as
> "declare-a-service-as-present-in-all-modules".
> Maybe this interpretation of the meaning of @Structure is it?
> So maybe we are actually just missing a feature likke adding a "Structure"
> to a ModuleAssembly.
> With that focus, we could think of all the existing "default" structures
> (ValueBuilderFactory, UOWFactory ....) as the application automatically
> having a "secret" module with these structure-things - and that *could*
> hint at a way of customizing these things?
> Am i making sense or just babblling here?
> /Kent

Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

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