[jira] [Commented] (FELIX-4079) Component lifecycle

["Guillaume Sauthier (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668340#comment-13668340 ] 

Guillaume Sauthier commented on FELIX-4079:
-------------------------------------------

In short, you want your @Invalidate methods to be invoked before any mandatory @Unbind (if the dependency departure would lead to the invalidation of the instance) ?
                
> Component lifecycle
> -------------------
>
>                 Key: FELIX-4079
>                 URL: https://issues.apache.org/jira/browse/FELIX-4079
>             Project: Felix
>          Issue Type: Improvement
>          Components: iPOJO
>    Affects Versions: ipojo-runtime-1.8.6
>            Reporter: Volkmar Bluhm
>         Attachments: ordered_invalidation.patch
>
>
> At iPOJO's documentation section I had read that invalidation has to be developed defensively, because services already could be departed.
> While improving the shutdown behaviour of components in our OSGi container (Felix implementation), I often made some handstands.
> I know that reacting on a leaving service can be done by using bind and unbind callbacks, but this only tracks one required service. In most cases our components requiring several services. Unbind only guarantees that one service (the leaving one) is available, but not other ones. Handling this needs a mass of code sometimes.
> So my intentions are the following:
> 1) I had modified DependencyModel.manageDeparture() to invalidate if a required (not optional) service is leaving (and not already departed).
> Now all services, requiring the leaving service will be informed via unbind and invalidate callback before the service is departed. I tested a lot and it seems to work very fine. I'm going to attach a patch file for.
> Of course there are several use cases in which the invalidation callback doesn't care whether a required service is available anymore or not, but in our cases we often run into a mass of boilerplate code to get sure stopping components safely.
> 2) If this behaviour is not desirable, I would welcome a further callback (like @PreInvalidation) to have a central method in a component where all requirements are available before one or more are leaving.
> Best regards!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira