[ 
http://team.ops4j.org/browse/QI-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17401#comment-17401
 ] 

Niclas Hedhman commented on QI-364:
-----------------------------------

Suggestion 2 (perhaps a different concept)


Introduce annotations for activation activity on the Mixin methods.


{code:java}
@Retention( RUNTIME )
@Target( METHOD )
public @interface Activation
{}


@Retention( RUNTIME )
@Target( METHOD )
public @interface Deactivation
{}
{code}

which can be placed on any method with void return type and only Qi4j 
resolvable method arguments, i.e. annotated with @Service, @Structure and so 
forth.


This suggestion is to me a different thing. It is about initialization of the 
mixin, and can be confusing if it is only applicable to a mixin IF and ONLY IF 
the mixin is part of a Service. Therefor, I don't think this is any good, 
although it looks neat.

However, if we do;

{code:java}
public class MyMixin 
    implements .... 
{

   @Activation
   public void myActivationMethod( @Structure Module module )
   {
   }

   @Activation
   public void myOtherActivationMethod( @Service brother )
   {
   }
}
{code}

the issue surface of "What is the order of invocation?". Although I think the 
Reflection API returns the methods in declaration order, I am not sure if it is 
explicitly required according to the Java Language Spec. Another aspect is that 
people often move methods around, and that could break functionality if we 
introduced this. Not good.


                
> Decoupling Service Activators
> -----------------------------
>
>                 Key: QI-364
>                 URL: http://team.ops4j.org/browse/QI-364
>             Project: Qi4j
>          Issue Type: New Feature
>            Reporter: Niclas Hedhman
>            Priority: Blocker
>             Fix For: 2.0 - Reductionism
>
>
> In 1.x, Activatable was used to get Services up and running. However, I feel 
> that the concepts are mixed up in a bad way, since Activatable initially 
> relied on that the Activatable method was exposed like any other method, and 
> that there could only be one. Later, we added that any Mixin that got 
> instantiated, would have its Activatable methods called. But, a pure Mixin 
> for only the purpose of starting up the service couldn't really be supported.
> Further, internally in Qi4j Runtime, there is an Activation mechanism in 
> place;
>   * User "activate" the application.
>   * The Application activates the Layers.
>   * Each Layer activates the Modules.
>   * Each Module activates the Services (if instantiateOnStartup).
> The current system is fragile (if a Mixin with the start-up code has its 
> method(s) overridden it will not be instantiated), and we need to find a new 
> solution. This will break compatibility, so it is imperative that this is 
> solved prior to 2.0 release.
> Action item 1; *Remove Activatable interface*
> There are possibly a few ways to provide this functionality, listed in 
> individual comments below.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
http://team.ops4j.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev

Reply via email to