[
https://issues.apache.org/jira/browse/FELIX-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894849#action_12894849
]
Felix Meschberger commented on FELIX-2288:
------------------------------------------
Fixed handling of the component ID in the Declarative Services bundle in Rev.
981772: The ID is now only generated and assigned to a component while the
component is enabled. To still access components without an assigned ID,
ScrService gets a new method getComponent(String name) to access components by
their name.
This also increases the version of the SCR management API to 1.6 (Rev. 981782)
> Felix SCR API problem/misunderstanding
> --------------------------------------
>
> Key: FELIX-2288
> URL: https://issues.apache.org/jira/browse/FELIX-2288
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR), Web Console
> Reporter: Valentin Valchev
> Priority: Critical
>
> I've been playing with the Components plugin of the Web Console and it work
> perfectly with the Felix SCR implementation. When I switched to
> ProSyst/Equinox implementation (they are basically the same) I found a small
> problem.
> When I disable a component, it's ID becomes -1 and I cannot enable it
> anymore. As long as I disable components all their IDs becomes -1.
> I opened the OSGi r4.2 specification to see if there is a reason for this
> behaviour. The JavaDoc for ComponentConstants states for the component ID,
> that
> "The value of this property is assigned by the Service Component Runtime when
> a component configuration is created."
> In part 112.6 Component Properties, the specification says, that
> 'component.id' property is always added by the SCR but for "Each component
> configuration".
> When a component is disabled or uninstalled, there is no configuration - it's
> just a component definition. So the SCR is not required to assign ID.
> As for the Web Console we can easily fix the problem by using the pair bundle
> + component name for identification, instead of ID. However, since Apache SCR
> API is becoming recommended OSGi API, it would be better to define a mature
> and compatible API.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
