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] [Created] (ZEST-129) Review the different activation/initialization/lifecycle methods
Date Fri, 13 Nov 2015 22:45:11 GMT
Niclas Hedhman created ZEST-129:

             Summary: 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;

    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
    The afterPassivation could have some usages in that context.

    So I think we should keep that concept for now.

This message was sent by Atlassian JIRA

View raw message