felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-2895) Allow the use of a property to tell SCR to always discover Service Component files even if there's no wildcard in the name
Date Tue, 07 Jun 2011 14:39:58 GMT

    [ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045454#comment-13045454
] 

Felix Meschberger commented on FELIX-2895:
------------------------------------------

Looking at the code and considering what the spec really says in 112.4.1: "The value of the
header is a comma separated list of paths to XML *entries* within the bundle." I think use
getResource() is completely wrong.

In addition, getResource() as RIchard says, might also return files outside of the bundle,
which again is wrong. Lastly it uses the class loader and thus forces the creation of such
a class loader (which creation might be delayed otherwise).

So in essence, getResource() should really be replaced by getEntry() to ensure only scanning
the bundle --- of course this will miss descriptors in embedded libraries, but I think this
is something we can live with: I assume descriptors will not be embedded in embedded libraries
because such libraries would then probably be bundles and thus be installed in the framework
as such ...

I suggest we go the full route and always use Bundle.findEntries even for non-wildcarded locations.
If a specific configuration framework property (or scr configuration ?) is set non-wildcarded
locations will still be accessed with Bundle.getResource. So backwards compatibility is still
provided but has to be asked for explicitly.

> 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.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

Mime
View raw message