[
http://team.ops4j.org/browse/QI-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17560#comment-17560
]
Paul Merlin commented on QI-364:
--------------------------------
I'll be more confident going with the first suggestion.
I would rephrase it as follows.
Introduce Activator and Passivator interfaces:
{code:java}
public interface Activator<T>
{
void beforeActivation( T activated );
void afterActivation( T activated );
}
public interface Passivator<T>
{
void beforePassivation( T passivated );
void afterPassivation( T passivated );
}
// + Convenience abstract classes ActivatorAdapter and PassivatorAdapter.
{code}
and it is possible to register hooks in the assembly;
{code:java}
public interface ApplicationAssembly
{
:
void withActivators( Class<? extends Activator<Application>>... activators
);
void withPassivators( Class<? extends Passivator<Application>>...
passivators );
}
public interface LayerAssembly
{
:
void withActivators( Class<? extends Activator<Layer>>... activators );
void withPassivators( Class<? extends Passivator<Layer>>... passivators );
}
public interface ModuleAssembly
{
:
void withActivators( Class<? extends Activator<Module>>... activators );
void withPassivators( Class<? extends Passivator<Module>>... passivators );
}
public interface ServiceDeclaration {
:
void withActivators( Class<? extends Activator<?>>... activators )
void withPassivators( Class<? extends Passivator<?>>... passivators );
}
{code}
And in the same vein as withMixins it could be declared on the Services with
@Activators and @Passivators annotation where the order can be kept.
WDYT?
/Paul
> 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
