polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ZEST-129) Review the different activation/initialization/lifecycle methods
Date Fri, 13 Nov 2015 22:48:10 GMT

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

Mime
View raw message