[
https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved FELIX-2895.
--------------------------------------
Resolution: Fixed
Fix Version/s: scr-1.6.2
Assignee: Felix Meschberger
Removed the use of getResource to find the descriptor altogether thus also not
implementing the new configuration property.
Done in Rev. 1180676.
> Allow the use of a property to tell SCR to always discover Service Component
> files even if there's no wildcard in the name
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: FELIX-2895
> URL: https://issues.apache.org/jira/browse/FELIX-2895
> Project: Felix
> Issue Type: Improvement
> Components: Declarative Services (SCR)
> Reporter: Justin Edelson
> Assignee: Felix Meschberger
> Fix For: scr-1.6.2
>
> Attachments: FELIX-2895-fmeschbe.patch, FELIX-2895.patch,
> FELIX-2895_take2.patch
>
>
> The current version of SCR will use the API method getResource() to get the
> service component descriptor if the Service-Component header does not contain
> a wildcard. This precludes the discovery of DS components in attached
> fragment bundles. From the DS spec:
> Section 112.4:
> Component descriptions are defined in XML documents contained in a bundle
> and any attached fragments.
> Section 112.4.1:
> The last component of each path in the Service-Component header may use
> wildcards so that Bundle.findEntries can be used to locate the XML document
> within the bundle and its fragments....
> A Service-Component manifest header specified in a fragment is ignored by
> SCR. However, XML documents referenced by a bundle's Service-Component
> Note the use of the word "may" in the first sentence. It does not say that
> findEntries() should/must *only* be used if there's a wildcard.
> As such, I believe this is within the spec, albeit not backwards compatible
> which is why I'm proposing to use a framework property.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
