[jira] [Resolved] (FELIX-6141) Risk of NPE when Maps containing null keys or values are converted

[Timothy Ward (JIRA)]

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

Timothy Ward resolved FELIX-6141.
-
Resolution: Fixed

Fixed in SVN revision r1860547

It would be good to get confirmation from [~bosschaert] that this is an 
acceptable fix as per the OSGi specification.

> Risk of NPE when Maps containing null keys or values are converted
> --
>
> Key: FELIX-6141
> URL: https://issues.apache.org/jira/browse/FELIX-6141
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.8
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Major
> Fix For: converter-1.0.10
>
>
> The Converter code incorrectly calls Class#isAssignableFrom() using an 
> argument that may be null. This results in an NPE being thrown when 
> converting map-like values into scalars. Even if conversion should fail it 
> should never fail by throwing an NPE.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FELIX-6141) Risk of NPE when Maps containing null keys or values are converted

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-6141:
---

 Summary: Risk of NPE when Maps containing null keys or values are 
converted
 Key: FELIX-6141
 URL: https://issues.apache.org/jira/browse/FELIX-6141
 Project: Felix
  Issue Type: Bug
  Components: Converter
Affects Versions: converter-1.0.8
Reporter: Timothy Ward
Assignee: Timothy Ward
 Fix For: converter-1.0.10


The Converter code incorrectly calls Class#isAssignableFrom() using an argument 
that may be null. This results in an NPE being thrown when converting map-like 
values into scalars. Even if conversion should fail it should never fail by 
throwing an NPE.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FELIX-6138) Missing support for temporal types

[Timothy Ward (JIRA)]

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

Timothy Ward resolved FELIX-6138.
-
Resolution: Fixed

Fixed in SVN revision r1860413

> Missing support for temporal types
> --
>
> Key: FELIX-6138
> URL: https://issues.apache.org/jira/browse/FELIX-6138
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Affects Versions: converter-1.0.8
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Major
> Fix For: converter-1.0.10
>
>
> Table *707.2* of the compendium specification (in section 707.4.2.3) contains 
> mappings for a number of types from java.time. Several of these types are not 
> supported by the converter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FELIX-6138) Missing support for temporal types

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-6138:
---

 Summary: Missing support for temporal types
 Key: FELIX-6138
 URL: https://issues.apache.org/jira/browse/FELIX-6138
 Project: Felix
  Issue Type: Bug
  Components: Converter
Affects Versions: converter-1.0.8
Reporter: Timothy Ward
Assignee: Timothy Ward
 Fix For: converter-1.0.10


Table *707.2* of the compendium specification (in section 707.4.2.3) contains 
mappings for a number of types from java.time. Several of these types are not 
supported by the converter.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Felix Converter 1.0.8

[Timothy Ward]

+1

> On 18 Apr 2019, at 14:30, Jean-Baptiste Onofré  wrote:
> 
> +1 (binding)
> 
> Regards
> JB
> 
> On 18/04/2019 12:47, dav...@apache.org wrote:
>> Hi all,
>> 
>> A number of issues have been fixed in the Felix Converter:
>> https://issues.apache.org/jira/projects/FELIX/versions/12344992
>> 
>> Therefore I would like to call the Converter 1.0.8 release.
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1297/
>> 
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> 
>> Usage:
>> sh check_staged_release.sh 1297 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> This vote will be open for at least 72 hours.
>> 
>> Best regards,
>> 
>> David Bosschaert
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

[jira] [Created] (FELIX-6100) The converter fails to properly convert null to array types

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-6100:
---

 Summary: The converter fails to properly convert null to array 
types
 Key: FELIX-6100
 URL: https://issues.apache.org/jira/browse/FELIX-6100
 Project: Felix
  Issue Type: Bug
  Components: Converter
Affects Versions: converter-1.0.4
Reporter: Timothy Ward
Assignee: Timothy Ward
 Fix For: converter-1.0.6


The Converter specification [says in 
707.4.3.1|https://osgi.org/specification/osgi.cmpn/7.0.0/util.converter.html#util.converter-arrays.collections]
 that null should be converted to an empty array, however the current 
implementation converts to an empty `Object[]` regardless of the target type, 
for example a `byte[]`. This is clearly wrong as the returned object cannot be 
assigned to the target type!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: March board report

[Timothy Ward]

It looks good to me too.

Tim

> On 12 Mar 2019, at 07:09, Jean-Baptiste Onofré  wrote:
> 
> Hi,
> 
> It looks good to me. Thanks Karl !
> 
> Regards
> JB
> 
> On 11/03/2019 13:24, Karl Pauls wrote:
>> Hi,
>> 
>> Please find the board report below. Comments welcome.
>> 
>> ## Description:
>> 
>> 
>> Apache Felix is a project aimed at implementing specifications from the OSGi
>> 
>> Alliance as well as implementing other supporting tools and technologies
>> 
>> aligned with OSGi technology.
>> 
>> 
>> ## Issues:
>> 
>> 
>> - There are no issues requiring board attention at this time.
>> 
>> 
>> ## Activity:
>> 
>> 
>> - Existing implementations have been improved/enhanced based on community
>> 
>>   feedback.
>> 
>> - Released 15 components (mostly bug fixes and a new healthcheck subproject).
>> 
>> - Accepted and integrated the "Health Check Framework" contribution from the
>> 
>>   Apache Sling project.
>> 
>> 
>> ## Health report:
>> 
>> 
>> - Overall the project is in good health.
>> 
>> - Questions on the user list are answered, development concerns are either
>> 
>>   discussed on the mailing list or directly in the JIRA issues.
>> 
>> - The project as well as the OSGi community in general is still in the
>> 
>>   process of adapting to JPMS and its long term impact.
>> 
>> - We added 3 committer by attracting a contribution from the Apache Sling
>> 
>>   project. The contribution (called healthchecks) has been integrated and
>> 
>>   released.
>> 
>> - Turning some of the committers we gained recently into PMC members needs to
>> 
>>   be a focus for the upcoming quarter.
>> 
>> - We had no issues voting on releases and JIRA issues are generally addressed
>> 
>>   promptly.
>> 
>> 
>> ## PMC changes:
>> 
>> 
>> - Currently 26 PMC members.
>> 
>> - No new PMC members added in the last 3 months
>> 
>> - Last PMC addition was Raymond Augé on Thu May 03 2018
>> 
>> 
>> ## Committer base changes:
>> 
>> 
>> - Currently 67 committers.
>> 
>> - New commmitters:
>> 
>>- Bertrand Delacretaz was added as a committer on Tue Dec 18 2018
>> 
>>- Georg Henzler was added as a committer on Tue Dec 18 2018
>> 
>>- Oliver Lietz was added as a committer on Tue Dec 18 2018
>> 
>> 
>> ## Releases:
>> 
>> 
>> - felix-logback-1.0.2 was released on Mon Jan 21 2019
>> 
>> - org.apache.felix.converter-1.0.4 was released on Thu Mar 07 2019
>> 
>> - org.apache.felix.dependencymanager-r15 was released on Sun Dec 23 2018
>> 
>> - org.apache.felix.framework-5.6.12 was released on Mon Feb 04 2019
>> 
>> - org.apache.felix.framework-6.0.2 was released on Thu Jan 31 2019
>> 
>> - org.apache.felix.gogo.jline-1.1.4 was released on Mon Jan 28 2019
>> 
>> - org.apache.felix.healthcheck.annotation-2.0.0 was released on Mon Feb 25
>> 
>>   2019
>> 
>> - org.apache.felix.healthcheck.api-2.0.0 was released on Mon Feb 25 2019
>> 
>> - org.apache.felix.healthcheck.core-2.0.0 was released on Mon Feb 25 2019
>> 
>> - org.apache.felix.healthcheck.generalchecks-2.0.0 was released on Mon Feb 25
>> 
>>   2019
>> 
>> - org.apache.felix.healthcheck.webconsoleplugin-2.0.0 was released on Mon Feb
>> 
>>   25 2019
>> 
>> - org.apache.felix.main-6.0.2 was released on Thu Jan 31 2019
>> 
>> - org.apache.felix.main.distribution-6.0.2 was released on Thu Jan 31 2019
>> 
>> - org.apache.felix.scr-2.1.12 was released on Tue Feb 26 2019
>> 
>> - org.apache.felix.scr.bnd-1.9.2 was released on Mon Jan 28 2019
>> 
>> 
>> ## Mailing list activity:
>> 
>> 
>> - us...@felix.apache.org:
>> 
>>- 564 subscribers (down -2 in the last 3 months):
>> 
>>- 75 emails sent to list (134 in previous quarter)
>> 
>> 
>> - dev@felix.apache.org:
>> 
>>- 320 subscribers (down -4 in the last 3 months):
>> 
>>- 876 emails sent to list (844 in previous quarter)
>> 
>> 
>> ## JIRA activity:
>> 
>> 
>> - 84 JIRA tickets created in the last 3 months
>> 
>> - 72 JIRA tickets closed/resolved in the last 3 months
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [VOTE] Release Apache Felix Configadmin 1.9.14

[Timothy Ward]

+1

> On 7 Mar 2019, at 13:31, Jean-Baptiste Onofré  wrote:
> 
> Hi,
> 
> We solved one issue in this release:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100=12345009
> 
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1291
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> Regards
> JB

Re: [VOTE] Release Apache Felix Http Components

[Timothy Ward]

+1

> On 27 Feb 2019, at 09:31, David Bosschaert  wrote:
> 
> +1
> 
> David
> 
> On Tue, 26 Feb 2019 at 15:05, Carsten Ziegeler  wrote:
> 
>> We solved four issues in http base 4.0.6:
>> 
>> https://issues.apache.org/jira/projects/FELIX/versions/12344179
>> 
>> We solved four issues in http bridge 4.0.6
>> https://issues.apache.org/jira/projects/FELIX/versions/12344181
>> 
>> We solved eight issues in http jetty 4.0.8
>> https://issues.apache.org/jira/projects/FELIX/versions/12344180
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1289
>> 
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> 
>> Usage:
>> sh check_staged_release.sh 1289 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> Regards
>> Carsten
>> 
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>> 

Re: [VOTE] Release Apache Felix Configadmin 1.9.12

[Timothy Ward]

+1

Tim

> On 21 Feb 2019, at 07:39, Georg Henzler  wrote:
> 
> +1 (non-binding)
> 
> -Georg
> 
> On 2019-02-21 06:25, Francois Papon wrote:
>> +1 (non-binding)
>> Thanks!
>> regards,
>> François Papon
>> fpa...@apache.org
>> Le 20/02/2019 à 14:54, Carsten Ziegeler a écrit :
>>> We solved two issues in this release:
>>> http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.configadmin-1.9.12/changelog.txt
>>> Staging repositories:
>>> https://repository.apache.org/content/repositories/orgapachefelix-1287/
>>> You can use this UNIX script to download the release and verify the
>>> signatures:
>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>> Usage:
>>> sh check_staged_release.sh 1287 /tmp/felix-staging
>>> Please vote to approve this release:
>>> [ ] +1 Approve the release
>>> [ ] -1 Veto the release (please provide specific comments)
>>> Regards
>>> Carsten
>>> --
>>> Carsten Ziegeler
>>> Adobe Research Switzerland
>>> cziege...@apache.org

Re: [VOTE] Release Felix SCR version 2.1.16

[Timothy Ward]

+1

Tim

> On 21 Feb 2019, at 09:32, David Bosschaert  wrote:
> 
> +1
> 
> David
> 
> On Wed, 20 Feb 2019 at 18:43, Thomas Watson  wrote:
> 
>> Hi,
>> 
>> We solved 10 issues in this release:
>> 
>> 
>> http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.scr-2.1.16/changelog.txt
>> 
>> 
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-1288/
>> 
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> 
>> Usage:
>> sh check_staged_release.sh 1288 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> Tom
>> 

[jira] [Created] (FELIX-6065) The Converter doesn't support Wildcard types

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-6065:
---

 Summary: The Converter doesn't support Wildcard types
 Key: FELIX-6065
 URL: https://issues.apache.org/jira/browse/FELIX-6065
 Project: Felix
  Issue Type: Improvement
  Components: Converter
Affects Versions: converter-1.0.2
Reporter: Timothy Ward
 Fix For: converter-1.0.6


If you pass a wildcard type to the converter then it fails to do the 
conversion. This is an odd thing to do, but it is definitely possible to work 
out what the type is.

 

For example:

    to(new TypeReference>(){});

 

can be converted to a Map, and 

    to(new TypeReference>>(){});

can be converted to a Map>

 

It is unclear what it would mean to use

{{ to(new TypeReference(){});}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FELIX-6064) Allow leniency when converting from DTO-like types with no public no-args constructor

[Timothy Ward (JIRA)]

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

Timothy Ward resolved FELIX-6064.
-
Resolution: Fixed

Fixed in SVN revision 1853957

> Allow leniency when converting from DTO-like types with no public no-args 
> constructor
> -
>
> Key: FELIX-6064
> URL: https://issues.apache.org/jira/browse/FELIX-6064
> Project: Felix
>  Issue Type: Improvement
>  Components: Converter
>Affects Versions: converter-1.0.2
>    Reporter: Timothy Ward
>Assignee: Timothy Ward
>Priority: Major
> Fix For: converter-1.0.6
>
>
> DTO types are supposed to have a public no-args constructor, but this is only 
> needed by the converter when converting *to* a DTO type. We should allow some 
> leniency when converting from a DTO like type because we don't need to 
> construct it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FELIX-6064) Allow leniency when converting from DTO-like types with no public no-args constructor

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-6064:
---

 Summary: Allow leniency when converting from DTO-like types with 
no public no-args constructor
 Key: FELIX-6064
 URL: https://issues.apache.org/jira/browse/FELIX-6064
 Project: Felix
  Issue Type: Improvement
  Components: Converter
Affects Versions: converter-1.0.2
Reporter: Timothy Ward
Assignee: Timothy Ward
 Fix For: converter-1.0.6


DTO types are supposed to have a public no-args constructor, but this is only 
needed by the converter when converting *to* a DTO type. We should allow some 
leniency when converting from a DTO like type because we don't need to 
construct it.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FELIX-6063) Avoid using reflection operations which require permissions

[Timothy Ward (JIRA)]

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

Timothy Ward resolved FELIX-6063.
-
Resolution: Fixed

Updated in SVN commit 1853936

> Avoid using reflection operations which require permissions
> ---
>
> Key: FELIX-6063
> URL: https://issues.apache.org/jira/browse/FELIX-6063
> Project: Felix
>  Issue Type: Improvement
>  Components: Converter
>Affects Versions: converter-1.0.2
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Major
> Fix For: converter-1.0.4
>
>
> The Converter implementation uses lots of reflection as part of its 
> operation, however it is only expected to interact with public members. It 
> should therefore not use getDeclaredMethods() or getDeclaredFields().



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FELIX-6063) Avoid using reflection operations which require permissions

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-6063:
---

 Summary: Avoid using reflection operations which require 
permissions
 Key: FELIX-6063
 URL: https://issues.apache.org/jira/browse/FELIX-6063
 Project: Felix
  Issue Type: Improvement
  Components: Converter
Affects Versions: converter-1.0.2
Reporter: Timothy Ward
Assignee: Timothy Ward
 Fix For: converter-1.0.4


The Converter implementation uses lots of reflection as part of its operation, 
however it is only expected to interact with public members. It should 
therefore not use getDeclaredMethods() or getDeclaredFields().



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FELIX-6061) Configuration Admin uses getDeclaredMethods without permission

[Timothy Ward (JIRA)]

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

Timothy Ward resolved FELIX-6061.
-
Resolution: Fixed

Changed to use getMethods() in SVN revision 1853885

> Configuration Admin uses getDeclaredMethods without permission
> --
>
> Key: FELIX-6061
> URL: https://issues.apache.org/jira/browse/FELIX-6061
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.9.10
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Blocker
> Fix For: configadmin-1.9.12
>
>
> The use of getDeclaredMethods requires a security permission which 
> Configuration Admin doesn't have. This needs to be fixed by either using 
> getMethods (which doesn't need a permission) or adding the permission to 
> Configuration Admin's permissions.perm
> Removing the call would be preferred.
>  
> Note that this bug breaks the OSGi Compliance Tests



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-6061) Configuration Admin uses getDeclaredMethods without permission

[Timothy Ward (JIRA)]

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

Timothy Ward updated FELIX-6061:

Issue Type: Bug  (was: Improvement)

> Configuration Admin uses getDeclaredMethods without permission
> --
>
> Key: FELIX-6061
> URL: https://issues.apache.org/jira/browse/FELIX-6061
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.9.10
>Reporter: Timothy Ward
>    Assignee: Timothy Ward
>Priority: Blocker
>
> The use of getDeclaredMethods requires a security permission which 
> Configuration Admin doesn't have. This needs to be fixed by either using 
> getMethods (which doesn't need a permission) or adding the permission to 
> Configuration Admin's permissions.perm
> Removing the call would be preferred.
>  
> Note that this bug breaks the OSGi Compliance Tests



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FELIX-6061) Configuration Admin uses getDeclaredMethods without permission

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-6061:
---

 Summary: Configuration Admin uses getDeclaredMethods without 
permission
 Key: FELIX-6061
 URL: https://issues.apache.org/jira/browse/FELIX-6061
 Project: Felix
  Issue Type: Improvement
  Components: Configuration Admin
Affects Versions: configadmin-1.9.10
Reporter: Timothy Ward
Assignee: Timothy Ward


The use of getDeclaredMethods requires a security permission which 
Configuration Admin doesn't have. This needs to be fixed by either using 
getMethods (which doesn't need a permission) or adding the permission to 
Configuration Admin's permissions.perm

Removing the call would be preferred.

 

Note that this bug breaks the OSGi Compliance Tests



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FELIX-6029) Felix Http Jetty does not have a service capability for the HttpService

[Timothy Ward (JIRA)]

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

Timothy Ward resolved FELIX-6029.
-
Resolution: Fixed

> Felix Http Jetty does not have a service capability for the HttpService
> ---
>
> Key: FELIX-6029
> URL: https://issues.apache.org/jira/browse/FELIX-6029
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-4.0.6
>Reporter: Timothy Ward
>Priority: Major
> Fix For: http.jetty-4.0.8
>
>
> The Felix Http Jetty bundle provides an HttpService service but does not have 
> a Provide-Capability for it. This prevents bundles which use the HttpService 
> from resolving when used with Felix Http Jetty.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Apache Felix Framework 6.0.2 and related subproject releases

[Timothy Ward]

+1

It all verifies and builds cleanly on my machine.

> On 28 Jan 2019, at 15:13, Jean-Baptiste Onofré  wrote:
> 
> +1 (binding)
> 
> Quickly tested on incoming Karaf 4.3.0 R7 branch.
> So far so good !
> 
> Thanks a lot !
> 
> Regards
> JB
> 
> On 28/01/2019 15:29, Karl Pauls wrote:
>> I would like to call a vote on the following subproject releases:
>> 
>> framework 6.0.2
>> main 6.0.2
>> main.distribution 6.0.2
>> 
>> The main changelogs are in jira and at:
>> https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.framework-6.0.2/doc/changelog.txt
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1280/
>> 
>> You can use this UNIX script to download the release and verify the 
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> 
>> Usage:
>> sh check_staged_release.sh 1280 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

[jira] [Created] (FELIX-6029) Felix Http Jetty does not have a service capability for the HttpService

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-6029:
---

 Summary: Felix Http Jetty does not have a service capability for 
the HttpService
 Key: FELIX-6029
 URL: https://issues.apache.org/jira/browse/FELIX-6029
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http.jetty-4.0.6
Reporter: Timothy Ward
 Fix For: http.jetty-4.0.8


The Felix Http Jetty bundle provides an HttpService service but does not have a 
Provide-Capability for it. This prevents bundles which use the HttpService from 
resolving when used with Felix Http Jetty.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5970) Add requirement & capabilities model so gogo can be resolved

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5970:
-

{quote}If you want me to add an annotation for that too, I will.
{quote}
 

I see this as the primary usage pattern for people providing commands into 
Gogo, so I think that something like a @RequireCommandWhiteboard or 
@RequireCommandRuntime is pretty important.

I'd be happy to add the ComponentPropertyType annotations too, that way we can 
make it really easy for people to build runtimes which provide custom Gogo 
commands using DS.

> Add requirement & capabilities model so gogo can be resolved
> 
>
> Key: FELIX-5970
> URL: https://issues.apache.org/jira/browse/FELIX-5970
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Command, Gogo JLine, Gogo Runtime, Gogo Shell
>Reporter: Raymond Augé
>Assignee: Raymond Augé
>Priority: Major
> Fix For: gogo.command-1.1.0, gogo.runtime-1.1.2, 
> gogo.shell-1.1.2, gogo.jline-1.1.2
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (FELIX-5970) Add requirement & capabilities model so gogo can be resolved

[Timothy Ward (JIRA)]

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

Timothy Ward edited comment on FELIX-5970 at 12/21/18 3:57 PM:
---

{quote}I've implemented it slightly differently. There's a gogo specific 
namespace called {{org.apache.felix.gogo}} and it is used to resolve the Gogo 
_love triangle_ (runtime, shell impl, command.)
{quote}
 

I'm not sure why this approach was taken. Gogo commands use a whiteboard model 
and so as someone contributing a Gogo command I would expect to use the 
osgi.implementation namespace to pull in a whiteboard implementation. 

I can understand that if you want to start doing *deep shell* work with live 
input or changing the colour of the text then you need something more akin to 
the model that you have defined, but what if I just want to provide a command 
that could be used with vanilla Gogo or JLine Gogo?

 

For something nicely usable I would expect to see the following annotations:

{{@Requirement(namespace="osgi.implementation" name="felix.gogo.command", 
version=1.0.0)}}

{{public @interface RequireCommandWhiteboard \{ }}}

 

{{@RequireCommandWhiteboard}}

{{@ComponentPropertyType}}

{{public @interface GogoCommand {}}

{{    public static final String _PREFIX = "osgi.command.";}}{{    }}

{{    public String scope();}}

{{    public String[] function();}}

{{}}}

 

These would then be used as follows:

 

{{@GogoCommand(scope="foo" function=\{"bar", "baz"})}}

{{@Component(service=MyCommand.class)}}

{{public class MyCommand {}}

{{    public String bar() \{ ... }}}

{{    public String baz(int n) \{ ... }}}

{{}}}


was (Author: timothyjward):
{quote}I've implemented it slightly differently. There's a gogo specific 
namespace called {{org.apache.felix.gogo}} and it is used to resolve the Gogo 
_love triangle_ (runtime, shell impl, command.)
{quote}
 

I'm not sure why this approach was taken. Gogo commands use a whiteboard model 
and so as someone contributing a Gogo command I would expect to use the 
osgi.implementation namespace to pull in a whiteboard implementation. 

I can understand that if you want to start doing *deep shell* work with live 
input or changing the colour of the text then you need something more akin to 
the model that you have defined, but what if I just want to provide a command 
that could be used with vanilla Gogo or JLine Gogo?

 

For something nicely usable I would expect to see the following annotations:

{{@Requirement(namespace="osgi.implementation" name="felix.gogo.command", 
version=1.0.0)}}

{{public @interface RequireCommandWhiteboard \{ }}}

 

{{@RequireCommandWhiteboard}}

{{@ComponentPropertyType}}

{{public @interface GogoCommand {}}{{    }}

{{    public static final String _PREFIX = "osgi.command.";}}{{    }}

{{    public String scope();}}{{    }}

{{    public String[] function();}}

{{}}}

 

These would then be used as follows:

 

{{@GogoCommand(scope="foo" function=\{"bar", "baz"})}}

{{@Component(service=MyCommand.class)}}

{{public class MyCommand {}}

{{    public String bar() \{ ... }}}

{{    public String baz(int n) \{ ... }}}

{{}}}

> Add requirement & capabilities model so gogo can be resolved
> 
>
> Key: FELIX-5970
> URL: https://issues.apache.org/jira/browse/FELIX-5970
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Command, Gogo JLine, Gogo Runtime, Gogo Shell
>Reporter: Raymond Augé
>Assignee: Raymond Augé
>Priority: Major
> Fix For: gogo.command-1.1.0, gogo.runtime-1.1.2, 
> gogo.shell-1.1.2, gogo.jline-1.1.2
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5970) Add requirement & capabilities model so gogo can be resolved

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5970:
-

{quote}I've implemented it slightly differently. There's a gogo specific 
namespace called {{org.apache.felix.gogo}} and it is used to resolve the Gogo 
_love triangle_ (runtime, shell impl, command.)
{quote}
 

I'm not sure why this approach was taken. Gogo commands use a whiteboard model 
and so as someone contributing a Gogo command I would expect to use the 
osgi.implementation namespace to pull in a whiteboard implementation. 

I can understand that if you want to start doing *deep shell* work with live 
input or changing the colour of the text then you need something more akin to 
the model that you have defined, but what if I just want to provide a command 
that could be used with vanilla Gogo or JLine Gogo?

 

For something nicely usable I would expect to see the following annotations:

{{@Requirement(namespace="osgi.implementation" name="felix.gogo.command", 
version=1.0.0)}}

{{public @interface RequireCommandWhiteboard \{ }}}

 

{{@RequireCommandWhiteboard}}

{{@ComponentPropertyType}}

{{public @interface GogoCommand {}}{{    }}

{{    public static final String _PREFIX = "osgi.command.";}}{{    }}

{{    public String scope();}}{{    }}

{{    public String[] function();}}

{{}}}

 

These would then be used as follows:

 

{{@GogoCommand(scope="foo" function=\{"bar", "baz"})}}

{{@Component(service=MyCommand.class)}}

{{public class MyCommand {}}

{{    public String bar() \{ ... }}}

{{    public String baz(int n) \{ ... }}}

{{}}}

> Add requirement & capabilities model so gogo can be resolved
> 
>
> Key: FELIX-5970
> URL: https://issues.apache.org/jira/browse/FELIX-5970
> Project: Felix
>  Issue Type: Improvement
>  Components: Gogo Command, Gogo JLine, Gogo Runtime, Gogo Shell
>Reporter: Raymond Augé
>Assignee: Raymond Augé
>Priority: Major
> Fix For: gogo.command-1.1.0, gogo.runtime-1.1.2, 
> gogo.shell-1.1.2, gogo.jline-1.1.2
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [ANN] New committer: Tim Ward

[Timothy Ward]

Thank you all, now I just need to find some more bugs to fix :)

Tim

> On 13 Nov 2018, at 17:10, Christian Schneider  wrote:
> 
> Welcome Tim. It is great to have you in the felix team now.
> 
> Christian
> 
> Am Di., 13. Nov. 2018 um 15:03 Uhr schrieb Karl Pauls :
> 
>> The Project Management Committee (PMC) for Apache Felix
>> has invited Tim Ward to become a committer and we are pleased
>> to announce that he has accepted.
>> 
>> Please welcome Tim.
>> 
>> Tim, you might want to introduce yourself.
>> 
> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Computer Scientist
> http://www.adobe.com

Re: [VOTE] Release Apache Felix SCR 2.1.14, Take II

[Timothy Ward]

+1 (non binding)

The signatures now check out, and the published sources build cleanly.

Tim

> On 11 Nov 2018, at 20:03, Christian Schneider  wrote:
> 
> +1 (non binding)
> 
> Christian
> 
> Am Sa., 10. Nov. 2018 um 11:18 Uhr schrieb Carsten Ziegeler <
> cziege...@apache.org>:
> 
>> We solved two issues in this release:
>> 
>> 
>> http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.scr-2.1.14/changelog.txt
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1270/
>> 
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> 
>> Usage:
>> sh check_staged_release.sh 1270 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>> 
> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Computer Scientist
> http://www.adobe.com

Re: [VOTE] Release Apache Felix SCR 2.1.14

[Timothy Ward]

When I attempt to run the checks it tells me that the GPG signature is bad… I 
may be doing something wrong, can anyone guess what it is?

Tim

> On 9 Nov 2018, at 16:11, Francois Papon  wrote:
> 
> +1 (non-binding)
> 
> Thanks!
> 
> regards,
> 
> François Papon
> fpa...@apache.org
> 
> Le 09/11/2018 à 17:09, Carsten Ziegeler a écrit :
>> We solved two issues in this release:
>> 
>> http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.scr-2.1.14/changelog.txt
>> 
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1269/
>> 
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> 
>> Usage:
>> sh check_staged_release.sh 1269 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> Regards
>> Carsten

[jira] [Created] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-5978:
---

 Summary: Felix framework unable to retrieve custom URL handlers 
when security is on
 Key: FELIX-5978
 URL: https://issues.apache.org/jira/browse/FELIX-5978
 Project: Felix
  Issue Type: Bug
Affects Versions: framework-6.0.1, framework-6.0.0
Reporter: Timothy Ward
 Fix For: framework-6.0.2


When running with multiple frameworks in the same VM, custom URL Handlers, and 
OSGi security on there are a couple of problems:

 

Firstly, this security exception results in the custom URL handler being 
ignored. The framework should really be using a doPriv here.
{code:java}
java.security.AccessControlException: access denied 
("java.lang.RuntimePermission" "getClassLoader")
at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
at java.lang.Class.getClassLoader(Class.java:683)
at 
org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
at 
org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
at 
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
at java.net.URL.toExternalForm(URL.java:929)
at java.net.URL.toString(URL.java:915)
at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
at 
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
at 
org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
at 
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at 
org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
{code}
Secondly, the wrong framework is returned some of the time due to the logic of 
URLHandlers.getFrameworkContext() - in this method it assumes that there will 
be a bundle class loader on the stack, which is not true when the launcher is 
starting a bundle (the framework reflectively loads the Activator type which 
requires a URL check to set the security domain).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5978) Felix framework unable to retrieve custom URL handlers when security is on

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5978:
-

{quote}Secondly, the wrong framework is returned some of the time due to the 
logic of URLHandlers.getFrameworkContext() - in this method it assumes that 
there will be a bundle class loader on the stack, which is not true when the 
launcher is starting a bundle (the framework reflectively loads the Activator 
type which requires a URL check to set the security domain).
{quote}
While it would be nice to fix this, I've thought more deeply about it and I'm 
really not sure whether it is possible to fix without a significant change to 
the Felix BundleClassLoader (basically to register the Framework that is 
associated with the current class load). I would like some advice as to whether 
people think this would be a good idea. [~karlpauls]?

> Felix framework unable to retrieve custom URL handlers when security is on
> --
>
> Key: FELIX-5978
> URL: https://issues.apache.org/jira/browse/FELIX-5978
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-6.0.0, framework-6.0.1
>    Reporter: Timothy Ward
>Priority: Critical
> Fix For: framework-6.0.2
>
>
> When running with multiple frameworks in the same VM, custom URL Handlers, 
> and OSGi security on there are a couple of problems:
>  
> Firstly, this security exception results in the custom URL handler being 
> ignored. The framework should really be using a doPriv here.
> {code:java}
> java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "getClassLoader")
> at 
> java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1528)
> at java.lang.Class.getClassLoader(Class.java:683)
> at 
> org.apache.felix.framework.URLHandlers.getFrameworkFromContext(URLHandlers.java:690)
> at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.getStreamHandlerService(URLHandlersStreamHandlerProxy.java:574)
> at 
> org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
> at java.net.URL.toExternalForm(URL.java:929)
> at java.net.URL.toString(URL.java:915)
> at java.lang.ClassLoader.defineClassSourceLocation(ClassLoader.java:678)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:762)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2344)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClassParallel(BundleWiringImpl.java:2162)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2096)
> at 
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
> at 
> org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
> at 
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at 
> org.apache.felix.cm.impl.ConfigurationManager.configure(ConfigurationManager.java:758)
> {code}
> Secondly, the wrong framework is returned some of the time due to the logic 
> of URLHandlers.getFrameworkContext() - in this method it assumes that there 
> will be a bundle class loader on the stack, which is not true when the 
> launcher is starting a bundle (the framework reflectively loads the Activator 
> type which requires a URL check to set the security domain).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5974) Prototype scope references are not released on deactivation

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5974:
-

I've updated the PR - hopefully this will now release the objects from the 
MultiplePrototypeRefPair as well as releasing the service instance.

> Prototype scope references are not released on deactivation
> ---
>
> Key: FELIX-5974
> URL: https://issues.apache.org/jira/browse/FELIX-5974
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.12
>Reporter: Timothy Ward
>Priority: Major
> Fix For: scr-2.1.14
>
>
> Having read the stack overflow question on [Stack 
> Overflow|https://stackoverflow.com/questions/52839641/osgi-ds-prototype-reference-not-released]
>  I was pretty certain that the user must be doing something wrong, but in 
> fact it seems as though SCR does a bad job of releasing Prototype scoped 
> references when a component is disposed.
> I looked into the code, and it seems that there are a lot of conflicting 
> locations where prototype scope services are obtained and released. I propose 
> tidying this up so that the ComponentServiceObjects is *always* used 
> internally regardless of whether it is injected or not. This encapsulates all 
> the access in a single location so it is less likely that the objects will 
> leak.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FELIX-5974) Prototype scope references are not released on deactivation

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-5974:
---

 Summary: Prototype scope references are not released on 
deactivation
 Key: FELIX-5974
 URL: https://issues.apache.org/jira/browse/FELIX-5974
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions: scr-2.1.12
Reporter: Timothy Ward
 Fix For: scr-2.1.14


Having read the stack overflow question on [Stack 
Overflow|https://stackoverflow.com/questions/52839641/osgi-ds-prototype-reference-not-released]
 I was pretty certain that the user must be doing something wrong, but in fact 
it seems as though SCR does a bad job of releasing Prototype scoped references 
when a component is disposed.

I looked into the code, and it seems that there are a lot of conflicting 
locations where prototype scope services are obtained and released. I propose 
tidying this up so that the ComponentServiceObjects is *always* used internally 
regardless of whether it is injected or not. This encapsulates all the access 
in a single location so it is less likely that the objects will leak.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Felix scr version 2.1.10

[Timothy Ward]

+1 (non binding)

> On 5 Oct 2018, at 09:05, Pierre De Rop  wrote:
> 
> Hello,
> 
> +1
> 
> thanks Raymond
> 
> On Thu, Oct 4, 2018 at 9:43 AM Grzegorz Grzybek 
> wrote:
> 
>> +1 (non-binding)
>> 
>> regards
>> Grzegorz Grzybek
>> 
>> czw., 4 paź 2018 o 09:38 David Bosschaert 
>> napisał(a):
>> 
>>> +1
>>> 
>>> David
>>> 
>>> On Wed, 3 Oct 2018 at 22:41, Raymond Auge 
>>> wrote:
>>> 
 Hi,
 
 We fixed 3 issues in this release:
 
 
>>> 
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20FELIX%20AND%20fixVersion%20%3D%20scr-2.1.10
 
 Staging repository:
 
>> https://repository.apache.org/content/repositories/orgapachefelix-1262/
 
 You can use this UNIX script to download the release and verify the
 signatures:
 http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
 
 Usage:
 sh check_staged_release.sh 1262 /tmp/felix-staging
 
 Please vote to approve this release:
 
 [ ] +1 Approve the release
 [ ] -1 Veto the release (please provide specific comments)
 
 This vote will be open for 72 hours.
 
 --
 *Raymond Augé* 
 (@rotty3000)
 Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
 Board Member & EEG Co-Chair, OSGi Alliance 
 (@OSGiAlliance)
 
>>> 
>> 

Re: [VOTE] Release Felix configadmin version 1.9.8

[Timothy Ward]

+1 (non binding)

> On 5 Oct 2018, at 08:53, Pierre De Rop  wrote:
> 
> Hello;
> 
> +1
> 
> thanks Raymond
> Pierre
> 
> On Thu, Oct 4, 2018 at 9:43 AM Grzegorz Grzybek 
> wrote:
> 
>> +1 (non-binding)
>> 
>> regards
>> Grzegorz Grzybek
>> 
>> czw., 4 paź 2018 o 09:38 David Bosschaert 
>> napisał(a):
>> 
>>> +1
>>> 
>>> David
>>> 
>>> On Wed, 3 Oct 2018 at 23:24, Raymond Auge 
>>> wrote:
>>> 
 Hi,
 
 We fixed 3 issues in this release:
 FELIX-5949 
 Configuration
 _updates_ are ignored when using a NotCachablePersistenceManager
 
 Staging repository:
 https://repository.apache.org/content/repositories/orgapachefelix-1263
 
 You can use this UNIX script to download the release and verify the
 signatures:
 http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
 
 Usage:
 sh check_staged_release.sh 1263 /tmp/felix-staging
 
 Please vote to approve this release:
 
 [ ] +1 Approve the release
 [ ] -1 Veto the release (please provide specific comments)
 
 This vote will be open for 72 hours.
 
 --
 *Raymond Augé* 
 (@rotty3000)
 Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
 Board Member & EEG Co-Chair, OSGi Alliance 
 (@OSGiAlliance)
 
>>> 
>> 

[jira] [Commented] (FELIX-5911) [Configurator] Too restrictive permissions.perm file

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5911:
-

{quote}[~timothyjward]: as far as I understand the set of permissions granted 
by the system admin/the person launching the framework can only be a subset of 
the permissions requested in the permissions.perm file. More precisely, the 
effective set of permissions is the intersection of the ones in 
permissions.perm and the ones granted by the admin. It is hence not possible to 
configure additional permissions. Did I get this wrong?
{quote}
 

You can still use PermissionAdmin/ConditionalPermissionAdmin to control the 
permissions of a bundle and grant them wider permissions than they would 
otherwise have. You are correct, however that the permissions for a bundle 
cannot expand beyond those of the Java runtime as a whole.

> [Configurator] Too restrictive permissions.perm file
> 
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5911) [Configurator] request FilePermission <>

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5911:
-

This permission request seems wrong. By default the OSGi framework should grant 
access to the bundle storage area ([see the security section in the core 
specification 
title|[https://osgi.org/specification/osgi.core/7.0.0/framework.security.html#framework.security.impliedpermissions]).]
 I'm not sure why the bundle should need to request other file permissions at 
all.

 

I would also really like to see reflection removed as it really shouldn't be 
necessary. The bundle is in complete control of the serialization, so I'm not 
sure why it hasn't been written purely using DataInput/DataOutput. There aren't 
any cycles, and none of the default serialisation behaviour is in use. To my 
mind this could (and should) all be re-implemented without any need for 
reflection, even while maintaining backward compatibility with existing saved 
data.

 

Finally, the additional permissions needed when the "configurator.initial" 
property is set need to be granted by the person launching the framework. They 
know that they have set security on, and what they have sent the 
configurator.initial property to. The Configurator bundle shouldn't be opening 
up the base options for this.

> [Configurator] request FilePermission <>
> ---
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Apache Felix Metatype 1.2.2

[Timothy Ward]

+1 (non-binding)

> On 24 Sep 2018, at 11:26, Francois Papon  wrote:
> 
> +1 (non-binding)
> 
> Thanks !
> 
> Regards,
> 
> François Papon
> fpa...@apache.org
> 
> Le 23/09/2018 à 13:34, Carsten Ziegeler a écrit :
>> Hi all,
>> 
>> we fixed one issue:
>> https://issues.apache.org/jira/browse/FELIX-5936
>> 
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1261/
>> 
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> 
>> Usage:
>> sh check_staged_release.sh 1261 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> This vote will be open for at least 72 hours.
>> 
>> Regards
>> Carsten
> 

Re: [VOTE] Felix Converter 1.0.2

[Timothy Ward]

+ 1 (non binding)

Tim Ward

> On 20 Sep 2018, at 13:04, Raymond Auge  wrote:
> 
> +1
> 
> - Ray
> 
> On Thu, Sep 20, 2018, 04:41 Karl Pauls,  wrote:
> 
>> +1
>> 
>> regards,
>> 
>> Karl
>> On Thu, Sep 20, 2018 at 10:37 AM  wrote:
>>> 
>>> Here's my +1
>>> 
>>> David
>>> 
>>> On Thu, 20 Sep 2018 at 10:29,  wrote:
>>> 
 Hi all,
 
 I would like to call a vote on the Felix Converter version 1.0.2
 
 The following issue was fixed:
 FELIX-5923 Conversion from Map to single element Annotation type does
>> not
 incorporate PREFIX_
 
 Staging repositories:
 
>> https://repository.apache.org/content/repositories/orgapachefelix-1260/
 
 You can use this UNIX script to download the release and verify the
 signatures:
 http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
 
 Usage:
 sh check_staged_release.sh 1260 /tmp/felix-staging
 
 Please vote to approve this release:
 
 [ ] +1 Approve the release
 [ ] -1 Veto the release (please provide specific comments)
 
 This vote will be open for at least 72 hours.
 
 Best regards,
 
 David Bosschaert
 
 
>> 
>> 
>> 
>> --
>> Karl Pauls
>> karlpa...@gmail.com
>> 

Re: [VOTE] Release Apache Felix SCR 2.1.8 and Webconsole DS Plugin 2.1.0

[Timothy Ward]

+1 (non binding)

Tim Ward

> On 20 Sep 2018, at 09:32, Karl Pauls  wrote:
> 
> +1
> 
> regards,
> 
> Karl
> On Wed, Sep 19, 2018 at 10:03 PM Carsten Ziegeler  
> wrote:
>> 
>> We solved six issues in the SCR release:
>> 
>> http://svn.apache.org/repos/asf/felix/releases/org.apache.felix.scr-2.1.8/changelog.txt
>> 
>> And one issue in the webconsole plugin release:
>> https://issues.apache.org/jira/browse/FELIX-5841
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1258/
>> 
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> 
>> Usage:
>> sh check_staged_release.sh 1258 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
> 
> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com

Re: [VOTE] Release Apache Felix Configurator 1.0.6

[Timothy Ward]

+ 1 (non binding)

Tim Ward

> On 20 Sep 2018, at 09:26, Karl Pauls  wrote:
> 
> +1
> 
> regards,
> 
> Karl
> On Wed, Sep 19, 2018 at 9:34 PM Carsten Ziegeler  wrote:
>> 
>> We solved one issue in this release:
>> 
>> https://issues.apache.org/jira/browse/FELIX-5932
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1257/
>> 
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> 
>> Usage:
>> sh check_staged_release.sh 1257 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> Regards
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
> 
> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com

Re: [VOTE] Release Apache Felix Configadmin 1.9.6

[Timothy Ward]

+1 (non-binding)

> On 14 Sep 2018, at 13:25, Karl Pauls  wrote:
> 
> +1
> 
> regards,
> 
> Karl
> On Fri, Sep 14, 2018 at 2:24 PM Raymond Auge  wrote:
>> 
>> +1
>> 
>> - Ray
>> 
>> On Fri, Sep 14, 2018, 06:16 Francois Papon, 
>> wrote:
>> 
>>> +1 (non-binding)
>>> 
>>> Thanks for the release.
>>> 
>>> Regards,
>>> 
>>> François Papon
>>> fpa...@apache.org
>>> 
>>> Le 14/09/2018 à 10:16, Carsten Ziegeler a écrit :
 We solved two issues in this release:
 
 
>>> https://svn.apache.org/repos/asf/felix/releases/org.apache.felix.configadmin-1.9.6/changelog.txt
 
 Staging repositories:
 https://repository.apache.org/content/repositories/orgapachefelix-1254/
 
 You can use this UNIX script to download the release and verify the
 signatures:
 http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
 
 Usage:
 sh check_staged_release.sh 1254 /tmp/felix-staging
 
 Please vote to approve this release:
 
 [ ] +1 Approve the release
 [ ] -1 Veto the release (please provide specific comments)
 
 Regards
 Carsten
>>> 
>>> 
> 
> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com

[jira] [Commented] (FELIX-5910) [ConfigAdmin] Set correct AccessControlContext when firing events

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5910:
-

{quote}Thanks, yes this looks like a SCR bug
{quote}
 

I agree with this. SCR should definitely be removing itself from the stack by 
setting the relevant access control context before calling any lifecycle 
methods on the component. Otherwise SCR requires AllPermission (which is 
probably what it has if nobody has created a proper permissions file for it) 
which is a bad thing.

> [ConfigAdmin] Set correct AccessControlContext when firing events
> -
>
> Key: FELIX-5910
> URL: https://issues.apache.org/jira/browse/FELIX-5910
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.9.4
> Environment: - Felix fwk 6.0.0 
> - Felix security 2.6.0
> - Felix config admin 1.9.4 and 1.9.5-SNAPSHOT
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configadmin-1.9.6
>
>
> ConfigAdmin requests a restricted set of permissions by means of a 
> permissions.perm file, which must not restrict the permissions of other 
> bundles to which it sends events. There is in fact a mechanism in place to 
> prevent this, using the protection domain of the bundle, in the class 
> ManagedServiceTracker (resolving the related issue 
> https://issues.apache.org/jira/browse/FELIX-4362). However, the UpdateThread 
> class does not use this mechanism; instead it explicitly sets an 
> AccessControlContext based on its own protection domain, hence enforcing its 
> own restricted set of permissions to the event listeners. Below are two 
> examples of the resulting AccessControlExceptions I get... there is just one 
> additional bundle in the stack trace, felix-scr, which has all permissions 
> and can be ignored from the permissions point of view. 
> By the way, removing the permissions.perm file from ConfigAdmin resolves the 
> problem, confirming that the bug is indeed in ConfigAdmin. 
> rg.slf4j.osgi-over-slf4j[org.apache.felix.configadmin.1.9.4] : 
> [[org.osgi.service.cm.ConfigurationAdmin]]Unexpected problem delivering 
> configuration event to [org.osgi.service.cm.ConfigurationListener, id=18, 
> bundle=24/mvn:org.apache.felix/org.apache.felix.configadmin/1.9.4]
> java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "getClassLoader")
>  at 
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>  at 
> java.base/java.security.AccessController.checkPermission(AccessController.java:895)
>  at 
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:335)
>  at 
> java.base/java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:2042)
>  at java.base/java.lang.Class.getClassLoader(Class.java:807)
>  at 
> org.apache.felix.scr.impl.inject.methods.BaseMethod.findMethod(BaseMethod.java:158)
>  at 
> org.apache.felix.scr.impl.inject.methods.BaseMethod.access$400(BaseMethod.java:41)
>  at 
> org.apache.felix.scr.impl.inject.methods.BaseMethod$NotResolved.resolve(BaseMethod.java:602)
>  at 
> org.apache.felix.scr.impl.inject.methods.BaseMethod$NotResolved.methodExists(BaseMethod.java:626)
>  at 
> org.apache.felix.scr.impl.inject.methods.BaseMethod.methodExists(BaseMethod.java:528)
>  at 
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:315)
>  at 
> org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307)
>  at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.invokeModifiedMethod(SingleComponentManager.java:810)
>  at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.modify(SingleComponentManager.java:765)
>  at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:683)
>  at 
> org.apache.felix.scr.impl.manager.SingleComponentManager.reconfigure(SingleComponentManager.java:647)
>  at 
> org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.configurationUpdated(ConfigurableComponentHolder.java:435)
>  at 
> org.apache.felix.scr.impl.manager.RegionConfigurationSupport.configurationEvent(RegionConfigurationSupport.java:288)
>  at 
> org.apache.felix.scr.impl.manager.RegionConfigurationSupport$1.configurationEvent(RegionConfigurationSupport.java:91)
>  at 
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationMana

[jira] [Commented] (FELIX-5010) NPE when resolving bundle with a header "Bundle-NativeCode = *"

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5010:
-

Please ignore the above PR addition - It was supposed to reference FELIX-5910

> NPE when resolving bundle with a header "Bundle-NativeCode = *"
> ---
>
> Key: FELIX-5010
> URL: https://issues.apache.org/jira/browse/FELIX-5010
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-5.0.1
>Reporter: Guillaume Nodet
>Assignee: Bob Paulin
>Priority: Major
> Fix For: framework-5.2.0
>
>
> {code}
> java.lang.NullPointerException
>   at 
> org.apache.felix.framework.capabilityset.CapabilitySet.match(CapabilitySet.java:197)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.framework.capabilityset.CapabilitySet.match(CapabilitySet.java:187)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.framework.StatefulResolver.findProvidersInternal(StatefulResolver.java:229)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.framework.ResolveContextImpl.findProviders(ResolveContextImpl.java:89)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.resolver.Candidates.populate(Candidates.java:198)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:199)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:140)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:431)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.framework.Felix.resolveBundles(Felix.java:4073)[org.apache.felix.framework-5.0.1.jar:]
>   at 
> org.apache.felix.framework.FrameworkWiringImpl.resolveBundles(FrameworkWiringImpl.java:133)[org.apache.felix.framework-5.0.1.jar:]
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Release of Configuration Admin

[Timothy Ward]

I have cross-checked and all looks good. I also put together a test for the 
AccessControlContext being set, both for MSF (which has been working for a long 
time but not explicitly tested) and for ConfigurationListener, which was broken 
until your fix (I reverted locally and saw the failure).

The test is available at https://github.com/apache/felix/pull/154 - Feel free 
to integrate it if you think it would be useful as a regression check.

Tim

On 12 Sep 2018, at 11:22, Carsten Ziegeler 
mailto:cziege...@apache.org>> wrote:

I've applied potential fixes for those issues. It would be great if you
could cross check them as well, Tim

Regards

Carsten


Carsten Ziegeler wrote
Hi,

it would be great if we could also fix FELIX-5918 and  FELIX-5910 and
then hopefully have addressed all security related issues.

So if someone can provide patches for those, this would be preferred.

In any case I can kick of the release end of this week

Regards

Carsten


Timothy Ward wrote
Hi all,

I’m aware that there’s only been one bug fixed in Config Admin since the last 
release at the end of July, but I’m quite keen to see it available in a 
released version. I’ve created a PR (https://github.com/apache/felix/pull/153) 
to update the dependency versions in 1.9.5-SNAPSHOT so that it can be released. 
Is someone able to do the honours?

Thanks,

Tim

--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org<mailto:cziege...@apache.org>

Release of Configuration Admin

[Timothy Ward]

Hi all,

I’m aware that there’s only been one bug fixed in Config Admin since the last 
release at the end of July, but I’m quite keen to see it available in a 
released version. I’ve created a PR (https://github.com/apache/felix/pull/153) 
to update the dependency versions in 1.9.5-SNAPSHOT so that it can be released. 
Is someone able to do the honours?

Thanks,

Tim

Re: Session invalidation

[Timothy Ward]

My thought was that by hooking into the Jetty handlers it wouldn’t be necessary 
to do any work with the session cookie, effectively making the SessionIdManager 
“OSGi HttpContext aware” so that different contexts create and/or get different 
sessions back. It’s possible that this isn’t sufficient though.

Tim

> On 23 Aug 2018, at 10:50, Carsten Ziegeler  wrote:
> 
> Hi,
> 
> potentially yes, as mentioned we could do this in the Jetty case.
> However, it might require a little bit more like ensuring that the
> virtual id is correctly used for rewriting urls/managing the session cookie.
> 
> 
> Regards
> 
> Carsten
> 
> 
> Timothy Ward wrote
>> Would it not be sufficient to generate a virtual session id for each session 
>> in the whiteboard? This should be possible by customising the Whiteboard’s 
>> SessionIdManager<https://www.eclipse.org/jetty/javadoc/9.4.8.v20171121/org/eclipse/jetty/server/SessionIdManager.html>
>>  and 
>> SessionCache<http://www.eclipse.org/jetty/javadoc/9.4.6.v20170531/org/eclipse/jetty/server/session/SessionCache.html>.
>>  Obviously this won’t help you when you’re running in a nested whiteboard, 
>> but it should let you provide separate native Jetty Sessions despite 
>> multiplexing.
>> 
>> Tim
>> 
>> On 23 Aug 2018, at 07:19, Carsten Ziegeler 
>> mailto:cziege...@apache.org>> wrote:
>> 
>> I remember a similar discussion about session handling some time ago,
>> but couldn't find it anymore. I would like to start by describing how it
>> works today.
>> 
>> The http implementation is registering a single servlet context in the
>> container (jetty in standalone mode and an app server/servlet engine in
>> bridged mode running as a webapp) and as the container is managing the
>> session, there is only a single session regardless of what the http
>> implementation does.
>> 
>> The http implementation generates one or more http contexts which can be
>> seen as child contexts of the container servlet context. There is one
>> for everything registered through the http service and using the http
>> whiteboard you'll have at least one more, but might have a set of
>> additional ones. All these contexts share the single container session.
>> In a bridged scenario the session might even be shared with something
>> running outside of the OSGi container in the app server.
>> 
>> Each of these http contexts has its own "local" session which can be
>> created and invalidated. In order to leverage the container session
>> handling, these local sessions make use of the container session. Due to
>> that if you invalidate such a local session, the surrounding container
>> session is not invalidated as this local session has no idea whether
>> anyone else is also using the container session.
>> 
>> Before FELIX-5819, there was the assumption that if there is nothing
>> else stored in the container session, the container session can be
>> invalidated. But that's a weak assumption, it is right in most cases but
>> wrong in some others.
>> 
>> In the general case I think we can't work around the single container
>> session. We might be able to create more than one session with a Jetty
>> based implementation but not in the bridged case. And having separate
>> sessions per http context poses new problems as this prohibits
>> exchanging information between different http contexts for a session.
>> 
>> As a immediate workaround we could add the old behaviour back in again -
>> which invalidates the container session if its empty and make this
>> configurable. That should solve your immediate problem.
>> 
>> But to be honest, I'm unsure what the right solution should look like.
>> 
>> Regards
>> 
>> Carsten
>> 
>> 
>> Rob Walker wrote
>> Carsten
>> 
>> Been pondering this one some more and thrown some notes down below. Caveat 
>> to all of them though: I am not so familiar with the recent Felix codebase 
>> in this area; and my experience of real-world HTTP security definitely has 
>> gaps!
>> 
>> So my take is that some apps (obviously not many as we're the 1st to hit 
>> this in 6 months since the change!) would expected a session invalidate() to 
>> destroy every aspect of that session. All attributes definitely, and also 
>> most would expect the ID to be destroyed and not re-used. I haven't checked 
>> the Servlet or HTTP specs for that last part, maybe it isn’t stated in a 
>> contract anywhere. I could certainly see apps that hold their session 
>> information in 

Re: Session invalidation

[Timothy Ward]

Would it not be sufficient to generate a virtual session id for each session in 
the whiteboard? This should be possible by customising the Whiteboard’s 
SessionIdManager
 and 
SessionCache.
 Obviously this won’t help you when you’re running in a nested whiteboard, but 
it should let you provide separate native Jetty Sessions despite multiplexing.

Tim

On 23 Aug 2018, at 07:19, Carsten Ziegeler 
mailto:cziege...@apache.org>> wrote:

I remember a similar discussion about session handling some time ago,
but couldn't find it anymore. I would like to start by describing how it
works today.

The http implementation is registering a single servlet context in the
container (jetty in standalone mode and an app server/servlet engine in
bridged mode running as a webapp) and as the container is managing the
session, there is only a single session regardless of what the http
implementation does.

The http implementation generates one or more http contexts which can be
seen as child contexts of the container servlet context. There is one
for everything registered through the http service and using the http
whiteboard you'll have at least one more, but might have a set of
additional ones. All these contexts share the single container session.
In a bridged scenario the session might even be shared with something
running outside of the OSGi container in the app server.

Each of these http contexts has its own "local" session which can be
created and invalidated. In order to leverage the container session
handling, these local sessions make use of the container session. Due to
that if you invalidate such a local session, the surrounding container
session is not invalidated as this local session has no idea whether
anyone else is also using the container session.

Before FELIX-5819, there was the assumption that if there is nothing
else stored in the container session, the container session can be
invalidated. But that's a weak assumption, it is right in most cases but
wrong in some others.

In the general case I think we can't work around the single container
session. We might be able to create more than one session with a Jetty
based implementation but not in the bridged case. And having separate
sessions per http context poses new problems as this prohibits
exchanging information between different http contexts for a session.

As a immediate workaround we could add the old behaviour back in again -
which invalidates the container session if its empty and make this
configurable. That should solve your immediate problem.

But to be honest, I'm unsure what the right solution should look like.

Regards

Carsten


Rob Walker wrote
Carsten

Been pondering this one some more and thrown some notes down below. Caveat to 
all of them though: I am not so familiar with the recent Felix codebase in this 
area; and my experience of real-world HTTP security definitely has gaps!

So my take is that some apps (obviously not many as we're the 1st to hit this 
in 6 months since the change!) would expected a session invalidate() to destroy 
every aspect of that session. All attributes definitely, and also most would 
expect the ID to be destroyed and not re-used. I haven't checked the Servlet or 
HTTP specs for that last part, maybe it isn’t stated in a contract anywhere. I 
could certainly see apps that hold their session information in some external 
cache not in attributes getting tripped up with narrow timing windows where an 
old session ID comes in again before a cache is cleared. Bad coding by that app 
- sure, almost certainly. But also caught out by non-standard behaviour.

Of course it sounds like we have just as many if not more HTTP whiteboard users 
that would get caught by this changed. I'm not going to argue the current 
re-use of IDs is wrong, and that we need to refactor since we risk breaking 
things for these users, and that is just as bad.

So my proposal is (hopefully) a simple one. We add a property that lets users 
(like us) tripped up by the wrapper behaviour, have the raw Jetty Session 
object returned rather than the wrapper. That way no Felix code gets in the way 
of normal Jetty handling for those not using HTTP whiteboard.

Looking at the code, I think there's a very small number of places this would 
change. Obviously getSession() is one. And then in Dispatcher we'd need to do 
an instanceof test in dispatch before calling getExpiredSessionContextNames. 
And I think again something similar in ServiceController.

We could of course add a higher level wrapper, but that seems to get 
heavyweight.

One added benefit of the above is it allows use of the normal Jetty 
SecureHandler code which does an automatic session invalidate/renew as part of 
the auth steps. But this gets torpedoed by the use of the Felix 

Re: [VOTE] Apache Felix Framework 6.0.1 and related subproject releases

[Timothy Ward]

+1 (non binding)

Sent from my iPhone

> On 16 Aug 2018, at 14:24, Raymond Auge  wrote:
> 
> +1
> 
> - Ray
> 
> On Thu, Aug 16, 2018 at 8:57 AM, Christian Schneider <
> ch...@die-schneider.net> wrote:
> 
>> +1 (non binding)
>> 
>> Christian
>> 
>> Am Do., 16. Aug. 2018 um 12:37 Uhr schrieb Karl Pauls >> :
>> 
>>> I would like to call a vote on the following subproject releases:
>>> 
>>> framework 6.0.1
>>> framework.security 2.6.1
>>> main 6.0.1
>>> main.distribution 6.0.1
>>> 
>>> The main changelogs are in jira and at:
>>> 
>>> https://svn.apache.org/repos/asf/felix/releases/org.apache.
>> felix.framework.security-2.6.1/doc/changelog.txt
>>> 
>>> https://svn.apache.org/repos/asf/felix/releases/org.apache.
>> felix.framework-6.0.1/doc/changelog.txt
>>> 
>>> Staging repositories:
>>> https://repository.apache.org/content/repositories/orgapachefelix-1246/
>>> 
>>> You can use this UNIX script to download the release and verify the
>>> signatures:
>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>> 
>>> Usage:
>>> sh check_staged_release.sh 1246 /tmp/felix-staging
>>> 
>>> Please vote to approve this release:
>>> 
>>> [ ] +1 Approve the release
>>> [ ] -1 Veto the release (please provide specific comments)
>>> 
>> 
>> 
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> 
>> Computer Scientist
>> http://www.adobe.com
>> 
> 
> 
> 
> -- 
> *Raymond Augé* 
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

[jira] [Commented] (FELIX-5908) NoClassDefFoundError for the CM Security Domain combiner

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5908:
-

[~cziegeler] the other option would be update the ConfigurationTestBase 
installBundle method to add a dummy file into the generated test bundles. 

Adding a dummy file makes these bundles not “manifest only” and therefore 
avoids FELIX-5906 blowing up the tests. If this change is made then security 
2.6.0 can be used. 

I avoided working around that bug in the patch as it wasn’t part of the minimum 
necessary changes for testing/fixing, and I figured the test changes were 
complex enough already!

> NoClassDefFoundError for the CM Security Domain combiner
> 
>
> Key: FELIX-5908
> URL: https://issues.apache.org/jira/browse/FELIX-5908
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.9.4
>Reporter: Timothy Ward
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configadmin-1.9.6
>
>
> This is a pretty weird bug, so I'll try to explain it.
> When running with security on the Configuration Admin Updater thread applies 
> an Access Control Context which, amongst other things, sets up a Domain 
> Combiner. This Domain Combiner lazily creates a combined Protection Domain 
> based on the target bundle.
>  
> All of this works fine until you end up in the following situation:
>  # The MS/MSF being called attempts to perform a checked operation (for which 
> they may or may not have permission)
>  # The Check causes the CM Domain Combiner to be instantiated, triggering a 
> class load if it is the first time
>  # The Loading of the class can then trigger *more* security checks in some 
> cases, for example setting the CodeSource of the class being defined can 
> require a security check if there are multiple frameworks in the VM, or if 
> the code was installed from a custom URL handler that has a custom 
> toExternalForm() implementation
>  # This security check retrievers the CM Domain Combiner, which attempts to 
> load the class again
>  # The Java ClassLoader detects the cycle and throws a NoClassDefFoundError
>  
> I am setting up a "simple" test demonstrating this (it necessarily has 
> several moving parts) and a proposed patch.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5908) NoClassDefFoundError for the CM Security Domain combiner

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5908:
-

The attached GitHub Pull Request contains two commits, the first containing 
tests demonstrating the issue, the second containing a fix for the issue

> NoClassDefFoundError for the CM Security Domain combiner
> 
>
> Key: FELIX-5908
> URL: https://issues.apache.org/jira/browse/FELIX-5908
> Project: Felix
>  Issue Type: Bug
>  Components: Configuration Admin
>Affects Versions: configadmin-1.9.4
>Reporter: Timothy Ward
>Priority: Major
>
> This is a pretty weird bug, so I'll try to explain it.
> When running with security on the Configuration Admin Updater thread applies 
> an Access Control Context which, amongst other things, sets up a Domain 
> Combiner. This Domain Combiner lazily creates a combined Protection Domain 
> based on the target bundle.
>  
> All of this works fine until you end up in the following situation:
>  # The MS/MSF being called attempts to perform a checked operation (for which 
> they may or may not have permission)
>  # The Check causes the CM Domain Combiner to be instantiated, triggering a 
> class load if it is the first time
>  # The Loading of the class can then trigger *more* security checks in some 
> cases, for example setting the CodeSource of the class being defined can 
> require a security check if there are multiple frameworks in the VM, or if 
> the code was installed from a custom URL handler that has a custom 
> toExternalForm() implementation
>  # This security check retrievers the CM Domain Combiner, which attempts to 
> load the class again
>  # The Java ClassLoader detects the cycle and throws a NoClassDefFoundError
>  
> I am setting up a "simple" test demonstrating this (it necessarily has 
> several moving parts) and a proposed patch.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FELIX-5908) NoClassDefFoundError for the CM Security Domain combiner

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-5908:
---

 Summary: NoClassDefFoundError for the CM Security Domain combiner
 Key: FELIX-5908
 URL: https://issues.apache.org/jira/browse/FELIX-5908
 Project: Felix
  Issue Type: Bug
  Components: Configuration Admin
Affects Versions: configadmin-1.9.4
Reporter: Timothy Ward


This is a pretty weird bug, so I'll try to explain it.

When running with security on the Configuration Admin Updater thread applies an 
Access Control Context which, amongst other things, sets up a Domain Combiner. 
This Domain Combiner lazily creates a combined Protection Domain based on the 
target bundle.

 

All of this works fine until you end up in the following situation:
 # The MS/MSF being called attempts to perform a checked operation (for which 
they may or may not have permission)
 # The Check causes the CM Domain Combiner to be instantiated, triggering a 
class load if it is the first time
 # The Loading of the class can then trigger *more* security checks in some 
cases, for example setting the CodeSource of the class being defined can 
require a security check if there are multiple frameworks in the VM, or if the 
code was installed from a custom URL handler that has a custom toExternalForm() 
implementation
 # This security check retrievers the CM Domain Combiner, which attempts to 
load the class again
 # The Java ClassLoader detects the cycle and throws a NoClassDefFoundError

 

I am setting up a "simple" test demonstrating this (it necessarily has several 
moving parts) and a proposed patch.

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-5906) Intstalling Manifest only bundles causes ArrayIndexOutOfBoundsException from Felix Security

[Timothy Ward (JIRA)]

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

Timothy Ward updated FELIX-5906:

Component/s: Framework Security

> Intstalling Manifest only bundles causes ArrayIndexOutOfBoundsException from 
> Felix Security
> ---
>
> Key: FELIX-5906
> URL: https://issues.apache.org/jira/browse/FELIX-5906
> Project: Felix
>  Issue Type: Bug
>  Components: Framework Security
>Affects Versions: framework.security-2.6.0
>    Reporter: Timothy Ward
>Priority: Major
>
> The Felix security Provider returns an empty array, rather than null when 
> [finding 
> certificates|[https://github.com/apache/felix/blob/trunk/framework.security/src/main/java/org/apache/felix/framework/security/verifier/BundleDNParser.java#L274].]
>  This then causes an ArrayIndexOutOfBoundsException when [this 
> line|https://github.com/apache/felix/blob/trunk/framework.security/src/main/java/org/apache/felix/framework/security/verifier/BundleDNParser.java#L475]
>  is reached



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-5906) Intstalling Manifest only bundles causes ArrayIndexOutOfBoundsException from Felix Security

[Timothy Ward (JIRA)]

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

Timothy Ward updated FELIX-5906:

Affects Version/s: framework.security-2.6.0

> Intstalling Manifest only bundles causes ArrayIndexOutOfBoundsException from 
> Felix Security
> ---
>
> Key: FELIX-5906
> URL: https://issues.apache.org/jira/browse/FELIX-5906
> Project: Felix
>  Issue Type: Bug
>  Components: Framework Security
>Affects Versions: framework.security-2.6.0
>    Reporter: Timothy Ward
>Priority: Major
>
> The Felix security Provider returns an empty array, rather than null when 
> [finding 
> certificates|[https://github.com/apache/felix/blob/trunk/framework.security/src/main/java/org/apache/felix/framework/security/verifier/BundleDNParser.java#L274].]
>  This then causes an ArrayIndexOutOfBoundsException when [this 
> line|https://github.com/apache/felix/blob/trunk/framework.security/src/main/java/org/apache/felix/framework/security/verifier/BundleDNParser.java#L475]
>  is reached



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FELIX-5906) Intstalling Manifest only bundles causes ArrayIndexOutOfBoundsException from Felix Security

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-5906:
---

 Summary: Intstalling Manifest only bundles causes 
ArrayIndexOutOfBoundsException from Felix Security
 Key: FELIX-5906
 URL: https://issues.apache.org/jira/browse/FELIX-5906
 Project: Felix
  Issue Type: Bug
Reporter: Timothy Ward


The Felix security Provider returns an empty array, rather than null when 
[finding 
certificates|[https://github.com/apache/felix/blob/trunk/framework.security/src/main/java/org/apache/felix/framework/security/verifier/BundleDNParser.java#L274].]
 This then causes an ArrayIndexOutOfBoundsException when [this 
line|https://github.com/apache/felix/blob/trunk/framework.security/src/main/java/org/apache/felix/framework/security/verifier/BundleDNParser.java#L475]
 is reached



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release Configadmin 1.9.4

[Timothy Ward]

+1 (non-binding)

> On 31 Jul 2018, at 09:23, Neil Bartlett  wrote:
> 
> +1 non-binding
> 
>> On 31 Jul 2018, at 07:12, Carsten Ziegeler  wrote:
>> 
>> The following issue has been fixed for this release:
>> 
>> https://issues.apache.org/jira/browse/FELIX-5892
>> 
>> 
>> 
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1239/
>> 
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>> 
>> Usage:
>> sh check_staged_release.sh 1239 /tmp/felix-staging
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> Regards
>> Carsten
>> -- 
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
> 

[jira] [Created] (FELIX-5892) Repeated calls to getFactoryConfiguration return different configuration instances

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-5892:
---

 Summary: Repeated calls to getFactoryConfiguration return 
different configuration instances
 Key: FELIX-5892
 URL: https://issues.apache.org/jira/browse/FELIX-5892
 Project: Felix
  Issue Type: Bug
  Components: Configuration Admin
Affects Versions: configadmin-1.9.2
Reporter: Timothy Ward


When using the new getFactoryConfiguration methods the Configuration Admin 
implementation does not store a newly created configuration in its local cache. 
This results in a new configuration object being created each time which means 
that the revision field is reset to 1. Any updates made to the newly acquired 
configuration are thus not delivered to ManagedServiceFactory instances because 
they are deemed to be "too old", at least until the revision count of the new 
configuration overtakes the old one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FELIX-5885) Felix SCR uses an overly restrictive import range for promises

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-5885:
---

 Summary: Felix SCR uses an overly restrictive import range for 
promises
 Key: FELIX-5885
 URL: https://issues.apache.org/jira/browse/FELIX-5885
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions: scr-2.1.2
Reporter: Timothy Ward
 Fix For: scr-2.1.2


The Felix SCR bundle embeds the OSGi promise library at version 1.0 to make it 
easy to deploy DS. This is great, but the import range used is [1.0,1.1), which 
prevents users of the DS API from using promises 1.1.

There should be no reason that Felix SCR needs to have a provider import range 
- it should be able to substitute any backward compatible version and use a 
range of [1,2).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5864) Missing uses constraints for OSGi spec packages

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5864:
-

Looking now it appears that this may be fixed in trunk, but that still leaves 
5.6.x broken, and there are no snapshots being published of the latest code.

> Missing uses constraints for OSGi spec packages
> ---
>
> Key: FELIX-5864
> URL: https://issues.apache.org/jira/browse/FELIX-5864
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-5.6.10
>Reporter: Timothy Ward
>Priority: Major
> Fix For: framework-5.6.12
>
>
> The System bundle is required to export a number of OSGi spec packages. Some 
> of these must come from the system bundle, but others (for example, 
> org.osgi.service.resolver) can be provided by other bundles as well. It is 
> important, therefore, that the framework defines uses constraints on these 
> packages.
> Specifically "org.osgi.service.resolver" uses "org.osgi.resource" and both 
> are available as separate installable bundles. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FELIX-5864) Missing uses constraints for OSGi spec packages

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-5864:
---

 Summary: Missing uses constraints for OSGi spec packages
 Key: FELIX-5864
 URL: https://issues.apache.org/jira/browse/FELIX-5864
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-5.6.10
Reporter: Timothy Ward
 Fix For: framework-5.6.12


The System bundle is required to export a number of OSGi spec packages. Some of 
these must come from the system bundle, but others (for example, 
org.osgi.service.resolver) can be provided by other bundles as well. It is 
important, therefore, that the framework defines uses constraints on these 
packages.

Specifically "org.osgi.service.resolver" uses "org.osgi.resource" and both are 
available as separate installable bundles. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Plugins for File Install

[Timothy Ward]

Hi all,

There was a contribution of an aggregate bundle archive installer to Felix File 
Install about three months ago, but it appears that not much has been done 
since. I’ve created a PR to make this 
a little easier to build, but was wondering whether anyone is planning on 
releasing this any time soon? At the moment there aren’t even any snapshots 
being deployed...

Best Regards,

Tim

Re: [VOTE] Felix Converter 1.0.0

[Timothy Ward]

+1 (non-binding)

Tim

> On 24 Apr 2018, at 12:59, Christian Schneider  wrote:
> 
> Great to see the converter being released. It is necessary for the upcoming
> Aries RSA release.
> 
> +1 (non binding)
> 
> Christian
> 
> 2018-04-24 5:35 GMT+02:00 Jean-Baptiste Onofré :
> 
>> +1 (binding)
>> 
>> Regards
>> JB
>> 
>> Le 23 avr. 2018 à 17:16, à 17:16, dav...@apache.org a écrit:
>>> Hi all,
>>> 
>>> I would like to call a vote on the Felix Converter version 1.0.0.
>>> The Converter implements chapter 707 of the new OSGi R7 Compendium
>>> Specifications which can be found here:
>>> https://osgi.org/specification/osgi.cmpn/7.0.0/util.converter.html
>>> 
>>> As the OSGi R7 API is now available in Maven Central as released
>>> artifacts,
>>> the release of the Felix Converter can take place.
>>> 
>>> Staging repositories:
>>> https://repository.apache.org/content/repositories/orgapachefelix-1218/
>>> 
>>> You can use this UNIX script to download the release and verify the
>>> signatures:
>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>> 
>>> Usage:
>>> sh check_staged_release.sh 1218 /tmp/felix-staging
>>> 
>>> Please vote to approve this release:
>>> 
>>> [ ] +1 Approve the release
>>> [ ] -1 Veto the release (please provide specific comments)
>>> 
>>> This vote will be open for at least 72 hours.
>>> 
>>> Best regards,
>>> 
>>> David
>> 
> 
> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Computer Scientist
> http://www.adobe.com

Re: Implementation of unreleased spec and community

[Timothy Ward]

At this point I’d also like to re-affirm that the OSGi RFC documents are 
public, and that there is a public feedback mechanism for RFC bugs. As the 
holder of the pen for Transaction Control, the JAX-RS whiteboard, and the JPA 
service updates I can truthfully say that community discussion and feedback has 
influenced the direction of those RFCs/specifications, not just the converter.

As David says below, you can gain increased control over the direction of 
things anywhere by becoming a member/committer/employee. Committers in Apache 
Aries have ample opportunity to review and discuss the many implementations 
built there, just as they do in Felix. This right applies both before and after 
the release of the specification. What Apache Committers can’t do is make 
changes to an OSGi RFC/spec, for that they need to lobby an OSGi member. This 
is exactly the same for a committer in Eclipse, on Github, or in a private 
company, so it leaves Apache committers just as equal as everyone else. The 
main difference here is that there are a lot of OSGi members who believe in 
Apache, and therefore contribute as committers. Are we really saying that those 
committers should be disallowed because they are OSGi members and therefore 
have “more power”?

Finally, there are a lot of projects and/or components in Open Source 
(including Apache) that are written by a single committer, typically the person 
with the itch to scratch. Only If that committer tries to prevent discussion 
about, or changes to, that code is there a problem for the community. To my 
knowledge this does not apply to any of the components in Apache Aries or 
Apache Felix.

Best Regards,

Tim Ward

> On 19 Jan 2017, at 17:32, David Leangen  wrote:
> 
>>> Ray has listed a number of things that have been implemented during the
>>> past few months.  All of them have been written by a single committer who
>>> also happen to be the one modifying the spec document.
>>> 
>>> 
>> This is factually incorrect at least for the Converter implementation at
>> Felix. Just look at the commit history for commits done on behalf of
>> community members and also check the mailing list for discussions that
>> definitely provided great feedback on the work done.
> 
> I have been doing a very tiny bit of work on the Converter as a double 
> outsider (non committer in Felix, and non OSGi member).
> 
> I completely rely on others to accept my contributions and suggestions, 
> making me a kind of second class citizen. It does work, but I need to either 
> (i) become a first class citizen either by merit or paying fees, depending on 
> the organisation, or (ii) accept my dependence on the goodwill of others. 
> Currently I have a de facto sponsor who has been very attentive to my 
> questions and contributions, so (ii) is working out well enough. If it didn’t 
> work out, could always fall back on option (i).
> 
> So I can understand the frustrations and agree that there is a bit of a grey 
> area, but at the same time I understand that in the end I have the same 
> opportunities as everybody else. In this case, I am not willing/able to “pay 
> the price” for full citizenship, so I don’t feel I have the right to complain.
> 
> 
> Just my 2¥.
> 
> Cheers,
> =David
> 
> 

[jira] [Updated] (FELIX-5310) Felix HTTP Jetty WebSockets do not work out of the box

[Timothy Ward (JIRA)]

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

Timothy Ward updated FELIX-5310:

Description: 
I have encountered two significant problems when trying to use the Jetty 
WebSocketServlet with the Jetty based Felix HTTP service whiteboard. Both 
problems occur in the init method of my servlet.

 1. I have to set the TCCL for the Jetty Web Socket implementation to be able 
to find its own internal implementation of Websockets (specifically 
org.eclipse.jetty.websocket.server.WebSocketServerFactory). This is really 
stupid, as the TCCL I have to use is the Felix HTTP Jetty bundle's class loader!

2. The Jetty Web Socket implementation does one (and only one) check to check 
that it's running on Jetty. It looks as though the only reason for this is to 
get hold of an Executor which is available via a getter. This check involves 
trying to establish the Jetty Context by casting the ServletContext to a Jetty 
internal type. This does not work as the HTTP Whiteboard wrappers the 
ServletContext. I can work around this by delaying initialisation to the first 
request so that there is a context to get hold of, but this also sucks :(


In summary, my servlet has to look like this, most of which should not be 
necessary!
{code:java}
public class EchoServlet extends WebSocketServlet {

private static final Logger LOGGER = 
LoggerFactory.getLogger(EchoServlet.class);

private final AtomicBoolean firstCall = new AtomicBoolean(true); 

private final CountDownLatch initBarrier = new CountDownLatch(1); 

@Override
public void init() throws ServletException {
LOGGER.info("The Echo servlet has been initialized, but we delay 
initialization until the first request so that a Jetty Context is available");  
   
}

@Override
public void service(ServletRequest arg0, ServletResponse arg1) throws 
ServletException, IOException {
if(firstCall.compareAndSet(true, false)) {
try {
delayedInit();
} finally {
initBarrier.countDown();
}
} else {
try {
initBarrier.await();
} catch (InterruptedException e) {
throw new ServletException("Timed out waiting for 
initialisation", e);
}
}

super.service(arg0, arg1);
}

private void delayedInit() throws ServletException {
// Overide the TCCL so that the internal factory can be found
// Jetty tries to use ServiceLoader, and their fallback is to
// use TCCL, it would be better if we could provide a loader...

Thread currentThread = Thread.currentThread();
ClassLoader tccl = currentThread.getContextClassLoader();

currentThread.setContextClassLoader(WebSocketServlet.class.getClassLoader());
try {
super.init();
} finally {
currentThread.setContextClassLoader(tccl);
}
}

@Override
public void configure(WebSocketServletFactory wsf) {
wsf.setCreator((req,res) -> new WebSocketAdaptor() {
public void onWebSocketText(String message) {
getRemote().sendStringByFuture("Echo: " + message);
}
});
}
}
{code}

  was:
I have encountered two significant problems when trying to use the Jetty 
WebSocketServlet with the Jetty based Felix HTTP service whiteboard. Both 
problems occur in the init method of my servlet.

 1. I have to set the TCCL for the Jetty Web Socket implementation to be able 
to find its own internal implementation of Websockets (specifically 
org.eclipse.jetty.websocket.server.WebSocketServerFactory). This is really 
stupid, as the TCCL I have to use is the Felix HTTP Jetty bundle's class loader!

2. The Jetty Web Socket implementation does one (and only one) check to check 
that it's running on Jetty. It looks as though the only reason for this is to 
get hold of an Executor which is available via a getter. This check involves 
trying to establish the Jetty Context by casting the ServletContext to a Jetty 
internal type. This does not work as the HTTP Whiteboard wrappers the 
ServletContext. I can work around this by delaying initialisation to the first 
request so that there is a context to get hold of, but this also sucks :(


In summary, my servlet has to look like this, most of which should not be 
necessary!

public class EchoServlet extends WebSocketServlet {

private static final Logger LOGGER = 
LoggerFactory.getLogger(EchoServlet.class);

private final AtomicBoolean f

[jira] [Created] (FELIX-5310) Felix HTTP Jetty WebSockets do not work out of the box

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-5310:
---

 Summary: Felix HTTP Jetty WebSockets do not work out of the box
 Key: FELIX-5310
 URL: https://issues.apache.org/jira/browse/FELIX-5310
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http.jetty-3.2.0
Reporter: Timothy Ward


I have encountered two significant problems when trying to use the Jetty 
WebSocketServlet with the Jetty based Felix HTTP service whiteboard. Both 
problems occur in the init method of my servlet.

 1. I have to set the TCCL for the Jetty Web Socket implementation to be able 
to find its own internal implementation of Websockets (specifically 
org.eclipse.jetty.websocket.server.WebSocketServerFactory). This is really 
stupid, as the TCCL I have to use is the Felix HTTP Jetty bundle's class loader!

2. The Jetty Web Socket implementation does one (and only one) check to check 
that it's running on Jetty. It looks as though the only reason for this is to 
get hold of an Executor which is available via a getter. This check involves 
trying to establish the Jetty Context by casting the ServletContext to a Jetty 
internal type. This does not work as the HTTP Whiteboard wrappers the 
ServletContext. I can work around this by delaying initialisation to the first 
request so that there is a context to get hold of, but this also sucks :(


In summary, my servlet has to look like this, most of which should not be 
necessary!

public class EchoServlet extends WebSocketServlet {

private static final Logger LOGGER = 
LoggerFactory.getLogger(EchoServlet.class);

private final AtomicBoolean firstCall = new AtomicBoolean(true); 

private final CountDownLatch initBarrier = new CountDownLatch(1); 

@Override
public void init() throws ServletException {
LOGGER.info("The Echo servlet has been initialized, but we delay 
initialization until the first request so that a Jetty Context is available");  
   
}

@Override
public void service(ServletRequest arg0, ServletResponse arg1) throws 
ServletException, IOException {
if(firstCall.compareAndSet(true, false)) {
try {
delayedInit();
} finally {
initBarrier.countDown();
}
} else {
try {
initBarrier.await();
} catch (InterruptedException e) {
throw new ServletException("Timed out waiting for 
initialisation", e);
}
}

super.service(arg0, arg1);
}

private void delayedInit() throws ServletException {
// Overide the TCCL so that the internal factory can be found
// Jetty tries to use ServiceLoader, and their fallback is to
// use TCCL, it would be better if we could provide a loader...

Thread currentThread = Thread.currentThread();
ClassLoader tccl = currentThread.getContextClassLoader();

currentThread.setContextClassLoader(WebSocketServlet.class.getClassLoader());
try {
super.init();
} finally {
currentThread.setContextClassLoader(tccl);
}
}

@Override
public void configure(WebSocketServletFactory wsf) {
wsf.setCreator((req,res) -> new WebSocketAdaptor() {
public void onWebSocketText(String message) {
getRemote().sendStringByFuture("Echo: " + message);
}
});
}
}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Felix Http Base 3.0.10, Http Bridge 3.0.10, and Http Jetty 3.2.2

[Timothy Ward]

The checks look good to me.

+1 (non binding)

Tim
> On 18 Jul 2016, at 14:45, Raymond Auge  wrote:
> 
> +1 (non-binding)
> 
> On Mon, Jul 18, 2016 at 3:20 AM, Carsten Ziegeler 
> wrote:
> 
>> +1
>> 
>> 
>> 
>> 
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>> 
>> 
> 
> 
> -- 
> *Raymond Augé* 
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

[jira] [Commented] (FELIX-5248) SCR does not reactivate a failed component after a configuration update

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5248:
-

Hi David,

The component is immediate and has a configuration policy of required. It has 
one static reference to a service which is satisfied, an activate method which 
takes a bundle context, a type safe configuration object, and a map of the raw 
configuration. It also has a deactivate method which takes no arguments.

The failure flow is as follows:

1. The component's bundle is started and the referenced service is available. 
The configuration requirement correctly prevents activation of any component 
instances.
2. A factory configuration is created for the correct factory pid with some 
config properties. Occasionally one of the config properties is malformed, 
which the component instance detects, throwing an exception from the activate 
method. This correctly prevents that component instance from starting when the 
config is bad.
3. The factory configuration is then updated by the user to correct the 
malformed config property. At this point I do not get the behaviour I expect. I 
expect a component instance to be activated with the updated configuration. 
Instead the component sits there, ignoring the configuration update.

If at this point I disable and enable the component then everything works fine, 
but I don't want to do that as it will disable all of the other instances 
created by other factory configurations. It also works if I delete the old 
config and create a new config, but I don't want to do that either because it's 
an extra set of steps for the user.

I don't think that what I'm asking for is illogical, although I can't find a 
line in the specification which says that it must work. 

I hope this helps. I've tried looking through the felix SCR unit tests, but at 
the moment I'm not entirely sure how I would write a failing test for this 
behaviour.

Tim

> SCR does not reactivate a failed component after a configuration update
> ---
>
> Key: FELIX-5248
> URL: https://issues.apache.org/jira/browse/FELIX-5248
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.4
>Reporter: Timothy Ward
>Priority: Blocker
>
> A configurable SCR component may fail to activate by throwing an exception if 
> the factory configuration contains bad values. If the factory configuration 
> for that component is then updated SCR should attempt to recreate and 
> activate the component. Instead the component sits in the "satisfied" state 
> forever, and updates to the factory configuration are ignored.
> This makes it impossible to "fix" a mistaken configuration without deleting 
> and recreating it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FELIX-5248) SCR does not reactivate a failed component after a configuration update

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-5248:
---

 Summary: SCR does not reactivate a failed component after a 
configuration update
 Key: FELIX-5248
 URL: https://issues.apache.org/jira/browse/FELIX-5248
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions: scr-2.0.4
Reporter: Timothy Ward
Priority: Blocker


A configurable SCR component may fail to activate by throwing an exception if 
the factory configuration contains bad values. If the factory configuration for 
that component is then updated SCR should attempt to recreate and activate the 
component. Instead the component sits in the "satisfied" state forever, and 
updates to the factory configuration are ignored.

This makes it impossible to "fix" a mistaken configuration without deleting and 
recreating it.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4212) Felix framework doesn't provide access to Generic Requirements and Capabilities with effective:=active

[Timothy Ward (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756405#comment-13756405
 ] 

Timothy Ward commented on FELIX-4212:
-

Hi Richard,

Thanks for locating the relevant part of the spec. The R4.3 JavaDoc for 
BundleWiring.getCapabilities() doesn't mention the resolver (hence my 
confusion) The wording is as follows:

-

java.util.ListBundleCapability getCapabilities(java.lang.String namespace)
Returns the capabilities provided by this bundle wiring.
A capability may not be required by any bundle wiring and thus there may be no 
wires for the capability.

A bundle wiring for a non-fragment revision provides a subset of the declared 
capabilities from the bundle revision and all attached fragment revisions. Not 
all declared capabilities may be provided since some may be discarded. For 
example, if a package is declared to be exported and import, only one is 
selected and the other is discarded.

Parameters:
namespace - The name space of the capabilities to return or null to return the 
capabilities from all name spaces.
Returns:
A list containing a snapshot of the BundleCapabilitys, or an empty list if this 
bundle wiring provides no capabilities in the specified name space. If this 
bundle wiring is not in use, null will be returned. For a given name space, the 
list contains the wires in the order the capabilities were specified in the 
manifests of the bundle revision and the attached fragments of this bundle 
wiring. There is no ordering defined between capabilities in different name 
spaces.

--

This was updated in R5 to:

---

java.util.ListBundleCapability getCapabilities(java.lang.String namespace)
Returns the capabilities provided by this bundle wiring.
Only capabilities considered by the resolver are returned. For example, 
capabilities with effective directive not equal to resolve are not returned.

A capability may not be required by any bundle wiring and thus there may be no 
wires for the capability.

A bundle wiring for a non-fragment revision provides a subset of the declared 
capabilities from the bundle revision and all attached fragment revisions†. Not 
all declared capabilities may be provided since some may be discarded. For 
example, if a package is declared to be both exported and imported, only one is 
selected and the other is discarded.

A bundle wiring for a fragment revision with a symbolic name must provide 
exactly one identity capability.

† The identity capability provided by attached fragment revisions must not be 
included in the capabilities of the host bundle wiring.

Parameters:
namespace - The namespace of the capabilities to return or null to return the 
capabilities from all namespaces.
Returns:
A list containing a snapshot of the BundleCapabilitys, or an empty list if this 
bundle wiring provides no capabilities in the specified namespace. If this 
bundle wiring is not in use, null will be returned. For a given namespace, the 
list contains the wires in the order the capabilities were specified in the 
manifests of the bundle revision and the attached fragments† of this bundle 
wiring. There is no ordering defined between capabilities in different 
namespaces.




I've put in a quick test. My bundle manifest contains:

--
Provide-Capability: test.namespace, test.namespace; effective:=active

Require-Capability: test.namespace; filter:=(foo=bar); resolution:=optional, 
test.namespace; filter:=(foo=bar); effective:=active
--

and I see the following:

Felix 4.2.1:


Bundle Revision
test.namespace effective null
test.namespace effective active
test.namespace effective null
test.namespace effective active

Bundle Wiring
test.namespace effective null

Felix 4.2.0:


Bundle Revision
test.namespace effective null
test.namespace effective active
test.namespace effective null
test.namespace effective active

Bundle Wiring
test.namespace effective null

Felix 4.0.3:


Bundle Revision
test.namespace effective null
test.namespace effective active
test.namespace effective null
test.namespace effective active

Bundle Wiring
test.namespace effective null

Equinox 3.8.2:
--

Bundle Revision
test.namespace effective null
test.namespace effective active
test.namespace effective null
test.namespace effective active

Bundle Wiring
test.namespace effective null

Equinox 3.7.2:
--

Bundle Revision
test.namespace effective null
test.namespace effective null

Bundle Wiring
test.namespace effective null


Looks like I should raise a bug against Equinox 3.7.x ...


 Felix framework doesn't provide access to Generic Requirements and 
 Capabilities with effective:=active
 --

 Key: FELIX

[jira] [Closed] (FELIX-4212) Felix framework doesn't provide access to Generic Requirements and Capabilities with effective:=active

[Timothy Ward (JIRA)]

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

Timothy Ward closed FELIX-4212.
---

Resolution: Invalid

 Felix framework doesn't provide access to Generic Requirements and 
 Capabilities with effective:=active
 --

 Key: FELIX-4212
 URL: https://issues.apache.org/jira/browse/FELIX-4212
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.2.1
Reporter: Timothy Ward
Priority: Critical

 I am trying to access Require-Capability and Provide-Capability metadata from 
 my bundle's manifest using the BundleWiring API. Most capabilities show up 
 fine, but none of the ones with effective:=active are present. I understand 
 that these capabilities are ignored by the resolver, and may not have any 
 wirings, but I expect them to show up anyway. This avoids me having to 
 provide my own parsing code to turn the manifest entries into Requirements 
 and Capabilities.
 Having checked with the OSGi Core Platform Expert group, active time 
 requirements and capabilities really should be showing up in the 
 BundleWiring. My guess is that this will be easy to fix!

--
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] [Created] (FELIX-4212) Felix framework doesn't provide access to Generic Requirements and Capabilities with effective:=active

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-4212:
---

 Summary: Felix framework doesn't provide access to Generic 
Requirements and Capabilities with effective:=active
 Key: FELIX-4212
 URL: https://issues.apache.org/jira/browse/FELIX-4212
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-4.2.1
Reporter: Timothy Ward
Priority: Critical


I am trying to access Require-Capability and Provide-Capability metadata from 
my bundle's manifest using the BundleWiring API. Most capabilities show up 
fine, but none of the ones with effective:=active are present. I understand 
that these capabilities are ignored by the resolver, and may not have any 
wirings, but I expect them to show up anyway. This avoids me having to provide 
my own parsing code to turn the manifest entries into Requirements and 
Capabilities.

Having checked with the OSGi Core Platform Expert group, active time 
requirements and capabilities really should be showing up in the BundleWiring. 
My guess is that this will be easy to fix!

--
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] [Commented] (FELIX-4088) NPE from SCR service unregistration

[Timothy Ward (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13739450#comment-13739450
 ] 

Timothy Ward commented on FELIX-4088:
-

That's fine with me.

 NPE from SCR service unregistration
 ---

 Key: FELIX-4088
 URL: https://issues.apache.org/jira/browse/FELIX-4088
 Project: Felix
  Issue Type: Bug
  Components: Configuration Admin, Declarative Services (SCR), 
 Framework
Affects Versions: framework-4.2.0,  configadmin-1.2.8,  scr-1.6.0
 Environment: MacOSX 8 processors
Reporter: Timothy Ward

 When uninstalling a set of bundles I get the following exception.
 ERROR: Bundle com.paremus.dosgi.topologymanager [101] EventDispatcher: Error 
 during dispatch. (java.lang.NullPointerException)
 java.lang.NullPointerException
   at org.apache.felix.framework.util.Util.getWire(Util.java:335)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493)
   at 
 org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280)
   at 
 org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401)
   at org.apache.felix.framework.Felix.access$000(Felix.java:74)
   at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
   at 
 org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
   at 
 com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338)
   at 
 org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414)
   at 
 org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152)
   at 
 org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247)
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832)
   at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104)
   at java.lang.Thread.run(Thread.java:722)
 ERROR: Bundle org.cauldron.newton.management.monitor [85] EventDispatcher: 
 Error during dispatch. (java.lang.NullPointerException)
 java.lang.NullPointerException
   at org.apache.felix.framework.util.Util.getWire(Util.java:335)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493)
   at 
 org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280)
   at 
 org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401)
   at org.apache.felix.framework.Felix.access$000(Felix.java:74)
   at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
   at 
 org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
   at 
 com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338)
   at 
 org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414

[jira] [Commented] (FELIX-4088) NPE from SCR service unregistration

[Timothy Ward (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13673330#comment-13673330
 ] 

Timothy Ward commented on FELIX-4088:
-

Hi [~djencks] - I have run the scenario again with a local build of the latest 
SCR code and I'm no longer seeing errors. Previously they were occurring about 
75% of the time, and I've run through 10 times since the update. This obviously 
doesn't guarantee that there isn't another race condition in the framework, but 
the fix you added has definitely improved things.

 NPE from SCR service unregistration
 ---

 Key: FELIX-4088
 URL: https://issues.apache.org/jira/browse/FELIX-4088
 Project: Felix
  Issue Type: Bug
  Components: Configuration Admin, Declarative Services (SCR), 
 Framework
Affects Versions: framework-4.2.0,  configadmin-1.2.8,  scr-1.6.0
 Environment: MacOSX 8 processors
Reporter: Timothy Ward

 When uninstalling a set of bundles I get the following exception.
 ERROR: Bundle com.paremus.dosgi.topologymanager [101] EventDispatcher: Error 
 during dispatch. (java.lang.NullPointerException)
 java.lang.NullPointerException
   at org.apache.felix.framework.util.Util.getWire(Util.java:335)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493)
   at 
 org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280)
   at 
 org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401)
   at org.apache.felix.framework.Felix.access$000(Felix.java:74)
   at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
   at 
 org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
   at 
 com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338)
   at 
 org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414)
   at 
 org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152)
   at 
 org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247)
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832)
   at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104)
   at java.lang.Thread.run(Thread.java:722)
 ERROR: Bundle org.cauldron.newton.management.monitor [85] EventDispatcher: 
 Error during dispatch. (java.lang.NullPointerException)
 java.lang.NullPointerException
   at org.apache.felix.framework.util.Util.getWire(Util.java:335)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493)
   at 
 org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280)
   at 
 org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401)
   at org.apache.felix.framework.Felix.access$000(Felix.java:74)
   at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
   at 
 org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
   at 
 com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470

[jira] [Created] (FELIX-4088) NPE from SCR service unregistration

[Timothy Ward (JIRA)]

Timothy Ward created FELIX-4088:
---

 Summary: NPE from SCR service unregistration
 Key: FELIX-4088
 URL: https://issues.apache.org/jira/browse/FELIX-4088
 Project: Felix
  Issue Type: Bug
  Components: Configuration Admin, Declarative Services (SCR), Framework
Affects Versions: scr-1.6.2
Reporter: Timothy Ward




--
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-4088) NPE from SCR service unregistration

[Timothy Ward (JIRA)]

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

Timothy Ward updated FELIX-4088:


  Description: 
When uninstalling a set of bundles I get the following exception.

ERROR: Bundle com.paremus.dosgi.topologymanager [101] EventDispatcher: Error 
during dispatch. (java.lang.NullPointerException)
java.lang.NullPointerException
at org.apache.felix.framework.util.Util.getWire(Util.java:335)
at 
org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493)
at 
org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280)
at 
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916)
at 
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at 
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401)
at org.apache.felix.framework.Felix.access$000(Felix.java:74)
at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
at 
org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151)
at 
org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
at 
com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37)
at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470)
at 
org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074)
at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338)
at 
org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414)
at 
org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152)
at 
org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247)
at 
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104)
at java.lang.Thread.run(Thread.java:722)
ERROR: Bundle org.cauldron.newton.management.monitor [85] EventDispatcher: 
Error during dispatch. (java.lang.NullPointerException)
java.lang.NullPointerException
at org.apache.felix.framework.util.Util.getWire(Util.java:335)
at 
org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493)
at 
org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280)
at 
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916)
at 
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
at 
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401)
at org.apache.felix.framework.Felix.access$000(Felix.java:74)
at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
at 
org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151)
at 
org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
at 
com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37)
at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470)
at 
org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074)
at 
org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338)
at 
org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414)
at 
org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152)
at 
org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247)
at 
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104)
at java.lang.Thread.run(Thread.java:722)

One of the bundles

[jira] [Commented] (FELIX-4088) NPE from SCR service unregistration

[Timothy Ward (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669616#comment-13669616
 ] 

Timothy Ward commented on FELIX-4088:
-

1. I'll have a go with the latest snapshot and see what happens.

2. The Paremus code doesn't do anything much beyond logging the call and then 
delegating. I don't see a way in which it could be introducing a thread switch, 
a delay, or that it could filter the event from DS. I'll make sure to keep an 
eye on it while continuing to debug.

3. The configuration has a factory pid matching the name of the DS component, 
and the DS component has a configuration-policy of require:

scr:component xmlns:scr=http://www.osgi.org/xmlns/scr/v1.1.0; 
name=com.paremus.packager.demos.derby.guard configuration-policy=require 
activate=activate

I'll try to collect some useful logs.

Even if this does turn out to be fixed in a more recent SCR release it still 
might be worth putting a null check in the core framework. I was quite 
surprised to be able to get something so deep in the core to NPE!

 NPE from SCR service unregistration
 ---

 Key: FELIX-4088
 URL: https://issues.apache.org/jira/browse/FELIX-4088
 Project: Felix
  Issue Type: Bug
  Components: Configuration Admin, Declarative Services (SCR), 
 Framework
Affects Versions: framework-4.2.0,  configadmin-1.2.8,  scr-1.6.0
 Environment: MacOSX 8 processors
Reporter: Timothy Ward

 When uninstalling a set of bundles I get the following exception.
 ERROR: Bundle com.paremus.dosgi.topologymanager [101] EventDispatcher: Error 
 during dispatch. (java.lang.NullPointerException)
 java.lang.NullPointerException
   at org.apache.felix.framework.util.Util.getWire(Util.java:335)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493)
   at 
 org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280)
   at 
 org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401)
   at org.apache.felix.framework.Felix.access$000(Felix.java:74)
   at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
   at 
 org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
   at 
 com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338)
   at 
 org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414)
   at 
 org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152)
   at 
 org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247)
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832)
   at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104)
   at java.lang.Thread.run(Thread.java:722)
 ERROR: Bundle org.cauldron.newton.management.monitor [85] EventDispatcher: 
 Error during dispatch. (java.lang.NullPointerException)
 java.lang.NullPointerException
   at org.apache.felix.framework.util.Util.getWire(Util.java:335)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493)
   at 
 org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280)
   at 
 org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401)
   at org.apache.felix.framework.Felix.access$000(Felix.java:74)
   at org.apache.felix.framework.Felix

[jira] [Commented] (FELIX-4088) NPE from SCR service unregistration

[Timothy Ward (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669662#comment-13669662
 ] 

Timothy Ward commented on FELIX-4088:
-

It looks like it probably is a threading problem...

I see the same error using the 1.7.0-SNAPSHOT build from this morning, but only 
sometimes.

Most of the time I see the following instead:

ERROR: [com.paremus.packager.demos.derby.guard(53)] Bundle is shut down for 
dependency driverHosting to ((database.driver=derby)(version=10.9.1.0))
*ERROR* Unexpected problem delivery configuration event to 
[org.osgi.service.cm.ConfigurationListener, id=199, bundle=158]
java.lang.NullPointerException
at 
org.apache.felix.scr.impl.config.ConfigurationSupport.configureComponentHolder(ConfigurationSupport.java:113)
at 
org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:246)
at 
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104)
at java.lang.Thread.run(Thread.java:722)


If I turn on debug trace then I no longer see the problem at all, if I turn on 
info trace then I occasionally see the problem. Sorry, I know this isn't the 
most helpful of debug information!


 NPE from SCR service unregistration
 ---

 Key: FELIX-4088
 URL: https://issues.apache.org/jira/browse/FELIX-4088
 Project: Felix
  Issue Type: Bug
  Components: Configuration Admin, Declarative Services (SCR), 
 Framework
Affects Versions: framework-4.2.0,  configadmin-1.2.8,  scr-1.6.0
 Environment: MacOSX 8 processors
Reporter: Timothy Ward

 When uninstalling a set of bundles I get the following exception.
 ERROR: Bundle com.paremus.dosgi.topologymanager [101] EventDispatcher: Error 
 during dispatch. (java.lang.NullPointerException)
 java.lang.NullPointerException
   at org.apache.felix.framework.util.Util.getWire(Util.java:335)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493)
   at 
 org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280)
   at 
 org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
   at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4401)
   at org.apache.felix.framework.Felix.access$000(Felix.java:74)
   at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
   at 
 org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:151)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
   at 
 com.paremus.frameworkintercept.DelegatingServiceRegistration.unregister(DelegatingServiceRegistration.java:37)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:470)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1074)
   at 
 org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:338)
   at 
 org.apache.felix.scr.impl.manager.ImmediateComponentManager.reconfigure(ImmediateComponentManager.java:414)
   at 
 org.apache.felix.scr.impl.config.ConfiguredComponentHolder.configurationDeleted(ConfiguredComponentHolder.java:152)
   at 
 org.apache.felix.scr.impl.config.ConfigurationComponentRegistry.configurationEvent(ConfigurationComponentRegistry.java:247)
   at 
 org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:1832)
   at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104)
   at java.lang.Thread.run(Thread.java:722)
 ERROR: Bundle org.cauldron.newton.management.monitor [85] EventDispatcher: 
 Error during dispatch. (java.lang.NullPointerException)
 java.lang.NullPointerException
   at org.apache.felix.framework.util.Util.getWire(Util.java:335)
   at 
 org.apache.felix.framework.ServiceRegistrationImpl$ServiceReferenceImpl.isAssignableTo(ServiceRegistrationImpl.java:493)
   at 
 org.apache.felix.framework.util.Util.isServiceAssignable(Util.java:280)
   at 
 org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:916)
   at 
 org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793

[jira] Commented: (FELIX-2546) Only one service is provisioned even when specifying for mulitple services

[Timothy Ward (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991858#comment-12991858
 ] 

Timothy Ward commented on FELIX-2546:
-

Hi Guillaume,

Obviously I'd like this fixed, but I'm happy for it to go into a 1.7 release 
rather than a 1.6.5 release of bundlerepository. There are a few other problems 
I'm looking at providing fixes for, and I'm happy to work by locally patching 
my bundles in the short term.

Tim

 Only one service is provisioned even when specifying for mulitple services
 --

 Key: FELIX-2546
 URL: https://issues.apache.org/jira/browse/FELIX-2546
 Project: Felix
  Issue Type: Bug
  Components: Bundle Repository (OBR)
Affects Versions: bundlerepository-1.6.4
 Environment: n/a
Reporter: Emily Jiang
 Attachments: Felix OBR isMultiple support - timothyjward.txt


 Felix OBR is unable to return multiple services when specifying 'multiple' 
 attribute with the value of 'true'. The test scenario is detailed below.
 I am trying to get all bundles registering the service of 
 com.sample.HelloWorld and install them into the osgi framework . In my test 
 environment, there are two bundles with different symbolic name offering the 
 same service, com.sample.HelloWorld. However, only one bundle was pulled into 
 runtime. The snippet of my repository is shown below. 
 require extend=false 
 filter=(amp;(service=service)(objectClass=com.sample.HelloWorld)(mandatory:lt;*service))
  multiple=true name=service optional=falseRequires service with 
 attributes {service=service, objectClass=com.sample.HelloWorld}/require
 Regards
 Emily

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (FELIX-2546) Only one service is provisioned even when specifying for mulitple services

[Timothy Ward (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12980887#action_12980887
 ] 

Timothy Ward commented on FELIX-2546:
-

I also needed this and thought that it would be rather useful function for OBR, 
so I had a go at coding it up. It actually turned out to be relatively simple 
thanks to the existing structure. I'll attach what I have, and I'm happy to 
contribute it to the felix code base.

 Only one service is provisioned even when specifying for mulitple services
 --

 Key: FELIX-2546
 URL: https://issues.apache.org/jira/browse/FELIX-2546
 Project: Felix
  Issue Type: Bug
  Components: Bundle Repository (OBR)
Affects Versions: bundlerepository-1.6.4
 Environment: n/a
Reporter: Emily Jiang

 Felix OBR is unable to return multiple services when specifying 'multiple' 
 attribute with the value of 'true'. The test scenario is detailed below.
 I am trying to get all bundles registering the service of 
 com.sample.HelloWorld and install them into the osgi framework . In my test 
 environment, there are two bundles with different symbolic name offering the 
 same service, com.sample.HelloWorld. However, only one bundle was pulled into 
 runtime. The snippet of my repository is shown below. 
 require extend=false 
 filter=(amp;(service=service)(objectClass=com.sample.HelloWorld)(mandatory:lt;*service))
  multiple=true name=service optional=falseRequires service with 
 attributes {service=service, objectClass=com.sample.HelloWorld}/require
 Regards
 Emily

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (FELIX-2546) Only one service is provisioned even when specifying for mulitple services

[Timothy Ward (JIRA)]

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

Timothy Ward updated FELIX-2546:


Attachment: Felix OBR isMultiple support - timothyjward.txt

This patch adds proper support for multiple resources (i.e. it greedily finds 
them in the repository and adds the ones that can resolve). It also adds 
another resolution flag that allows the new behaviour to be switched off, 
returning to the original behaviour and providing a slight speed increase.

There is a simple testcase for the new function included in the patch as well.

 Only one service is provisioned even when specifying for mulitple services
 --

 Key: FELIX-2546
 URL: https://issues.apache.org/jira/browse/FELIX-2546
 Project: Felix
  Issue Type: Bug
  Components: Bundle Repository (OBR)
Affects Versions: bundlerepository-1.6.4
 Environment: n/a
Reporter: Emily Jiang
 Attachments: Felix OBR isMultiple support - timothyjward.txt


 Felix OBR is unable to return multiple services when specifying 'multiple' 
 attribute with the value of 'true'. The test scenario is detailed below.
 I am trying to get all bundles registering the service of 
 com.sample.HelloWorld and install them into the osgi framework . In my test 
 environment, there are two bundles with different symbolic name offering the 
 same service, com.sample.HelloWorld. However, only one bundle was pulled into 
 runtime. The snippet of my repository is shown below. 
 require extend=false 
 filter=(amp;(service=service)(objectClass=com.sample.HelloWorld)(mandatory:lt;*service))
  multiple=true name=service optional=falseRequires service with 
 attributes {service=service, objectClass=com.sample.HelloWorld}/require
 Regards
 Emily

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.