You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Clement Escoffier (JIRA)" <ji...@apache.org> on 2006/06/19 14:41:29 UTC
[jira] Created: (FELIX-81) problem when component's state change
problem when component's state change
-------------------------------------
Key: FELIX-81
URL: http://issues.apache.org/jira/browse/FELIX-81
Project: Felix
Type: Bug
Components: iPOJO
Reporter: Clement Escoffier
When the component's state change, iPOJO loops on the handlers list and call the stateChanged method on each handler. But the order of call is the same than the handler starting order.
A problem occurs when the stopping lifecycle callback handler uses a service dependency, the service dependency handler is "stopped" before the lifecycle callback handler. So, the callback call the dependency, but the dependency manager does not maintain service list anymore (it is stopped) and return null.
Thie fix has two parts :
1) modifiyng the internal handler order
2) loop in reverse on the handler list in the setState method and stop method (ComponentManager class).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (FELIX-81) problem when component's state change
Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/FELIX-81?page=all ]
Clement Escoffier closed FELIX-81:
----------------------------------
Patch applied
> problem when component's state change
> -------------------------------------
>
> Key: FELIX-81
> URL: http://issues.apache.org/jira/browse/FELIX-81
> Project: Felix
> Type: Bug
> Components: iPOJO
> Reporter: Clement Escoffier
> Assignee: Richard S. Hall
> Attachments: patch.txt
>
> When the component's state change, iPOJO loops on the handlers list and call the stateChanged method on each handler. But the order of call is the same than the handler starting order.
> A problem occurs when the stopping lifecycle callback handler uses a service dependency, the service dependency handler is "stopped" before the lifecycle callback handler. So, the callback call the dependency, but the dependency manager does not maintain service list anymore (it is stopped) and return null.
> Thie fix has two parts :
> 1) modifiyng the internal handler order
> 2) loop in reverse on the handler list in the setState method and stop method (ComponentManager class).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (FELIX-81) problem when component's state change
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/FELIX-81?page=all ]
Richard S. Hall reassigned FELIX-81:
------------------------------------
Assign To: Richard S. Hall
> problem when component's state change
> -------------------------------------
>
> Key: FELIX-81
> URL: http://issues.apache.org/jira/browse/FELIX-81
> Project: Felix
> Type: Bug
> Components: iPOJO
> Reporter: Clement Escoffier
> Assignee: Richard S. Hall
> Attachments: patch.txt
>
> When the component's state change, iPOJO loops on the handlers list and call the stateChanged method on each handler. But the order of call is the same than the handler starting order.
> A problem occurs when the stopping lifecycle callback handler uses a service dependency, the service dependency handler is "stopped" before the lifecycle callback handler. So, the callback call the dependency, but the dependency manager does not maintain service list anymore (it is stopped) and return null.
> Thie fix has two parts :
> 1) modifiyng the internal handler order
> 2) loop in reverse on the handler list in the setState method and stop method (ComponentManager class).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (FELIX-81) problem when component's state change
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/FELIX-81?page=all ]
Richard S. Hall resolved FELIX-81:
----------------------------------
Resolution: Fixed
This is resolved after applying Clement's patch, so I am closing it.
> problem when component's state change
> -------------------------------------
>
> Key: FELIX-81
> URL: http://issues.apache.org/jira/browse/FELIX-81
> Project: Felix
> Type: Bug
> Components: iPOJO
> Reporter: Clement Escoffier
> Assignee: Richard S. Hall
> Attachments: patch.txt
>
> When the component's state change, iPOJO loops on the handlers list and call the stateChanged method on each handler. But the order of call is the same than the handler starting order.
> A problem occurs when the stopping lifecycle callback handler uses a service dependency, the service dependency handler is "stopped" before the lifecycle callback handler. So, the callback call the dependency, but the dependency manager does not maintain service list anymore (it is stopped) and return null.
> Thie fix has two parts :
> 1) modifiyng the internal handler order
> 2) loop in reverse on the handler list in the setState method and stop method (ComponentManager class).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (FELIX-81) problem when component's state change
Posted by "Clement Escoffier (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/FELIX-81?page=all ]
Clement Escoffier updated FELIX-81:
-----------------------------------
Attachment: patch.txt
Patch fixing the handlers invocation order.
> problem when component's state change
> -------------------------------------
>
> Key: FELIX-81
> URL: http://issues.apache.org/jira/browse/FELIX-81
> Project: Felix
> Type: Bug
> Components: iPOJO
> Reporter: Clement Escoffier
> Attachments: patch.txt
>
> When the component's state change, iPOJO loops on the handlers list and call the stateChanged method on each handler. But the order of call is the same than the handler starting order.
> A problem occurs when the stopping lifecycle callback handler uses a service dependency, the service dependency handler is "stopped" before the lifecycle callback handler. So, the callback call the dependency, but the dependency manager does not maintain service list anymore (it is stopped) and return null.
> Thie fix has two parts :
> 1) modifiyng the internal handler order
> 2) loop in reverse on the handler list in the setState method and stop method (ComponentManager class).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira