[
https://issues.apache.org/jira/browse/FELIX-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger closed FELIX-2526.
------------------------------------
Apache Felix Declarative Services 1.6.0 has been released. The issues are now
closed.
> Add a property to enable workarounds for CT assumptions
> -------------------------------------------------------
>
> Key: FELIX-2526
> URL: https://issues.apache.org/jira/browse/FELIX-2526
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: scr-1.6.0
>
>
> The current OSGi Compendium CT for Declarative services hsa two assumptions,
> which violate the spec. Our implementation correctly implements the spec in
> these two areas and thus fails CT tests.
> The two assumptions are:
> (1) ComponentContext.getProperties() expected writable
> The CT expects the Dictionary returned from ComponentContext.getProperties()
> to be writeable because it is used to pass status information. I reported
> https://www.osgi.org/bugzilla/show_bug.cgi?id=90
> The workaround is to return the internally used Dictionary from the
> ComponentContextImpl.getProperties() implementation.
> (2) Configuration Location Binding ignored
> Configuration is created with a location binding such that validating
> Location Binding fails the configuration tests. The reason is that
> configuration is created bound to a test bundle, while the components are
> provided by another bundle. According to my understanding of the
> Configuration Admin specification, DS should respect location binding when
> providing Configuration to components. I reported
> https://www.osgi.org/bugzilla/show_bug.cgi?id=91
> The workaround is to ignore the location binding when accessing the
> configuration to be supplied to components.
> Defining a framework property to enable these two workarounds makes our
> implementation pass the CT. The property is only supported as a framework
> property and is only read when the bundle is started. By default the property
> is not set, thus disabling the workarounds and behaving spec compliant.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
