[
https://issues.apache.org/jira/browse/FELIX-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated FELIX-131:
------------------------------------
Fix Version/s: scr-1.0.0
> Fix method lookup and implement enableComponet/disableComponent
> ---------------------------------------------------------------
>
> Key: FELIX-131
> URL: https://issues.apache.org/jira/browse/FELIX-131
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: felix-0.8.0
> Environment: org.apache.felix.scr project, Rev. 427625
> Reporter: Felix Meschberger
> Assignee: Richard S. Hall
> Fix For: scr-1.0.0
>
> Attachments: SCR_fm20060830.diff
>
>
> Attached is a patch, which provides fixes to the method lookup mechanism as
> well as a tentative implementation of the ComponentContext.enableComponent
> and ComponentContext.disableComponent methods.
> (1) Method Lookup
> The Spec says, that methods activate and deactivate as well as the bind and
> unbind methods must be public or protected methods. The currently used
> mechanism of using the Class.getMethod(String name, Class[] parameterTypes)
> method only returns public methods. To also find protected methods, the
> Class.getDeclaredMethod(String name, Class[] parameterTypes) method must be
> used. But this method must be called on the class itself as well as all super
> classes.
> Additionally, any protected method found must be made accessible by calling
> the Method.setAccessible(boolean) method.
> To implement this common behaviour, I added a
> ComponentManagerImpl.getMethod(Class calzz, String name, Class[]
> parameterTypes) which tries to find a public or protected method of the given
> name with required parameters from the class hierarchy of clazz.
> Another minor fix is included with the DependencyManager.getBindingMethod
> method: The third case - looking for method wich takes an assignement
> compatible parameter - only checked for the parameter cardinality and type
> but not for the method name. Besides also supporting protected methods by
> walking the class hierarchy using the Class.getDeclaredMethods() method, I
> added a check for the method name.
> (2) enableComponent/disableComponent
> These methods of the ComponentContext interface have not been implented. I
> added implementation in that the GenericActivator provides these
> implementations, as all registered components or the bundle are known there.
> Actual enabling and disabling is done in a separate thread as stipulated by
> the spec.
> A note on enabling: A component may be initially disabled, in which case the
> GenericActivator.initiliaze() class has created the componnent but not
> registered it. The fix is, to always register the component regardless of
> whether it is a factory component and whether it is enabled or not.
> A note on disabling: Currently, the GenericAdapter.disableComponent method
> calls the ComponentManager.dispose() method. In my opinion, this is not
> entirely correct, as (1) the preconditions regarding component state might be
> wrong, (2) the final state of the component (DESTROYED) is probably wrong
> (shouldn't it be CREATED, but what would be the transient state - DISABLING
> or UNCREATING ?) and (3) at the end the dispose() method clears the
> m_activator field, which would actually be required again if re-enabling the
> component.
> PS: This patch does not include the patch posted for issue FELIX-128 but also
> touches ComponentManagerImpl class.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
