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:28:25 +0000 (UTC)
From: "Niclas Hedhman (JIRA)" <jira@apache.org>
To: dev@zest.apache.org
Message-ID: <JIRA.12913013.1447454680000.285408.1461202105436@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: quoted-printable


    [ https://issues.apache.org/jira/browse/ZEST-129?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D152510=
70#comment-15251070 ]=20

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

Spring documentation (at least in Spring 3.2) says the following little tid=
bit;

<quote>
Tip
The JSR-250 @PostConstruct and @PreDestroy annotations are generally consid=
ered best practice for receiving lifecycle callbacks in a modern Spring app=
lication. Using these annotations means that your beans are not coupled to =
Spring specific interfaces. For details see Section 5.9.6, =E2=80=9C@PostCo=
nstruct and @PreDestroy=E2=80=9D.

If you don't want to use the JSR-250 annotations but you are still looking =
to remove coupling consider the use of init-method and destroy-method objec=
t definition metadata.
</quote>

It is interesting that it helps decouple from Spring (which is just as hard=
 as decouple from Zest) interfaces.

> 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) invok=
ed after construction. We have ServiceActivation - with 2 initialize/destro=
y methods implemented by a mixin - and sort of referenced from the declarat=
ions 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, f=
rankly, a quite dated way of doing stuff.
> I would say we should add support for declaring @PostConstruct and @PreDe=
stroy on Mixins - and support for @PostConstruct on plain objects (instanti=
ated 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 beforeActiva=
tion 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 activati=
on logic across several composites - And there could be some potential of r=
eusing the Activator as a listener for UnitOfWork activation/passivation in=
stead of module activation/passivation. The afterPassivation could have som=
e 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)