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 >>> >> >
