Re: Maybe a Felix Framework release sometime soon?
I would really like to start getting this release out, any comments on Guillaume's updated patch? If nobody has any comments I can just apply it and get the release process rolling. Cheers, David On 24 February 2014 14:07, Guillaume Nodet gno...@apache.org wrote: I just proposed a patch for FELIX-4190, so comments are welcomed. 2014-02-24 9:50 GMT+01:00 Guillaume Nodet gno...@apache.org: Do you have a patch that you could attach to FELIX-3687 that I could look at ? Again, I have no problems reverting my patch, but I'd like FELIX-3687 / FELIX-4190 to be fixed in some way or another, preferably the best one ... Cheers, Guillaume 2014-02-23 19:25 GMT+01:00 David Jencks david_jen...@yahoo.com: As I've said before, I sort of need some advice on how to proceed to fix the deadlock. I'm slightly in favor of just rolling back Guillaume's fix since it is definitely not spec compliant. Whether the deadlock is more spec compliant is certainly debatable. david jencks On Feb 23, 2014, at 8:14 AM, David Bosschaert david.bosscha...@gmail.com wrote: Hi all, It's been a while since this thread was started. I see that there is a desire to improve on the locking, but nothing has happened in that area over the past month. I was thinking to start putting together a release early March, since it will be nice to have R5 core support in a release. If we can get the locking code improved before that then great, but was thinking that if nothing has happened there we should postpone FELIX-3687/FELIX-4190 to a later release? Thought anyone? Cheers, David On 30 January 2014 08:53, Guillaume Nodet gno...@apache.org wrote: I don't have any problem reverting my fix if you have a better one ;-) 2014-01-18 David Jencks david_jen...@yahoo.com I hope that someone cleans up the mess around https://issues.apache.org/jira/browse/FELIX-3687 and https://issues.apache.org/jira/browse/FELIX-4190 before a release candidate. In the first issue I proposed a patch, Richard pointed out a problem, and I suggested a possible solution and haven't gotten any comments. In the 2nd issue Guillaume committed a fix that is invalid and AFAIK it has not been corrected. thanks david jencks On Jan 17, 2014, at 8:40 AM, David Bosschaert david.bosscha...@gmail.com wrote: On 17 January 2014 16:16, Carsten Ziegeler cziege...@apache.org wrote: +1 for a new framework release, it would be great to have full R5 support, but if that is not supposed to happen soon Full disclosure: I tried my hand on those resolver related open issues, but had the feeling that I didn't understand the Felix code well enough for it. The resolver is a pretty complex beast, especially since it's recursive/re-entrant and I found that fixing one little issue would cause tons of other things to fall over elsewhere ;) In the end I often came up with a patchwork of fixes for one resolver CT test failure where I had the feeling that it could be done more elegantly. so in the end I abandoned my attempts here... I think those remaining resolver issues are for someone who really knows the felix resolver code inside out :) Cheers, David
[jira] [Created] (FELIX-4455) Missing default constructor creates invalid class instances
Benjamin Debeerst created FELIX-4455:
Summary: Missing default constructor creates invalid class
instances
Key: FELIX-4455
URL: https://issues.apache.org/jira/browse/FELIX-4455
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.11.1, ipojo-manipulator-1.10.1
Reporter: Benjamin Debeerst
Consider the following component definition:
{code}
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
{code}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi container,
the component outputs
{code}
ComponentWithoutDefaultConstructor: activating!
null
{code}
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should not
be possible to create such an invalid object instance. I don't know much about
the reflection APIs or byte code manipulation though.
I have put [a sample maven project on
GitHub|https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample],
which can be built and droppped into a fresh Karaf container + iPOJO, which
shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (FELIX-4455) Missing default constructor creates invalid class instances
[
https://issues.apache.org/jira/browse/FELIX-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Debeerst updated FELIX-4455:
-
Description:
Consider the following component definition:
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi container,
the component outputs
ComponentWithoutDefaultConstructor: activating!
null
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should not
be possible to create such an invalid object instance. I don't know much about
the reflection APIs or byte code manipulation though.
I have put a sample maven project on GitHub[1], which can be built and droppped
into a fresh Karaf container + iPOJO, which shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
I encountered this problem both with iPOJO 1.10.1 and 1.11.1.
[1] https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample
was:
Consider the following component definition:
{code}
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
{code}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi container,
the component outputs
{code}
ComponentWithoutDefaultConstructor: activating!
null
{code}
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should not
be possible to create such an invalid object instance. I don't know much about
the reflection APIs or byte code manipulation though.
I have put [a sample maven project on
GitHub|https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample],
which can be built and droppped into a fresh Karaf container + iPOJO, which
shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
I encountered this problem both with iPOJO 1.10.1 and 1.11.1
Missing default constructor creates invalid class instances
---
Key: FELIX-4455
URL: https://issues.apache.org/jira/browse/FELIX-4455
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.10.1, ipojo-manipulator-1.11.1
Reporter: Benjamin Debeerst
Consider the following component definition:
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default
[jira] [Updated] (FELIX-4455) Missing default constructor creates invalid class instances
[
https://issues.apache.org/jira/browse/FELIX-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Debeerst updated FELIX-4455:
-
Description:
Consider the following component definition:
{code}
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
{code}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi container,
the component outputs
{code}
ComponentWithoutDefaultConstructor: activating!
null
{code}
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should not
be possible to create such an invalid object instance. I don't know much about
the reflection APIs or byte code manipulation though.
I have put [a sample maven project on
GitHub|https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample],
which can be built and droppped into a fresh Karaf container + iPOJO, which
shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
I encountered this problem both with iPOJO 1.10.1 and 1.11.1
was:
Consider the following component definition:
{code}
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
{code}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi container,
the component outputs
{code}
ComponentWithoutDefaultConstructor: activating!
null
{code}
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should not
be possible to create such an invalid object instance. I don't know much about
the reflection APIs or byte code manipulation though.
I have put [a sample maven project on
GitHub|https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample],
which can be built and droppped into a fresh Karaf container + iPOJO, which
shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
Missing default constructor creates invalid class instances
---
Key: FELIX-4455
URL: https://issues.apache.org/jira/browse/FELIX-4455
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.10.1, ipojo-manipulator-1.11.1
Reporter: Benjamin Debeerst
Consider the following component definition:
{code}
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property =
[jira] [Commented] (FELIX-4455) Missing default constructor creates invalid class instances
[
https://issues.apache.org/jira/browse/FELIX-4455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930181#comment-13930181
]
Clement Escoffier commented on FELIX-4455:
--
Could you try with:
{code}
public ComponentWithoutDefaultConstructor(@Property(name=property) String
property) {
System.out.println(Non-default constructor call!);
this.property = property;
}
{code}
Missing default constructor creates invalid class instances
---
Key: FELIX-4455
URL: https://issues.apache.org/jira/browse/FELIX-4455
Project: Felix
Issue Type: Bug
Components: iPOJO
Affects Versions: ipojo-manipulator-1.10.1, ipojo-manipulator-1.11.1
Reporter: Benjamin Debeerst
Consider the following component definition:
@Component
@Instantiate
public class ComponentWithoutDefaultConstructor
{
private Object internal = new Object();
@Property
private String property;
/* Constructor for unit tests */
public ComponentWithoutDefaultConstructor(String property)
{
System.out.println(Non-default constructor call!);
this.property = property;
}
@Validate
public void activate()
{
System.out.println(ComponentWithoutDefaultConstructor: activating!);
System.out.println(this.internal);
}
}
As per definition, I would expect every instance of this class to have a
non-null member {{internal}} at class creation. This is all fine for my unit
tests in a non-OSGi environment.
However, having this processes by iPOJO and putting this in an OSGi
container, the component outputs
ComponentWithoutDefaultConstructor: activating!
null
The existing non-default constructor is not called, while it seems that a
separate constructor has been created that does non instantiate the member
variable.
If I extend the code by an empty default constructor, that one is called and
all works perfectly fine.
I have no idea how iPOJO creates the object instance anyways, as it should
not be possible to create such an invalid object instance. I don't know much
about the reflection APIs or byte code manipulation though.
I have put a sample maven project on GitHub[1], which can be built and
droppped into a fresh Karaf container + iPOJO, which shows the problem.
If there is no constructor iPOJO can use, I would expect iPOJO to either A)
throw a warning/error (and build or runtime) and fail to instantiate the
component or B) synthesize the default constructor properly, including the
implicit instantiation of member variables.
I encountered this problem both with iPOJO 1.10.1 and 1.11.1.
[1] https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4190) The framework should not hold any lock while calling ServiceFactory#unget
[ https://issues.apache.org/jira/browse/FELIX-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930291#comment-13930291 ] Richard S. Hall commented on FELIX-4190: I believe duplicating the loop would work. The first loop tries to be friendly, then the call to invalidate() makes it impossible to get the service object again, and then finally the second loop deals more harshly with clients who won't let go. The framework should not hold any lock while calling ServiceFactory#unget - Key: FELIX-4190 URL: https://issues.apache.org/jira/browse/FELIX-4190 Project: Felix Issue Type: Bug Components: Framework Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: framework-4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Maybe a Felix Framework release sometime soon?
If you want me to I can cut the release if you let me know when it is ready... regards, Karl On Tue, Mar 11, 2014 at 9:50 AM, David Bosschaert david.bosscha...@gmail.com wrote: I would really like to start getting this release out, any comments on Guillaume's updated patch? If nobody has any comments I can just apply it and get the release process rolling. Cheers, David On 24 February 2014 14:07, Guillaume Nodet gno...@apache.org wrote: I just proposed a patch for FELIX-4190, so comments are welcomed. 2014-02-24 9:50 GMT+01:00 Guillaume Nodet gno...@apache.org: Do you have a patch that you could attach to FELIX-3687 that I could look at ? Again, I have no problems reverting my patch, but I'd like FELIX-3687 / FELIX-4190 to be fixed in some way or another, preferably the best one ... Cheers, Guillaume 2014-02-23 19:25 GMT+01:00 David Jencks david_jen...@yahoo.com: As I've said before, I sort of need some advice on how to proceed to fix the deadlock. I'm slightly in favor of just rolling back Guillaume's fix since it is definitely not spec compliant. Whether the deadlock is more spec compliant is certainly debatable. david jencks On Feb 23, 2014, at 8:14 AM, David Bosschaert david.bosscha...@gmail.com wrote: Hi all, It's been a while since this thread was started. I see that there is a desire to improve on the locking, but nothing has happened in that area over the past month. I was thinking to start putting together a release early March, since it will be nice to have R5 core support in a release. If we can get the locking code improved before that then great, but was thinking that if nothing has happened there we should postpone FELIX-3687/FELIX-4190 to a later release? Thought anyone? Cheers, David On 30 January 2014 08:53, Guillaume Nodet gno...@apache.org wrote: I don't have any problem reverting my fix if you have a better one ;-) 2014-01-18 David Jencks david_jen...@yahoo.com I hope that someone cleans up the mess around https://issues.apache.org/jira/browse/FELIX-3687 and https://issues.apache.org/jira/browse/FELIX-4190 before a release candidate. In the first issue I proposed a patch, Richard pointed out a problem, and I suggested a possible solution and haven't gotten any comments. In the 2nd issue Guillaume committed a fix that is invalid and AFAIK it has not been corrected. thanks david jencks On Jan 17, 2014, at 8:40 AM, David Bosschaert david.bosscha...@gmail.com wrote: On 17 January 2014 16:16, Carsten Ziegeler cziege...@apache.org wrote: +1 for a new framework release, it would be great to have full R5 support, but if that is not supposed to happen soon Full disclosure: I tried my hand on those resolver related open issues, but had the feeling that I didn't understand the Felix code well enough for it. The resolver is a pretty complex beast, especially since it's recursive/re-entrant and I found that fixing one little issue would cause tons of other things to fall over elsewhere ;) In the end I often came up with a patchwork of fixes for one resolver CT test failure where I had the feeling that it could be done more elegantly. so in the end I abandoned my attempts here... I think those remaining resolver issues are for someone who really knows the felix resolver code inside out :) Cheers, David -- Karl Pauls karlpa...@gmail.com http://twitter.com/karlpauls http://www.linkedin.com/in/karlpauls https://profiles.google.com/karlpauls
Re: [VOTE] Accept PojoSR code donation
+1 On Mar 5, 2014 3:49 PM, Guillaume Nodet gno...@apache.org wrote: Karl Pauls is willing to donate PojoSR (https://code.google.com/p/pojosr/) to Felix. This vote is about officially accepting the donation. [ ] +1 Accept PojoSR code into Felix [ ] -1 Do not Cheers, Guillaume Nodet
Re: [VOTE] Accept PojoSR code donation
+1 Nice one! On 11 Mar 2014, at 15:29, Marcel Offermans marcel.offerm...@luminis.eu wrote: +1 On Mar 5, 2014 3:49 PM, Guillaume Nodet gno...@apache.org wrote: Karl Pauls is willing to donate PojoSR (https://code.google.com/p/pojosr/) to Felix. This vote is about officially accepting the donation. [ ] +1 Accept PojoSR code into Felix [ ] -1 Do not Cheers, Guillaume Nodet
[VOTE] Release of iPOJO Manipulator and Runtime 1.11.2
Hi, It's time to cut a release of the iPOJO manipulator (1.11.2) and runtime project (1.11.2). Both projects are containing several modules: The org.apache.felix.ipojo.manipulator-project contains: * bnd-ipojo-plugin * maven-ipojo-plugin * org.apache.felix.ipojo.annotations * org.apache.felix.ipojo.ant * org.apache.felix.ipojo.manipulator * org.apache.felix.ipojo.manipulator.online The org.apache.felix.ipojo.runtime-project contains: * org.apache.felix.ipojo * org.apache.felix.ipojo.api * org.apache.felix.ipojo.composite * org.apache.felix.ipojo.distribution.10mintutorial * org.apache.felix.ipojo.distribution.maventutorial * org.apache.felix.ipojo.distribution.quickstart * org.apache.felix.ipojo.features * org.apache.felix.ipojo.gogo Those releases are bug fix releases. The changelogs are below. Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1011/ 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 1011 /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 (at least). Regards, Clement Changelog of the runtime project (1.11.2): ** Bug * [FELIX-4229] - Provide a way to obtain the component's BundleContext (other than constructor injection) * [FELIX-4419] - Open access to InstanceDeclaration and TypeDeclaration * [FELIX-4432] - DefaultServiceRankingInterceptor holds duplicate dependencies * [FELIX-4448] - Invalid dynamism management when an interceptor implements both Tracking and Ranking interceptors * [FELIX-4449] - The ConfigurationListener list contains duplicates and fires update on unchanged configurations ** Improvement * [FELIX-3931] - Provide a handler to inject the bundle context Changelog of the manipulator project (1.11.2): ** Bug * [FELIX-4453] - Introduce manipulator BOM (Bill of Material) ** Improvement * [FELIX-4454] - Online manipulator should be able to take advantage of Stereotypes
[jira] [Commented] (FELIX-4190) The framework should not hold any lock while calling ServiceFactory#unget
[ https://issues.apache.org/jira/browse/FELIX-4190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930818#comment-13930818 ] David Jencks commented on FELIX-4190: - I'm ok with the duplicated loop. The framework should not hold any lock while calling ServiceFactory#unget - Key: FELIX-4190 URL: https://issues.apache.org/jira/browse/FELIX-4190 Project: Felix Issue Type: Bug Components: Framework Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: framework-4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Maybe a Felix Framework release sometime soon?
I'm OK with Guillames updated patch idea. many thanks david jencks On Mar 11, 2014, at 1:50 AM, David Bosschaert david.bosscha...@gmail.com wrote: I would really like to start getting this release out, any comments on Guillaume's updated patch? If nobody has any comments I can just apply it and get the release process rolling. Cheers, David On 24 February 2014 14:07, Guillaume Nodet gno...@apache.org wrote: I just proposed a patch for FELIX-4190, so comments are welcomed. 2014-02-24 9:50 GMT+01:00 Guillaume Nodet gno...@apache.org: Do you have a patch that you could attach to FELIX-3687 that I could look at ? Again, I have no problems reverting my patch, but I'd like FELIX-3687 / FELIX-4190 to be fixed in some way or another, preferably the best one ... Cheers, Guillaume 2014-02-23 19:25 GMT+01:00 David Jencks david_jen...@yahoo.com: As I've said before, I sort of need some advice on how to proceed to fix the deadlock. I'm slightly in favor of just rolling back Guillaume's fix since it is definitely not spec compliant. Whether the deadlock is more spec compliant is certainly debatable. david jencks On Feb 23, 2014, at 8:14 AM, David Bosschaert david.bosscha...@gmail.com wrote: Hi all, It's been a while since this thread was started. I see that there is a desire to improve on the locking, but nothing has happened in that area over the past month. I was thinking to start putting together a release early March, since it will be nice to have R5 core support in a release. If we can get the locking code improved before that then great, but was thinking that if nothing has happened there we should postpone FELIX-3687/FELIX-4190 to a later release? Thought anyone? Cheers, David On 30 January 2014 08:53, Guillaume Nodet gno...@apache.org wrote: I don't have any problem reverting my fix if you have a better one ;-) 2014-01-18 David Jencks david_jen...@yahoo.com I hope that someone cleans up the mess around https://issues.apache.org/jira/browse/FELIX-3687 and https://issues.apache.org/jira/browse/FELIX-4190 before a release candidate. In the first issue I proposed a patch, Richard pointed out a problem, and I suggested a possible solution and haven't gotten any comments. In the 2nd issue Guillaume committed a fix that is invalid and AFAIK it has not been corrected. thanks david jencks On Jan 17, 2014, at 8:40 AM, David Bosschaert david.bosscha...@gmail.com wrote: On 17 January 2014 16:16, Carsten Ziegeler cziege...@apache.org wrote: +1 for a new framework release, it would be great to have full R5 support, but if that is not supposed to happen soon Full disclosure: I tried my hand on those resolver related open issues, but had the feeling that I didn't understand the Felix code well enough for it. The resolver is a pretty complex beast, especially since it's recursive/re-entrant and I found that fixing one little issue would cause tons of other things to fall over elsewhere ;) In the end I often came up with a patchwork of fixes for one resolver CT test failure where I had the feeling that it could be done more elegantly. so in the end I abandoned my attempts here... I think those remaining resolver issues are for someone who really knows the felix resolver code inside out :) Cheers, David
