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: Bug in Assembly??
Date Fri, 13 Nov 2015 19:40:03 GMT
I agree that the mix and match between composites and mixin declarations
of the same @Activators concept might lead to confusion - not a good idea.

But a whole new thought .... aren't we reinventing the wheel here.

We have Initializable interface - declaring a method (on the mixin)
invoked after construction
We have ServiceActivation - with 2 initialize/destroy methods
implemented by a mixin - and sort of referenced from the declarations on
the composites
We have @Activators -- that may be declared on the composite - with wide
flexibility implementation-wise.

But .... the JDK already has @PostConstruct and @PreDestroy annotations.
These were originally JEE stuff, but have been in the JDK for several years.
And it is the same thing! Keeping a special Initializable interface is,
frankly, a quite dated way of doing stuff.

I would say we should add support for declaring @PostConstruct and
@PreDestroy on Mixins - and support for @PostConstruct on plain objects
(instantiated by ObjectFactory).
And simply remove (or just deprecate) Initializable and
ServiceActivation alltogether.

I am more uncertain whether the @Activators should be kept or not.
 On one hand I cannot find a single usage in the whole codebase using
beforeActivation and afterPassivation - so not sure anyone would miss
those features.
On the other hand it might be handy to be able to reuse the same
activation logic across several composites
 - And there could be some potential of reusing the Activator as a
listener for UnitOfWork activation/passivation instead of module
The afterPassivation could have some usages in that context.

So I think we should keep that concept for now.


Den 12-11-2015 kl. 16:36 skrev Niclas Hedhman:
> Kent,
> I think you are right that we can't have this on Objects and Values, as you
> point out, we don't control the destruction,
> The problem of supporting ServiceActivator on the composites together with
> Mixins at the same time is that there is a 'precedence' problem; If several
> Mixins implements it, then one of them will be called via the invocation
> stack whereas the others won't. It makes an imbalanced execution
> expectation on the Mixins. Maybe not major, but a bit odd.
> Niclas
> On Thu, Nov 12, 2015 at 6:19 PM, Kent Sølvsten <kent.soelvsten@gmail.com>
> wrote:
>> What about something like
>> (1) @Activators can be declared either on composites or mixins (today
>> only on composites)
>> (2) As as side-effect, both a composite or a mixin may implements
>> ServiceActivation with the desired effect (just syntactical sugar around
>> @Activators)
>> (3) Initializable could be changed to be syntactical sugar around
>> @Activators - so may be used both on composites or mixins
>> Open question: Can ObjectFactory#newObject in any meaningful way be
>> changed to use @Activators instead of Initializable?
>> I guess not, since the destruction methods would never be invoked, thus
>> potentially leading to confusion.
>> /Kent
>> Den 12-11-2015 kl. 09:52 skrev Paul Merlin:
>>> Niclas Hedhman a écrit :
>>>> Ok, naming might be an issue, but there is a deeper one.
>>>> Is it correct that the ServiceActivation.activateService() is called on
>> the
>>>> ServiceComposite and not each Mixin implementing it??
>>> Correct.
>>>> Just like Initializable was changed to be called on the Mixin, instead
>> of
>>>> the Composite, I think a similar lifecycle method pair is needed for
>>>> Services. Otherwise it is really hard to make very generic Mixins that
>>>> works independently of the whole ServiceComposite.
>>>> Lifecycle is another interface with these semantics for entities.
>>> Makes sense. Could you please capture that in a JIRA?
>>> Cheers
>>> /Paul

View raw message