Mailing-List: contact dev-help@polygene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@polygene.apache.org
Date: Sun, 26 Feb 2017 13:07:45 +0000 (UTC)
From: "Paul Merlin (JIRA)" <jira@apache.org>
To: dev@polygene.apache.org
Message-ID: <JIRA.12913013.1447454680000.276.1488114465249@Atlassian.JIRA>
In-Reply-To: <JIRA.12913013.1447454680000@Atlassian.JIRA>
References: <JIRA.12913013.1447454680000@Atlassian.JIRA> <JIRA.12913013.1447454680116@jira-lw-us.apache.org>
Subject: [jira] [Commented] (POLYGENE-129) @PreDestroy and @PostConstruct in
 lieu of initializable and service activation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Sun, 26 Feb 2017 13:07:53 -0000


    [ https://issues.apache.org/jira/browse/POLYGENE-129?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D15=
884741#comment-15884741 ]=20

Paul Merlin commented on POLYGENE-129:
--------------------------------------

{{Initializable}} has a single {{initialize()}} method, called on fragment =
instantiation ; the {{@PostConstruct}}=C2=A0semantic apply well here.

{{Lifecycle}} has {{create()}} and {{remove()}} methods, called respectivel=
y  on *entities* creation and removal from UoW ; {{@PostConstruct}} and {{@=
PreDestroy}} semantic apply well here too.

{{@PreDestroy}} on a fragment would be ignored if not part of an entity

{{Activation}} has {{activate()}} and {{passivate()}} methods ; the semanti=
c here is that a passivated service can be reactivated ; {{@PreDestroy}} so=
unds a bit aggressive in this context and {{@PostConstruct}} doesn't make s=
ense for re-activation that happens on an existing instance.

We should definitely replace {{Lifecycle}}=C2=A0and {{Initializable}} with =
these annotations.
I'm not sure about {{Activation}}, mostly because of semantics, any thought=
s?


> @PreDestroy and @PostConstruct in lieu of initializable and service activ=
ation=20
> -------------------------------------------------------------------------=
------
>
>                 Key: POLYGENE-129
>                 URL: https://issues.apache.org/jira/browse/POLYGENE-129
>             Project: Polygene
>          Issue Type: Improvement
>            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.15#6346)