[ 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.