polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent SĂžlvsten <kent.soelvs...@gmail.com>
Subject Re: [Discuss] Object lifecycles...
Date Thu, 03 Dec 2015 13:42:09 GMT
I think the current lifecycle status is a mix of good and bad.

For the high-level parts (Application/Layer/Module we depend on Activation.

The typical lifecycle is (eg for application):

ApplicationInstance#activate() {
  "activators".beforeActivate
  *activateChildren*    
  "activators".afterActivate
}

....

ApplicationInstance#passivate() {
  "activators".beforePassivate
  *passivateChildren*
  "activators".afterPassivate.
}


On each level it is possible to add activators in the assembly.

The some goes partially for the module -> service/importedService case 
(where the activation of service/importedService may be made on module
startup or on first "usage").

So far so good.

But .....

ServiceInstance/ImportedServiceInstance is implementing Activation - but
the method seems to not be used at all (exception as a "marker
interface"). Instead the activators on a service are invoked directly
- which seems weird.

Den 03-12-2015 kl. 08:38 skrev Niclas Hedhman:
> Gang,
>
> 1. Should Initializable.initalize() be invoked on prototypeFor()?
Definitely not!

Currently Initializable#initialize() is invoked when the mixinInstance
is created.
This means that for servicecomposites we currently have

/- create service//
//- create mixins (and initialize() if necessary)//
//- "serviceactivators".beforeActivate//
//- .... no children to activate//
//- "serviceactivators".afterActivate   (this includes the
ServiceActivation)//
/
This sequence does not make sense, since it is inconsistent with the
other structural parent-child-relations
Worse, as you just discovered, it has the unpleasant side-effect of
invoking mixin#initialize in the "prototype-phase".

What would make sense in the grand scheme would be more like

/- create service//
//- create mixins (and initialize() if necessary)//
//- "serviceactivators".beforeActivate//
//- .... activate children (mixins) by invoking some (optional)
method//on the child (mixin)
//- "serviceactivators".afterActivate   (this includes the
ServiceActivation)//
///
and the same for destruction.

The challenge is that in some cases the lifecycle comes in pairs (mixin
on service, and possibly  on entities) - in other cases (mixin on
transient or value,  creation of objects) we only have the
initialization part.
I think it should be kept that way - finalize() is not a good idea.

This is nicely supported by the standard @PostConstruct/@PreDestroy
jdk-annotations - annotations that are widely used and understood.

I think we should support @PostConstruct in the following cases:

- declared directly on the method of a mixin - when used in a service
- declared directly on the method of a mixin - when used in a transient
- declared directly on the method of a mixin - when used in a value
- declared directly on the method of a mixin - when used in an Entity
- declared directly on the method of an imported service - if
instantiated by the serviceimporter
- declared directly on the method of an object - when created by an
ObjectFactory

I think we should support @PreDestroy in the following cases:
- declared directly on the method of a mixin - when used in a service
- declared directly on the method of a mixin - when used in an Entity
- declared directly on the method of an imported service - if
instantiated by the serviceimporter

These features should be able to replace all usages on
Initializable/Lifecycle - and probably almost all current usages of
Activators.
I think Activators should still be supported on services - but will
probably such a rare case, the syntactic sugar should be removed, to
keep the core simpler.

So .....
dump Initializable
dump Lifecycle
dump ServiceActivation
dump support for @Activators annotations  on a service - activators are
only possible by assembly.

Since mixins tend to be independent, i think the need for doing
something before/after all mixins will be rare.

There could be an argument for adding more domain-specific annotation
(@OnEntityCreation)
 - but i would rather like a way to extend the supported set of
annotations than putting those in the core.

/Kent



>
> At the moment, when prototypeFor() (and prototype() I guess) is called on
> TransientBuilder (probably ValueBuilder as well), the mixin's initialize()
> will be called.
> That means that the Composite is not really available (predictably) to the
> Mixin at this point.
>
> 2. Do we have a solid object lifecycle story at all??
>
> While writing this mail, I start to think that the object lifecycle model
> is severely flawed, and possibly not easily fixed here and there.
>
> I think we need to dig through the requirements from the ground up. I think
> that the Fragments and the Composite need to be separated.
>
> I also wonder if we can indeed utilize finalize(), to get pre/post
> semantics uniformly across all composite meta types... Does anyone have a
> very strong understanding of how finalize() works, and why it is said to be
> "bad" to use it in programs??
>
> What I would like to see is pairs of annotations with strong semantics,
> something like (maybe better names)
>
> @OnEntityCreation   // called on EntityBuilder.newInstance()
> @OnEntityDeletion   // called on UnitOfWork.remove()
>
> @OnCompositeConstruction  // called when in-memory instance created
> @OnCompositeDestruction    // called via finalize() or UnitOfWork teardown.
>
> @OnMixinCreation      // Called after Mixin constructor call.
> @OnMixinDestruction  // called via @OnCompositeDestruction
>
> I am not sure if we need to separate the prototype/prototypeFor creation
> from the instantiation of 'final' Mixin instance that goes into the
> Composite.
>
> And in the process "fix" the ServiceComposite story as well, i.e.
>
> @OnServiceActivation
> @OnServicePassivation
>
> And in the process get rid of the all the related interfaces;
> Initializable
> Lifecycle
> Activatable
> ServiceActivator
>
> and so on.
>
> Any thoughts?
>
>
> Cheers


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