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

["Volkmar Bluhm (JIRA)" <ji...@apache.org>]

Volkmar Bluhm created FELIX-4079:
------------------------------------

             Summary: 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


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