[ 
https://issues.apache.org/jira/browse/FELIX-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Adamcin updated FELIX-6699:
--------------------------------
    Labels: patch-available  (was: )

> [DS] Excessive ERROR logging when Overlap in Service-Component header between 
> wildcard and non-wildcard locations
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: FELIX-6699
>                 URL: https://issues.apache.org/jira/browse/FELIX-6699
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-2.2.10
>            Reporter: Mark Adamcin
>            Priority: Major
>              Labels: patch-available
>             Fix For: scr-2.2.12
>
>
> When a bundle's Service-Component header contains explicit paths and wildcard 
> paths, it is possible for an explicit descriptor entry to be parsed twice, if 
> it is also matched by a wildcard entry. This results in an ERROR level log 
> similar to that described in FELIX-2325. The use case which requires this mix 
> of wildcard and non-wildcard entries is probably rare, but such is the 
> situation with 
> [https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/3241]
> In this situation, bnd is used to package the host bundle, and so the 
> descriptors for the DS components contained within it are listed explicitly 
> in the Service-Component header value generated by the bnd tool. 
> Additionally, the project packages some optional component descriptors in a 
> sidecar fragment bundle which cannot define its own Service-Component header. 
> In order for SCR to load the optional components only when the fragment is 
> attached, they must be listed by the host bundle's Service-Component header, 
> but only implicitly by using a wildcard, so that their absence is not logged 
> when the fragment is not attached.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to