Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wait for a capability by the name of the capability given dynamically. #1246

Open
Niranjan-K opened this issue Jan 2, 2017 · 1 comment
Open

Comments

@Niranjan-K
Copy link
Contributor

[Moved from carbon-kernel jira]

Current required capability listener can wait until the given number of capabilities are available, but this number of capabilities are decide at the compile time and there is no way to decide them dynamically at the run time. There are some use cases where the component should only wait for capabilities that decided by a configuration file or some run time configuration. To cater this requirement, following features will be useful.

  1. Feature to decide required capabilities in the run time based on an OSGi property and to give the list of required capabilities dynamically.
  2. Feature to give a custom error message when a capability is not available as the current error message is only showing what type of capability it is waiting for.
    See mail: Improvements For The OSGi Required Capability Listiner
@Kishanthan
Copy link
Contributor

We also need to specify some capabilities need not to be resolved via StartupOrderResolver and skip (may be using a a service property). This is needed in the UUF case where for each UUF app, there is a microservice deployed and it does not need to be handled with StartupOrderResolver

@Kishanthan Kishanthan modified the milestones: 5.2.0-m5, 5.2.0-m4 Apr 7, 2017
@cnapagoda cnapagoda modified the milestones: 5.3.0, 5.2.0-m5 Aug 10, 2017
@jsdjayanga jsdjayanga added the C5 label Jul 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants