polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Bug in Assembly??
Date Fri, 13 Nov 2015 22:48:17 GMT
You make good points... So that became a Jira ticket ;-)

https://issues.apache.org/jira/browse/ZEST-129

On Sat, Nov 14, 2015 at 3:40 AM, Kent Sølvsten <kent.soelvsten@gmail.com>
wrote:

> 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
> activation/passivation.
> The afterPassivation could have some usages in that context.
>
> So I think we should keep that concept for now.
>
> /Kent
>
> 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
> >>>
> >>
> >
>
>


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

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