[jira] [Resolved] (FELIX-4449) The ConfigurationListener list contains duplicates and fires update on unchanged configurations
[ https://issues.apache.org/jira/browse/FELIX-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-4449. -- Resolution: Fixed Fixed in 1.11.2 The ConfigurationListener list contains duplicates and fires update on unchanged configurations --- Key: FELIX-4449 URL: https://issues.apache.org/jira/browse/FELIX-4449 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.11.0 Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-runtime-1.11.2 The configuration handler holds a list of configuration listeners. This list should not contain duplicates. In addition, these listeners should not be notified when when there are no change in the reconfiguration. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4160) Create an Maven Parent POM for iPOJO
[ https://issues.apache.org/jira/browse/FELIX-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-4160: - Fix Version/s: (was: ipojo-runtime-1.11.2) Create an Maven Parent POM for iPOJO Key: FELIX-4160 URL: https://issues.apache.org/jira/browse/FELIX-4160 Project: Felix Issue Type: Improvement Components: iPOJO Reporter: Guillaume Sauthier Assignee: Guillaume Sauthier Most of our released modules are sharing some configurations (rat + checkstyle at least). It would be nice to have all theses options, plugins, ... stored in 1 place. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FELIX-3931) Provide a handler to inject the bundle context
[ https://issues.apache.org/jira/browse/FELIX-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-3931. -- Resolution: Fixed Fixed in 1.11.2 Provide a handler to inject the bundle context -- Key: FELIX-3931 URL: https://issues.apache.org/jira/browse/FELIX-3931 Project: Felix Issue Type: Improvement Components: iPOJO Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-runtime-1.11.2 Provide a handler to inject the bundle context: - as a field injection - as a constructor injection The handler can inject 3 bundle context: - the bundle context of the bundle containing the implementation - the bundle context of the bundle declaring the instance - for handlers, the bundle context of the bundle containing the handler implementation -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4276) Let stereotypes have attributes
[ https://issues.apache.org/jira/browse/FELIX-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier updated FELIX-4276: - Fix Version/s: (was: ipojo-manipulator-1.11.2) Let stereotypes have attributes --- Key: FELIX-4276 URL: https://issues.apache.org/jira/browse/FELIX-4276 Project: Felix Issue Type: New Feature Components: iPOJO Reporter: Clement Escoffier Assignee: Guillaume Sauthier -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FELIX-4448) Invalid dynamism management when an interceptor implements both Tracking and Ranking interceptors
[ https://issues.apache.org/jira/browse/FELIX-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier resolved FELIX-4448. -- Resolution: Fixed Fixed in 1.11.2 Invalid dynamism management when an interceptor implements both Tracking and Ranking interceptors - Key: FELIX-4448 URL: https://issues.apache.org/jira/browse/FELIX-4448 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.11.0 Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-runtime-1.11.2 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (FELIX-4393) @Property should accept empty name values on instance fields
[
https://issues.apache.org/jira/browse/FELIX-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler resolved FELIX-4393.
-
Resolution: Fixed
@Property should accept empty name values on instance fields
--
Key: FELIX-4393
URL: https://issues.apache.org/jira/browse/FELIX-4393
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: scr annotations 1.9.6
Reporter: james strachan
Assignee: Carsten Ziegeler
Fix For: scr annotations 1.9.8
it'd be nice if @Property behaved like various other annotations (e.g.
@Inject / @Resource) so that if a name is not specified and @Property is
specified on a field, then the name value defaults to the field name.
It looks like name is optional with a default of - so its just the maven
scr plugin which seems to barf if name is empty generating this kind of
compile error:
{code}
@Property : Property name can not be empty.
{code}
It'd be nice if the name was optional; it makes the code more DRY and keeps
things more refactoring safe etc
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (FELIX-4449) The ConfigurationListener list contains duplicates and fires update on unchanged configurations
[ https://issues.apache.org/jira/browse/FELIX-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier closed FELIX-4449. iPOJO Runtime and Manipulator 1.11.2 release process has started. The ConfigurationListener list contains duplicates and fires update on unchanged configurations --- Key: FELIX-4449 URL: https://issues.apache.org/jira/browse/FELIX-4449 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.11.0 Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-runtime-1.11.2 The configuration handler holds a list of configuration listeners. This list should not contain duplicates. In addition, these listeners should not be notified when when there are no change in the reconfiguration. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (FELIX-4229) Provide a way to obtain the component's BundleContext (other than constructor injection)
[
https://issues.apache.org/jira/browse/FELIX-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clement Escoffier closed FELIX-4229.
iPOJO Runtime and Manipulator 1.11.2 release process has started.
Provide a way to obtain the component's BundleContext (other than constructor
injection)
Key: FELIX-4229
URL: https://issues.apache.org/jira/browse/FELIX-4229
Project: Felix
Issue Type: Bug
Components: iPOJO
Reporter: Guillaume Sauthier
Assignee: Clement Escoffier
Fix For: ipojo-runtime-1.11.2
Currently, the only common way to get the component's BundleContext is to use
constructor injection.
If we need a no-arg constructor, this is not possible to use that feature.
It is also possible to be the BundleContext though @PostRegistration
annotation, but it's only usable if your component provides a service.
I need another way to get my BundleContext.
Maybe something like:
{code}
@Requires / @Inject
private BundleContext bundleContext;
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (FELIX-4448) Invalid dynamism management when an interceptor implements both Tracking and Ranking interceptors
[ https://issues.apache.org/jira/browse/FELIX-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier closed FELIX-4448. iPOJO Runtime and Manipulator 1.11.2 release process has started. Invalid dynamism management when an interceptor implements both Tracking and Ranking interceptors - Key: FELIX-4448 URL: https://issues.apache.org/jira/browse/FELIX-4448 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.11.0 Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-runtime-1.11.2 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (FELIX-4432) DefaultServiceRankingInterceptor holds duplicate dependencies
[ https://issues.apache.org/jira/browse/FELIX-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier closed FELIX-4432. iPOJO Runtime and Manipulator 1.11.2 release process has started. DefaultServiceRankingInterceptor holds duplicate dependencies - Key: FELIX-4432 URL: https://issues.apache.org/jira/browse/FELIX-4432 Project: Felix Issue Type: Bug Components: iPOJO Affects Versions: ipojo-runtime-1.11.1 Reporter: Bengt Rodehav Assignee: Clement Escoffier Priority: Minor Fix For: ipojo-runtime-1.11.2 It seems like every dependency is duplicated in the member dependencies in class DefaultServiceRankingInterceptor. This has been discussed on the mailing list: http://www.mail-archive.com/users@felix.apache.org/msg15121.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (FELIX-3931) Provide a handler to inject the bundle context
[ https://issues.apache.org/jira/browse/FELIX-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Clement Escoffier closed FELIX-3931. iPOJO Runtime and Manipulator 1.11.2 release process has started. Provide a handler to inject the bundle context -- Key: FELIX-3931 URL: https://issues.apache.org/jira/browse/FELIX-3931 Project: Felix Issue Type: Improvement Components: iPOJO Reporter: Clement Escoffier Assignee: Clement Escoffier Fix For: ipojo-runtime-1.11.2 Provide a handler to inject the bundle context: - as a field injection - as a constructor injection The handler can inject 3 bundle context: - the bundle context of the bundle containing the implementation - the bundle context of the bundle declaring the instance - for handlers, the bundle context of the bundle containing the handler implementation -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4135) Bnd scrplugin contrib
[ https://issues.apache.org/jira/browse/FELIX-4135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-4135: Fix Version/s: scr bnd plugin 1.0.0 Bnd scrplugin contrib - Key: FELIX-4135 URL: https://issues.apache.org/jira/browse/FELIX-4135 Project: Felix Issue Type: Improvement Components: SCR Tooling Reporter: Pierre De Rop Assignee: Pierre De Rop Priority: Minor Fix For: scr bnd plugin 1.0.0 Attachments: bnd-scr-plugin.2.tgz, bnd-scr-plugin.3.tgz, bnd-scr-plugin.tgz, test.bndtools.scrplugin.2.tgz, test.bndtools.scrplugin.tgz This issue is related to the following post, which is about writing a bndtools plugin for the Apache Felix Scrplugin annotations: http://www.mail-archive.com/dev@felix.apache.org/msg29200.html If this may help, I have attached to this issue a simple BND plugin, which internally invokes the SCRDescriptorGenerator in order to generate the descriptors for Apache Felix Scr annotations, as well as DS 1.2 annotations (using the scrplugin generator). Basically, just adding the following parameter in a directives.bnd file allows to invoke the plugin: -plugin org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=target/classes I did some tests using a BND Ant task, and it seems to work, and will try to do a test with bndtools this week (for now I don't know how to add a plugin in bndtools, but I guess it's easy). -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [VOTE] Release of iPOJO Manipulator and Runtime 1.11.2
+1 2014-03-11 17:13 GMT+01:00 Clement Escoffier clement.escoff...@gmail.com: 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 -- Carsten Ziegeler cziege...@apache.org
[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=13931583#comment-13931583
]
Benjamin Debeerst commented on FELIX-4455:
--
Then I get {{createInstance - Cannot invoke the constructor (method not
found)}} and {{Cannot create a POJO instance, the POJO constructor cannot be
found}}.
Full stack:
{code}
2014-03-12 10:38:51,156 | ERROR | pool-1-thread-1 | ipojo-constructor
| 91 - com.example.ipojo-constructor - 1.0.0.SNAPSHOT | [ERROR] :
[com.example.ComponentWithoutDefaultConstructor-0] createInstance - Cannot
invoke the constructor (method not found) :
com.example.ComponentWithoutDefaultConstructor.init(org.apache.felix.ipojo.InstanceManager,
null)
java.lang.NoSuchMethodException:
com.example.ComponentWithoutDefaultConstructor.init(org.apache.felix.ipojo.InstanceManager,
null)
at java.lang.Class.getConstructor0(Class.java:2800)[:1.7.0_25]
at java.lang.Class.getDeclaredConstructor(Class.java:2043)[:1.7.0_25]
at
org.apache.felix.ipojo.InstanceManager.createObject(InstanceManager.java:703)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.InstanceManager.getPojoObject(InstanceManager.java:923)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.__M_stateChanged(LifecycleCallbackHandler.java:156)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.handlers.lifecycle.callback.LifecycleCallbackHandler.stateChanged(LifecycleCallbackHandler.java)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.InstanceManager.setState(InstanceManager.java:536)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.InstanceManager.start(InstanceManager.java:418)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.ComponentFactory.createInstance(ComponentFactory.java:179)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:319)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.IPojoFactory.createComponentInstance(IPojoFactory.java:240)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:312)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.extender.internal.linker.ManagedType$InstanceSupport$1.call(ManagedType.java:306)[84:org.apache.felix.ipojo:1.11.1]
at
org.apache.felix.ipojo.extender.internal.queue.JobInfoCallable.call(JobInfoCallable.java:114
[84:org.apache.felix.ipojo:1.11.1]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_25]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_25]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)[:1.7.0_25]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)[:1.7.0_25]
at java.lang.Thread.run(Thread.java:724)[:1.7.0_25]
2014-03-12 10:38:51,156 | ERROR | pool-1-thread-1 | ipojo-constructor
| 91 - com.example.ipojo-constructor -1.0.0.SNAPSHOT | [ERROR]
com.example.ComponentWithoutDefaultConstructor : Cannot create a POJO instance,
the POJO constructor cannot be found
{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
[VOTE] Apache Felix SCR Tooling Release
Hi, It's time to cut a new release for our SCR Tooling. This release includes some bug fixes for Maven, Ant and our SCR annotations as well as the first release of our bnd plugin: Updates and Bug Fixes (identical for all three releases): https://issues.apache.org/jira/browse/FELIX/fixforversion/12325061 Apache Felix SCR Generator 1.9.0 Apache Felix Maven SCR Plugin 1.16.0 Apache Felix SCR Ant Task 1.10.0 Updates and Bug Fixes (identical for all three releases): https://issues.apache.org/jira/browse/FELIX/fixforversion/12324798/ Apache Felix SCR Annotations 1.9.8 New Release: Apache Felix SCR Bnd Plugin 1.0.0 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1012 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 1012 /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, Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [VOTE] Apache Felix SCR Tooling Release
+1, Regards, Clement On 12 mars 2014, at 10:53, Carsten Ziegeler cziege...@apache.org wrote: Hi, It's time to cut a new release for our SCR Tooling. This release includes some bug fixes for Maven, Ant and our SCR annotations as well as the first release of our bnd plugin: Updates and Bug Fixes (identical for all three releases): https://issues.apache.org/jira/browse/FELIX/fixforversion/12325061 Apache Felix SCR Generator 1.9.0 Apache Felix Maven SCR Plugin 1.16.0 Apache Felix SCR Ant Task 1.10.0 Updates and Bug Fixes (identical for all three releases): https://issues.apache.org/jira/browse/FELIX/fixforversion/12324798/ Apache Felix SCR Annotations 1.9.8 New Release: Apache Felix SCR Bnd Plugin 1.0.0 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1012 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 1012 /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, Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Maybe a Felix Framework release sometime soon?
I'll commit a fix asap (hopefully tomorrow evening). 2014-03-11 20:24 GMT+01:00 David Jencks david_jen...@yahoo.com: 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
[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=13932169#comment-13932169
]
Clement Escoffier commented on FELIX-4455:
--
Did you recompile the bundle in between ? Could you also tell me which version
of the manipulator (ant task or maven plugin) are you using ?
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] [Resolved] (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:all-tabpanel ] Guillaume Nodet resolved FELIX-4190. Resolution: Fixed Sending framework/src/main/java/org/apache/felix/framework/ServiceRegistry.java Transmitting file data . Committed revision 1576875. https://svn.apache.org/viewvc?view=revisionrevision=1576875 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)
[jira] [Created] (FELIX-4456) openConnection().getContentLengthLong() always returns -1 for bundle URLs on Java7
Stuart McCulloch created FELIX-4456: --- Summary: openConnection().getContentLengthLong() always returns -1 for bundle URLs on Java7 Key: FELIX-4456 URL: https://issues.apache.org/jira/browse/FELIX-4456 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-4.2.1 Reporter: Stuart McCulloch Java7 introduced a new method to URLConnection called getContentLengthLong. Felix's URLHandlersBundleURLConnection only overrides getContentLength, so the default getContentLengthLong implementation is left in place and always returns -1 for 'bundle' URLs when running Felix on Java7. The client-side workaround is to fall-back to getContentLength whenever getContentLengthLong returns -1, but it would be great if this could be fixed in a future framework release. -- This message was sent by Atlassian JIRA (v6.2#6252)
