[
https://issues.apache.org/jira/browse/ZEST-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niclas Hedhman updated ZEST-129:
--------------------------------
Description:
Kent wrote on mailing list;
{quote}
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.
{quote}
was:
Kent wrote on mailing list;
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.
> Review the different activation/initialization/lifecycle methods
> ----------------------------------------------------------------
>
> Key: ZEST-129
> URL: https://issues.apache.org/jira/browse/ZEST-129
> Project: Zest
> Issue Type: Bug
> Reporter: Niclas Hedhman
>
> Kent wrote on mailing list;
> {quote}
> 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.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
