felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Volkmar Bluhm (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-4079) Component lifecycle
Date Tue, 28 May 2013 14:56:20 GMT

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

Volkmar Bluhm commented on FELIX-4079:

I would also agree if unbind is called first, but the point is to own all requirements at
invalidate callback.
> 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

View raw message