[
https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Edelson updated FELIX-2895:
----------------------------------
Attachment: FELIX-2895_take2.patch
based on Richard's comments, here's a second version of the patch which uses
getResources() and genercizes the configuration property name a bit.
> 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
> Reporter: Justin Edelson
> Attachments: 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
