[
https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13123740#comment-13123740
]
Felix Meschberger commented on FELIX-2895:
------------------------------------------
Thinking about it I come to the conclusion, that using getResource is really
wrong. So I think we should go the full length and completely remove the use of
getResource....
> 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
> 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
