Extend SCR to allow alternate activate and deactivate method signatures
-----------------------------------------------------------------------
Key: FELIX-925
URL: https://issues.apache.org/jira/browse/FELIX-925
Project: Felix
Issue Type: New Feature
Components: Declarative Services (SCR)
Affects Versions: scr-1.0.6
Environment: OSGi RFC-0134, OSGi R4.2 Early Draft 2
(http://www.osgi.org/download/osgi-4.2-early-draft2.pdf)
Reporter: Felix Meschberger
Fix For: scr-1.2.0
A way is needed to avoid using DS API at all in components with SCR. This means
the activate and deactivate methods should not require the ComponentContext
parameter. We should also allow the names of the activate and deactivate
methods to be specified to avoid requiring specific method names.
To support this, the follow attributes will be added to the component element:
<attribute name="activate" type="token" use="optional" default="activate" />
<attribute name="deactivate" type="token" use="optional
default="deactivate" />
The activate attribute will specify the name of the activate method and the
deactivate attribute will specify the name of the deactivate method.
The signature for the activate and deactivate methods is:
p r o t e c t ed vo i d <me thod - name> (< a r gumen t s >
) ;
<arguments> can be zero or more arguments.
For the activate method each argument must be of one of the following types:
● ComponentContext - the Component Context for the component
● BundleContext - the Bundle Context of the component's bundle
● Map - the Component Properties from ComponentContext.getProperties.
If any argument of the activate method is not one of the above types, SCR must
log an error message with the Log Service, if present, and the component
configuration is not activated.
For the deactivate method each argument must be of one of the following types:
● int/Integer - the deactivation reason
● ComponentContext - the Component Context for the component
● BundleContext - the Bundle Context of the component's bundle
● Map - the Component Properties from ComponentContext.getProperties.
If any argument of the deactivate method is not one of the above types, SCR
must log an error message with the Log Service, if present, and the
deactivation of the component configuration will continue.
The methods may also be declared public. The same rules as specified in 112.5.8
will be used to locate the activate and deactivate methods in the
implementation class hierarchy.
3.2.1 Component deactivation reasons
When a component is deactivated, the reason for the deactivation can be passed
to the deactivate method. The following deactivation reasons are specified in
ComponentConstants.
/**
* The reason the component instance was deactivated is
unspecified.
*
* @since 1.1
*/
public static final int DEACTIVATION_REASON_UNSPECIFIED = 0;
/**
* The component instance was deactivated because the
component was disabled.
*
* @since 1.1
*/
public static final int DEACTIVATION_REASON_DISABLED = 1;
/**
* The component instance was deactivated because a reference
became unsatisfied.
*
* @since 1.1
*/
public static final int DEACTIVATION_REASON_REFERENCE = 2;
/**
* The component instance was deactivated because its
configuration was changed.
*
* @since 1.1
*/
public static final int
DEACTIVATION_REASON_CONFIGURATION_MODIFIED = 3;
/**
* The component instance was deactivated because its
configuration was deleted.
*
* @since 1.1
*/
public static final int
DEACTIVATION_REASON_CONFIGURATION_DELETED = 4;
/**
* The component instance was deactivated because the
component was disposed.
*
* @since 1.1
*/
public static final int DEACTIVATION_REASON_DISPOSED = 5;
/**
* The component instance was deactivated because the bundle
was stopped.
*
* @since 1.1
*/
public static final int DEACTIVATION_REASON_BUNDLE_STOPPED =
6;
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
