[
https://issues.apache.org/jira/browse/FELIX-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volkmar Bluhm updated FELIX-4079:
---------------------------------
Attachment: ordered_invalidation.patch
The patch of my first intention based on iPOJO 1.8.6 release
> 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
