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 <[email protected]> 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 <[email protected] > > > > 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
