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

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

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

{{Lifecycle}} has {{create()}} and {{remove()}} methods, called respectively  
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 semantic 
here is that a passivated service can be reactivated ; {{@PreDestroy}} sounds a 
bit aggressive in this context and {{@PostConstruct}} doesn't make sense for 
re-activation that happens on an existing instance.

We should definitely replace {{Lifecycle}} and {{Initializable}} with these 
annotations.
I'm not sure about {{Activation}}, mostly because of semantics, any thoughts?


> @PreDestroy and @PostConstruct in lieu of initializable and service 
> activation 
> -------------------------------------------------------------------------------
>
>                 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) 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.15#6346)

Reply via email to