Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
Date: Thu, 21 Apr 2016 01:24:25 +0000 (UTC)
From: "Niclas Hedhman (JIRA)" <jira@apache.org>
To: dev@zest.apache.org
Message-ID: <JIRA.12913013.1447454680000.285372.1461201865599@Atlassian.JIRA>
In-Reply-To: <JIRA.12913013.1447454680000@Atlassian.JIRA>
References: <JIRA.12913013.1447454680000@Atlassian.JIRA>
 <JIRA.12913013.1447454680116@arcas>
Subject: [jira] [Commented] (ZEST-129) Review the different
 activation/initialization/lifecycle methods
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/ZEST-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15251065#comment-15251065 ] 

Niclas Hedhman commented on ZEST-129:
-------------------------------------

Interesting text in the jaavdoc for @PostConstruct

<quote>
The PostConstruct annotation is used on a method that needs to be executed after dependency injection is done to perform any initialization. This method MUST be invoked before the class is put into service. This annotation MUST be supported on all classes that support dependency injection. The method annotated with PostConstruct MUST be invoked even if the class does not request any resources to be injected. Only one method can be annotated with this annotation. The method on which the PostConstruct annotation is applied MUST fulfill all of the following criteria:
</quote>

So, every framework/platform that supports dependency injection MUST support this. (else what?? Not Java compatible?)

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