[
http://team.ops4j.org/browse/QI-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17400#comment-17400
]
Niclas Hedhman commented on QI-364:
-----------------------------------
Suggestion 1
Introduce the Activation interface;
public interface Activation<T>
{
void beforeActivation( T item );
void afterActivation( T item );
void beforeActivation( T item );
void afterActivation( T item );
}
and a convenience abstract class;
public abstract class ActivationAdapter
implements Activation
{
// no op methods for easy overriding.
}
and it is possible to register hooks in the assembly;
public interface ApplicationAssembly
{
:
void activateWith( Class<? extends Activation<Application>> activator );
}
public interface LayerAssembly
{
:
void activateWith( Class<? extends Activation<Layer>> activator );
}
public interface ModuleAssembly
{
:
void activateWith( Class<? extends Activation<Module>> activator );
}
public interface ServiceDeclaration {
:
void activateWith( Class<? extends Activation<?>> activator )
}
> 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.
--
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
