You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Justin Edelson (JIRA)" <ji...@apache.org> on 2011/03/29 20:32:05 UTC
[jira] [Created] (FELIX-2895) Allow the use of a property to tell
SCR to always use findEntries, not getResource
Allow the use of a property to tell SCR to always use findEntries, not getResource
----------------------------------------------------------------------------------
Key: FELIX-2895
URL: https://issues.apache.org/jira/browse/FELIX-2895
Project: Felix
Issue Type: Improvement
Reporter: Justin Edelson
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
[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
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013681#comment-13013681 ]
Richard S. Hall commented on FELIX-2895:
----------------------------------------
Just keep in mind, the two are not equivalent. getResources() will take into account imported packages and required bundles too, not just local content and fragments. findEntries() will only take into account local content and fragments.
I'm not sure what you want to achieve, I'm just making observations.
> 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
[jira] [Updated] (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
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated FELIX-2895:
-------------------------------------
Attachment: FELIX-2895-fmeschbe.patch
Proposed patch defining a property which must be set to use Bundle.getResource otherwise Bundle.findEntries will always be used.
Note: I really don't like the proposed name of the property. Improvements highly welcome ....
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[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
Posted by "Justin Edelson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013717#comment-13013717 ]
Justin Edelson commented on FELIX-2895:
---------------------------------------
getResource() is used now when the name doesn't use wildcards. The second patch (which uses getResources()) is thus more consistent with the current behavior.
>From my perspective, findEntries() should be used all the time, but I was trying to be somewhat backwards-compatible.
> 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
[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
Posted by "Justin Edelson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046786#comment-13046786 ]
Justin Edelson commented on FELIX-2895:
---------------------------------------
Patch LGTM. Only suggestion I can make about the property name would be to change it to ds.usegetresource but that's only marginally better.
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-2895) Allow the use of a property to tell
SCR to always use findEntries, not getResource
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013638#comment-13013638 ]
Richard S. Hall commented on FELIX-2895:
----------------------------------------
getResources() will return multiple results, but it is still not as flexible as findEntries()...
> Allow the use of a property to tell SCR to always use findEntries, not getResource
> ----------------------------------------------------------------------------------
>
> Key: FELIX-2895
> URL: https://issues.apache.org/jira/browse/FELIX-2895
> Project: Felix
> Issue Type: Improvement
> Reporter: Justin Edelson
> Attachments: FELIX-2895.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
[jira] [Resolved] (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
Posted by "Felix Meschberger (Resolved) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Closed] (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
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger closed FELIX-2895.
------------------------------------
Close after release
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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
Posted by "Justin Edelson (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (FELIX-2895) Allow the use of a property to tell
SCR to always use findEntries, not getResource
Posted by "Richard S. Hall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012604#comment-13012604 ]
Richard S. Hall commented on FELIX-2895:
----------------------------------------
Perhaps I'm missing something, but Bundle.getResource() also searches fragments. The main difference is that it has to be reachable from the bundle class path, where findEntries() allows you to search in other places too.
> Allow the use of a property to tell SCR to always use findEntries, not getResource
> ----------------------------------------------------------------------------------
>
> Key: FELIX-2895
> URL: https://issues.apache.org/jira/browse/FELIX-2895
> Project: Felix
> Issue Type: Improvement
> Reporter: Justin Edelson
>
> 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
[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
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (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
Posted by "Justin Edelson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Justin Edelson updated FELIX-2895:
----------------------------------
Summary: Allow the use of a property to tell SCR to always discover Service Component files even if there's no wildcard in the name (was: Allow the use of a property to tell SCR to always use findEntries, not getResource)
making summary more accurate
> 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
>
>
> 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
[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
Posted by "Felix Meschberger (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (FELIX-2895) Allow the use of a property to tell
SCR to always use findEntries, not getResource
Posted by "Justin Edelson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013636#comment-13013636 ]
Justin Edelson commented on FELIX-2895:
---------------------------------------
Richard - the key difference is that getResource() returns exactly one result. findEntries returns all matching results.
The use case I'm concerned with is where there is more than one Service Component file. Sorry if this wasn't clear.
> Allow the use of a property to tell SCR to always use findEntries, not getResource
> ----------------------------------------------------------------------------------
>
> Key: FELIX-2895
> URL: https://issues.apache.org/jira/browse/FELIX-2895
> Project: Felix
> Issue Type: Improvement
> Reporter: Justin Edelson
> Attachments: FELIX-2895.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
[jira] [Updated] (FELIX-2895) Allow the use of a property to tell
SCR to always use findEntries, not getResource
Posted by "Justin Edelson (JIRA)" <ji...@apache.org>.
[ 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.patch
proposed patch
> Allow the use of a property to tell SCR to always use findEntries, not getResource
> ----------------------------------------------------------------------------------
>
> Key: FELIX-2895
> URL: https://issues.apache.org/jira/browse/FELIX-2895
> Project: Felix
> Issue Type: Improvement
> Reporter: Justin Edelson
> Attachments: FELIX-2895.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
[jira] [Updated] (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
Posted by "Justin Edelson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Justin Edelson updated FELIX-2895:
----------------------------------
Component/s: Declarative Services (SCR)
> 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