[jira] [Created] (FELIX-4457) org.apache.felix.utils.properties will save key=value on top of comments if the original properties file are all comments
Freeman Fang created FELIX-4457:
---
Summary: org.apache.felix.utils.properties will save key=value on
top of comments if the original properties file are all comments
Key: FELIX-4457
URL: https://issues.apache.org/jira/browse/FELIX-4457
Project: Felix
Issue Type: Bug
Components: Utils
Reporter: Freeman Fang
for example if the properties file looks like
{code}
#
# just a comment
#
{code}
then if we add a property into this file and save it we get something like
{code}
key1 = value1
#
# just a comment
#
{code}
we should get
{code}
#
# just a comment
#
key1 = value1
{code}
instead
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Work started] (FELIX-4457) org.apache.felix.utils.properties will save key=value on top of comments if the original properties file are all comments
[
https://issues.apache.org/jira/browse/FELIX-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-4457 started by Freeman Fang.
org.apache.felix.utils.properties will save key=value on top of comments if
the original properties file are all comments
-
Key: FELIX-4457
URL: https://issues.apache.org/jira/browse/FELIX-4457
Project: Felix
Issue Type: Bug
Components: Utils
Reporter: Freeman Fang
Assignee: Freeman Fang
for example if the properties file looks like
{code}
#
# just a comment
#
{code}
then if we add a property into this file and save it we get something like
{code}
key1 = value1
#
# just a comment
#
{code}
we should get
{code}
#
# just a comment
#
key1 = value1
{code}
instead
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (FELIX-4457) org.apache.felix.utils.properties will save key=value on top of comments if the original properties file are all comments
[
https://issues.apache.org/jira/browse/FELIX-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned FELIX-4457:
---
Assignee: Freeman Fang
org.apache.felix.utils.properties will save key=value on top of comments if
the original properties file are all comments
-
Key: FELIX-4457
URL: https://issues.apache.org/jira/browse/FELIX-4457
Project: Felix
Issue Type: Bug
Components: Utils
Reporter: Freeman Fang
Assignee: Freeman Fang
for example if the properties file looks like
{code}
#
# just a comment
#
{code}
then if we add a property into this file and save it we get something like
{code}
key1 = value1
#
# just a comment
#
{code}
we should get
{code}
#
# just a comment
#
key1 = value1
{code}
instead
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: Maybe a Felix Framework release sometime soon?
That would be fantastic, Karl! I think the issues around the locking are now resolved: FELIX-4190 is resolved and I think we can close FELIX-3687 as well (correct David J?). I'll run trunk through the OSGi R5 CT today to double check that everything is still passing there and will let you know when that's done. Cheers, David On 11 March 2014 12:58, Karl Pauls karlpa...@gmail.com wrote: 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
[jira] [Resolved] (FELIX-3687) Deadlock potential from ServiceRegistry.unregisterService
[
https://issues.apache.org/jira/browse/FELIX-3687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-3687.
Resolution: Duplicate
Deadlock potential from ServiceRegistry.unregisterService
-
Key: FELIX-3687
URL: https://issues.apache.org/jira/browse/FELIX-3687
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-4.0.3
Reporter: David Jencks
Attachments: FELIX-3687-1.diff
At the end of unregisterService there's this block:
{code}
// Now forcibly unget the service object for all stubborn clients.
synchronized (this)
{
Bundle[] clients = getUsingBundles(reg.getReference());
for (int i = 0; (clients != null) (i clients.length); i++)
{
while (ungetService(clients[i], reg.getReference()))
; // Keep removing until it is no longer possible
}
((ServiceRegistrationImpl) reg).invalidate();
}
{code}
Note the call to ungetService from within a synchronized block. ungetService
itself is very careful to release the lock before calling out to the service
factory, however this call from unregisterService negates this care.
This causes problems with DS with thread dumps like:
{code}
ThreadId: 16 : name: SCR Component Actor State: RUNNABLE
LockInfo: null LockOwnerId: -1 LockOwnerName: null
sun.management.ThreadImpl.dumpThreads0(Native Method)
sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:433)
org.apache.felix.scr.impl.manager.AbstractComponentManager.dumpThreads(AbstractComponentManager.java:294)
org.apache.felix.scr.impl.manager.AbstractComponentManager.logLockingInfo(AbstractComponentManager.java:240)
org.apache.felix.scr.impl.manager.AbstractComponentManager.releaseReadLock(AbstractComponentManager.java:222)
org.apache.felix.scr.impl.manager.ImmediateComponentManager.ungetService(ImmediateComponentManager.java:710)
org.apache.felix.framework.ServiceRegistrationImpl.ungetFactoryUnchecked(ServiceRegistrationImpl.java:349)
org.apache.felix.framework.ServiceRegistrationImpl.ungetService(ServiceRegistrationImpl.java:258)
org.apache.felix.framework.ServiceRegistry.ungetService(ServiceRegistry.java:389)
org.apache.felix.framework.Felix.ungetService(Felix.java:3432)
org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextImpl.java:486)
org.apache.felix.scr.impl.manager.DependencyManager.ungetService(DependencyManager.java:900)
org.apache.felix.scr.impl.manager.DependencyManager.unbind(DependencyManager.java:1138)
org.apache.felix.scr.impl.manager.DependencyManager.close(DependencyManager.java:970)
org.apache.felix.scr.impl.manager.ImmediateComponentManager.disposeImplementationObject(ImmediateComponentManager.java:276)
org.apache.felix.scr.impl.manager.ImmediateComponentManager.deleteComponent(ImmediateComponentManager.java:148)
org.apache.felix.scr.impl.manager.AbstractComponentManager$Active.ungetService(AbstractComponentManager.java:1718)
org.apache.felix.scr.impl.manager.ImmediateComponentManager.ungetService(ImmediateComponentManager.java:695)
org.apache.felix.framework.ServiceRegistrationImpl.ungetFactoryUnchecked(ServiceRegistrationImpl.java:349)
org.apache.felix.framework.ServiceRegistrationImpl.ungetService(ServiceRegistrationImpl.java:258)
org.apache.felix.framework.ServiceRegistry.ungetService(ServiceRegistry.java:389)
inside the lock
org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:158)
org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:779)
org.apache.felix.scr.impl.manager.AbstractComponentManager$State.doDeactivate(AbstractComponentManager.java:1387)
org.apache.felix.scr.impl.manager.AbstractComponentManager$Satisfied.deactivate(AbstractComponentManager.java:1665)
org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:635)
org.apache.felix.scr.impl.manager.DependencyManager.serviceRemoved(DependencyManager.java:375)
org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:217)
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260)
[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=13933001#comment-13933001
]
Benjamin Debeerst commented on FELIX-4455:
--
Yes, I recompiled with {{mvn clean package}} each time. I used manipulator
version 1.11.1 (maven plugin), but the same also happenend for 1.10.1.
The project on GitHub is a proper maven project, so it should be possible to
simply build and run it.
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] [Comment Edited] (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=13933001#comment-13933001
]
Benjamin Debeerst edited comment on FELIX-4455 at 3/13/14 8:36 AM:
---
Yes, I recompiled with {{mvn clean package}} each time. I used manipulator
version 1.11.1 (maven plugin), but the same also happenend for 1.10.1.
The [project on
GitHub|https://github.com/BenjaminDebeerst/ipojo-component-constructor-sample]
is a proper maven project, so it should be possible to simply clone, build and
run it.
was (Author: benjamindebeerst):
Yes, I recompiled with {{mvn clean package}} each time. I used manipulator
version 1.11.1 (maven plugin), but the same also happenend for 1.10.1.
The project on GitHub is a proper maven project, so it should be possible to
simply build and run it.
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-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=13933018#comment-13933018
]
Guillaume Sauthier commented on FELIX-4455:
---
Hi Benjamin, what do you expect from iPOJO ?
* A clean error message stating that you need a manageable (callable from the
container) constructor ?
* iPOJO to work with this constructor scheme ?
AFAICT, option 2 is not workable (except if you use the {{{@Property}}} on the
parameter): any container (not only iPOJO) will have the same issue.
What you could try is to have a default constructor (no params) that call the
parametered constructor.
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)
Re: Maybe a Felix Framework release sometime soon?
I have run the framework on trunk throught the OSGi R5 CT: org.osgi.test.cases.framework org.osgi.test.cases.framework.launch The about suites are all passing. I did run into some issues around the security tests: org.osgi.test.cases.framework.secure org.osgi.test.cases.framework.launch.secure I passed on the details to Karl, hopefully he can figure out what's going on there ... Cheers, David On 13 March 2014 08:04, David Bosschaert david.bosscha...@gmail.com wrote: That would be fantastic, Karl! I think the issues around the locking are now resolved: FELIX-4190 is resolved and I think we can close FELIX-3687 as well (correct David J?). I'll run trunk through the OSGi R5 CT today to double check that everything is still passing there and will let you know when that's done. Cheers, David On 11 March 2014 12:58, Karl Pauls karlpa...@gmail.com wrote: 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
[REPORT] Apache Felix
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. Community - PMC: No new PMC members have been added in this report period. The last new PMC member was added in Dec. 2013 - Committers: David Bosschaert has been added as a committer on Dec. 20, 2013 - Steady mailing list activity. - There are no issues requiring board attention at this time. Software - Apache Felix Utils 1.6.0 (March 5, 2014) - Apache Felix Declarative Services (SCR) 1.8.2 (January 21, 2014) - Apache Felix Inventory 1.0.4 (March 3, 2014) - Apache Felix Jaas 0.0.2 (Feburary 17, 2014) - Apache Felix Web Console 4.2.2 (Feburary 06, 2014) - Apache Felix Inventory 1.0.2 (Feburary 06, 2014) - Apache Felix iPOJO Runtime and Manipulator 1.11.1 (January 29, 2014) - Apache Felix Metatype 1.0.10 (January 19, 2014) - Apache Felix Coordinator 1.0.0 (January 19, 2014) - Apache Felix AutoConf Processor 0.1.5 (December 10, 2013) - Apache Felix DeploymentAdmin 0.9.5 (December 10, 2013) - Apache Felix HTTP Service 2.2.2 (December 10, 2013) Project Branding - TM missing from all Logos Licensing and other issues - None Regards Felix
[jira] [Created] (FELIX-4458) maven-bundle-plugin cannot find dependencies (in multi-module project)
Valentin Valchev created FELIX-4458: --- Summary: maven-bundle-plugin cannot find dependencies (in multi-module project) Key: FELIX-4458 URL: https://issues.apache.org/jira/browse/FELIX-4458 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.4.0 Environment: Maven 3.1.1 Reporter: Valentin Valchev I have a multi-module maven project. 1. module 1 is a BND plugin 2. module 2 is general pom file, that should be used by other projects. In module 2 I've setup BND to run my plugin. I also need to set a dependency to module1, so the plugin will be in the class path and BND will find it. When I try to build the project from the root folder, it fails, because maven-bundle-plugin cannot find the dependency module 1. Weird think is that I've tried to add the same module as dependency to the maven-compiler-plugin, and it works perfectly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4458) maven-bundle-plugin cannot find dependencies (in multi-module project)
[ https://issues.apache.org/jira/browse/FELIX-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev updated FELIX-4458: Attachment: tc.7z I've stripped down a little bit the pom files I have and here is a minimal example showing the problem. maven-bundle-plugin cannot find dependencies (in multi-module project) -- Key: FELIX-4458 URL: https://issues.apache.org/jira/browse/FELIX-4458 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.4.0 Environment: Maven 3.1.1 Reporter: Valentin Valchev Attachments: tc.7z I have a multi-module maven project. 1. module 1 is a BND plugin 2. module 2 is general pom file, that should be used by other projects. In module 2 I've setup BND to run my plugin. I also need to set a dependency to module1, so the plugin will be in the class path and BND will find it. When I try to build the project from the root folder, it fails, because maven-bundle-plugin cannot find the dependency module 1. Weird think is that I've tried to add the same module as dependency to the maven-compiler-plugin, and it works perfectly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (FELIX-4458) maven-bundle-plugin cannot find dependencies (in multi-module project)
[ https://issues.apache.org/jira/browse/FELIX-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933068#comment-13933068 ] Valentin Valchev edited comment on FELIX-4458 at 3/13/14 10:20 AM: --- I've stripped down a little bit the pom files I have and here is attached a minimal example showing the problem. was (Author: v_valchev): I've stripped down a little bit the pom files I have and here is a minimal example showing the problem. maven-bundle-plugin cannot find dependencies (in multi-module project) -- Key: FELIX-4458 URL: https://issues.apache.org/jira/browse/FELIX-4458 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.4.0 Environment: Maven 3.1.1 Reporter: Valentin Valchev Attachments: tc.7z I have a multi-module maven project. 1. module 1 is a BND plugin 2. module 2 is general pom file, that should be used by other projects. In module 2 I've setup BND to run my plugin. I also need to set a dependency to module1, so the plugin will be in the class path and BND will find it. When I try to build the project from the root folder, it fails, because maven-bundle-plugin cannot find the dependency module 1. Weird think is that I've tried to add the same module as dependency to the maven-compiler-plugin, and it works perfectly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[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=13933073#comment-13933073
]
Benjamin Debeerst commented on FELIX-4455:
--
I would expected iPOJO to do either of the following:
# Raise an error (preferrably at manipulation/compile time), that a required
(default) constructor is missing to perform field injection of properties and
referenced services
# Generate the default constructor, but _without skipping field instantiation_.
The last part is the most important thing. I implemented a component with an
internal field, carefully making sure that field can never be null - among
others by instantiating at declaration. But then I throw the component into the
runtime and at once get unexpected NPEs, because in some unknown way, iPOJO
instantiated the class but not it's fields.
If I define a class like this:
{code}
@Component
public class MyClass {
private String internal = Default;
}
{code}
I expect that any fresh class instance has a non-null {{internal}} field -
provided the constructor does not overwrite the default value.
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-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=13933101#comment-13933101
]
Guillaume Sauthier commented on FELIX-4455:
---
Ok understood
From the iPOJO point of view, your component is invalid because it miss a
manageable constructor. I think that iPOJO should complain with an
understandable error message :)
I'm not sure it's a good practice to generate a default constructor for the
user if he (maybe intentionally) omit it. It make things harder to debug
because, you'll assume that what is executed is your code where in fact, iPOJO
is doing its own stuff.
What you see is a side effect of the ipojo manipulation: because it does not
stop if no manageable constructor is found, it process the class as usual:
build a new default constructor from scratch, and doing this, it miss the
assignment. This is because, in bytecode, the assignment is done in the
constructor, so if you generate one (instead of modifying one that contains the
instruction), you won't have the assignment for free...
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-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=13933190#comment-13933190
]
Benjamin Debeerst commented on FELIX-4455:
--
I'm good with both solutions.
But:
{quote}
it processes the class as usual: build a new default constructor from scratch,
and doing this, it misses the assignment
{quote}
Isn't this wrong for the usual case as well? I think it should definitely
consider default assignments of fields whenever constructors are generated.
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-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=13933211#comment-13933211
]
Guillaume Sauthier commented on FELIX-4455:
---
As I said, default field assignment is done in the constructor, not outside of
it in the bytecode.
That means that for your component example, the compiled bytecode looks like
this:
{code:java}
@Component
public class MyClass {
private String internal;
public MyClass() {
internal = Default;
}
}{code}
So, in this case, iPOJO modifies a correct constructor.
What you miss is that, once you defined your own constructor, there is no more
the default one available in the bytecode.
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)
Re: [VOTE] Release of iPOJO Manipulator and Runtime 1.11.2
+1 2014-03-12 10:41 GMT+01:00 Carsten Ziegeler cziege...@apache.org: +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] [Assigned] (FELIX-4456) openConnection().getContentLengthLong() always returns -1 for bundle URLs on Java7
[ https://issues.apache.org/jira/browse/FELIX-4456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls reassigned FELIX-4456: - Assignee: Karl Pauls 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 Assignee: Karl Pauls 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)
[jira] [Commented] (FELIX-3067) Prevent Deadlock Situation in Felix.acquireGlobalLock
[
https://issues.apache.org/jira/browse/FELIX-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933314#comment-13933314
]
metatech commented on FELIX-3067:
-
Here is another example of deadlock, between Blueprint and Felix.
The error reporting is implemented in the patch felix_unblock_deadlock.
{code}
ERROR: Waited 60 seconds to acquire the global lock held by blocked thread :
FelixPackageAdmin (java.lang.RuntimeException: Waited 60 seconds to acquire the
global lock held by blocked thread : FelixPackageAdmin)
java.lang.RuntimeException: Waited 60 seconds to acquire the global lock held
by blocked thread : FelixPackageAdmin
at org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5026)
at org.apache.felix.framework.Felix.access$600(Felix.java:80)
at
org.apache.felix.framework.Felix$StatefulResolver.resolve(Felix.java:4197)
at
org.apache.felix.framework.ModuleImpl.searchDynamicImports(ModuleImpl.java:1448)
at
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:759)
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:72)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1807)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:249)
at java.sql.DriverManager.getCallerClass(DriverManager.java:477)
at java.sql.DriverManager.getDriver(DriverManager.java:246)
at
org.apache.commons.dbcp.BasicDataSource.createConnectionFactory(BasicDataSource.java:1437)
at
org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1371)
at
org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:1044)
at
org.apache.activemq.store.jdbc.TransactionContext.getConnection(TransactionContext.java:58)
at
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.loadAdapter(JDBCPersistenceAdapter.java:430)
at
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.createAdapter(JDBCPersistenceAdapter.java:413)
at
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.getAdapter(JDBCPersistenceAdapter.java:366)
at
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.init(JDBCPersistenceAdapter.java:287)
at
org.apache.activemq.broker.LockableServiceSupport.preStart(LockableServiceSupport.java:79)
at org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:54)
at
org.apache.activemq.broker.BrokerService.doStartPersistenceAdapter(BrokerService.java:623)
at
org.apache.activemq.broker.BrokerService.startPersistenceAdapter(BrokerService.java:612)
at
org.apache.activemq.broker.BrokerService.start(BrokerService.java:577)
at
org.apache.activemq.broker.BrokerService.autoStart(BrokerService.java:539)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:225)
at
org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:838)
at
org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:638)
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:726)
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:64)
at
org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:219)
at
org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:147)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:631)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:337)
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:230)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
[jira] [Commented] (FELIX-4436) DirectoryWatcher should not refresh Blueprint XML deployments on every start-up
[ https://issues.apache.org/jira/browse/FELIX-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933306#comment-13933306 ] metatech commented on FELIX-4436: - Hi Uwe, Thanks for looking into this issue. I tried your patch but it does not change my observations : on every start-up, the Blueprint XML are still refreshed. To be honest, I do not understand how your patch is supposed to solve the problem, could you please elaborate ? Also, I notice that on Windows, the path extraction algorithm does not work, because there is an extra colon in the path, eg C:/ Regards, metatech DirectoryWatcher should not refresh Blueprint XML deployments on every start-up - Key: FELIX-4436 URL: https://issues.apache.org/jira/browse/FELIX-4436 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-3.2.4 Environment: ServiceMix 4.5.3 Reporter: metatech Priority: Minor Attachments: felix_no_refresh_installed.patch DirectoryWatcher can auto-deploy JAR or XML files placed in a directory. Blueprint XML files (containing for instance ActiveMQ factories or JAAS realms) are detected as installed on every start-up. Prior to FELIX-2066, this had no effect. Since FELIX-2066, bundles detected as installed are now forcibly refreshed on every start-up. The impact is that these bundles are stopped and restarted during the container start-up. Because there are some race conditions (see FELIX-3067), this can prevent those XML files or other bundles depending on them from fully starting. Here is a patch which avoids restarting those bundles when they were not modified. -- This message was sent by Atlassian JIRA (v6.2#6252)
[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=13933359#comment-13933359
]
Benjamin Debeerst commented on FELIX-4455:
--
Okay, I understand.
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)
Re: [VOTE] Apache Felix SCR Tooling Release
Hi Carsten; Did some basic tests with the maven scrplugin, as well as with the new bndtools scrplugin. +1 kind regards; /Pierre On Wed, Mar 12, 2014 at 10:53 AM, Carsten Ziegeler cziege...@apache.orgwrote: 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] Release of iPOJO Manipulator and Runtime 1.11.2
Hi Clement; +1 kind regards; /Pierre On Tue, Mar 11, 2014 at 5:13 PM, Clement Escoffier clement.escoff...@gmail.com wrote: 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-4436) DirectoryWatcher should not refresh Blueprint XML deployments on every start-up
[ https://issues.apache.org/jira/browse/FELIX-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13934319#comment-13934319 ] ASF GitHub Bot commented on FELIX-4436: --- Github user barthel closed the pull request at: https://github.com/apache/felix/pull/3 DirectoryWatcher should not refresh Blueprint XML deployments on every start-up - Key: FELIX-4436 URL: https://issues.apache.org/jira/browse/FELIX-4436 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-3.2.4 Environment: ServiceMix 4.5.3 Reporter: metatech Priority: Minor Attachments: felix_no_refresh_installed.patch DirectoryWatcher can auto-deploy JAR or XML files placed in a directory. Blueprint XML files (containing for instance ActiveMQ factories or JAAS realms) are detected as installed on every start-up. Prior to FELIX-2066, this had no effect. Since FELIX-2066, bundles detected as installed are now forcibly refreshed on every start-up. The impact is that these bundles are stopped and restarted during the container start-up. Because there are some race conditions (see FELIX-3067), this can prevent those XML files or other bundles depending on them from fully starting. Here is a patch which avoids restarting those bundles when they were not modified. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4436) DirectoryWatcher should not refresh Blueprint XML deployments on every start-up
[
https://issues.apache.org/jira/browse/FELIX-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13934320#comment-13934320
]
Uwe Barthel commented on FELIX-4436:
Hi metatech,
Thx for review my patch.
{quote}
To be honest, I do not understand how your patch is supposed to solve the
problem, could you please elaborate ?
{quote}
The idea behind my patch is to prevent to put the bundle into the
{{installedBundles}} collection. This collection will be added into the
{{toRefresh}} set, which you comment out in your patch.
If you're going the way back, you'll find a long if-else statement. In this
if-else statement, it's about if the file exists and whether an {{Artifact}}
object exists.
If this {{Artifact}} object is not found, it is newly created and inserted into
the {{toRefresh}} set.
A list of all known {{Artifact}} objects is collected at startup in the method
{{#initializeCurrentManagedBundles()}}. Creating the {{Artifact}} object for
the Blueprint XML file based on the path of the found file and the Bundle
Location of the already known bundles.
I hope this and my explanation above, have explained my thought better.
{quote}
Also, I notice that on Windows, the path extraction algorithm does not work,
because there is an extra colon in the path, eg C:/
{quote}
You're absolutely right. My solution is not optimal at this point. Perhaps it
is better to search {{file:}}, instead of the last colon. This could be the
reason why it does not work for you.
I've change the implementation. Please try it again.
Did you run the {{DirectoryWatcherTest}} test?
Sincerely
barthel
DirectoryWatcher should not refresh Blueprint XML deployments on every
start-up
-
Key: FELIX-4436
URL: https://issues.apache.org/jira/browse/FELIX-4436
Project: Felix
Issue Type: Bug
Components: File Install
Affects Versions: fileinstall-3.2.4
Environment: ServiceMix 4.5.3
Reporter: metatech
Priority: Minor
Attachments: felix_no_refresh_installed.patch
DirectoryWatcher can auto-deploy JAR or XML files placed in a directory.
Blueprint XML files (containing for instance ActiveMQ factories or JAAS
realms) are detected as installed on every start-up. Prior to FELIX-2066,
this had no effect. Since FELIX-2066, bundles detected as installed are
now forcibly refreshed on every start-up. The impact is that these bundles
are stopped and restarted during the container start-up. Because there are
some race conditions (see FELIX-3067), this can prevent those XML files or
other bundles depending on them from fully starting. Here is a patch which
avoids restarting those bundles when they were not modified.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4436) DirectoryWatcher should not refresh Blueprint XML deployments on every start-up
[ https://issues.apache.org/jira/browse/FELIX-4436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13934322#comment-13934322 ] ASF GitHub Bot commented on FELIX-4436: --- GitHub user barthel opened a pull request: https://github.com/apache/felix/pull/4 Possible fix for [FELIX-4436] https://issues.apache.org/jira/browse/FELIX-4436 * handle bundle if bundle location is a opaque uri * use 'file:' instead of last index of colon for extract the path name from opaque uri * test added You can merge this pull request into a Git repository by running: $ git pull https://github.com/barthel/felix trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/felix/pull/4.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4 commit 008c1c43aca0b8d10f54f6eb1bf55854128e1614 Author: Uwe Barthel bart...@x-reizend.de Date: 2014-03-05T06:34:52Z [FELIX-4436] handle bundle if bundle location is a opaque uri commit b623ec0a2a607c4f8baa827660ba32bfdfccf09d Author: Uwe Barthel bart...@x-reizend.de Date: 2014-03-13T23:52:55Z [FELIX-4436] handle bundle if bundle location is a opaque uri * use 'file:' instead of last index of colon for extract the path name from opaque uri * test added DirectoryWatcher should not refresh Blueprint XML deployments on every start-up - Key: FELIX-4436 URL: https://issues.apache.org/jira/browse/FELIX-4436 Project: Felix Issue Type: Bug Components: File Install Affects Versions: fileinstall-3.2.4 Environment: ServiceMix 4.5.3 Reporter: metatech Priority: Minor Attachments: felix_no_refresh_installed.patch DirectoryWatcher can auto-deploy JAR or XML files placed in a directory. Blueprint XML files (containing for instance ActiveMQ factories or JAAS realms) are detected as installed on every start-up. Prior to FELIX-2066, this had no effect. Since FELIX-2066, bundles detected as installed are now forcibly refreshed on every start-up. The impact is that these bundles are stopped and restarted during the container start-up. Because there are some race conditions (see FELIX-3067), this can prevent those XML files or other bundles depending on them from fully starting. Here is a patch which avoids restarting those bundles when they were not modified. -- This message was sent by Atlassian JIRA (v6.2#6252)
[GitHub] felix pull request: [FELIX-4436] handle bundle if bundle location ...
Github user barthel closed the pull request at: https://github.com/apache/felix/pull/3 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] felix pull request: Possible fix for [FELIX-4436] https://issues.a...
GitHub user barthel opened a pull request: https://github.com/apache/felix/pull/4 Possible fix for [FELIX-4436] https://issues.apache.org/jira/browse/FELIX-4436 * handle bundle if bundle location is a opaque uri * use 'file:' instead of last index of colon for extract the path name from opaque uri * test added You can merge this pull request into a Git repository by running: $ git pull https://github.com/barthel/felix trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/felix/pull/4.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4 commit 008c1c43aca0b8d10f54f6eb1bf55854128e1614 Author: Uwe Barthel bart...@x-reizend.de Date: 2014-03-05T06:34:52Z [FELIX-4436] handle bundle if bundle location is a opaque uri commit b623ec0a2a607c4f8baa827660ba32bfdfccf09d Author: Uwe Barthel bart...@x-reizend.de Date: 2014-03-13T23:52:55Z [FELIX-4436] handle bundle if bundle location is a opaque uri * use 'file:' instead of last index of colon for extract the path name from opaque uri * test added --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [GitHub] felix pull request: Possible fix for [FELIX-4436] https://issues.a...
To me, these pull request are sort of annoying, since we don't even use git for the Felix source repo... - richard On 3/13/14, 20:00 , barthel wrote: GitHub user barthel opened a pull request: https://github.com/apache/felix/pull/4 Possible fix for [FELIX-4436] https://issues.apache.org/jira/browse/FELIX-4436 * handle bundle if bundle location is a opaque uri * use 'file:' instead of last index of colon for extract the path name from opaque uri * test added You can merge this pull request into a Git repository by running: $ git pull https://github.com/barthel/felix trunk Alternatively you can review and apply these changes as the patch at: https://github.com/apache/felix/pull/4.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #4 commit 008c1c43aca0b8d10f54f6eb1bf55854128e1614 Author: Uwe Barthel bart...@x-reizend.de Date: 2014-03-05T06:34:52Z [FELIX-4436] handle bundle if bundle location is a opaque uri commit b623ec0a2a607c4f8baa827660ba32bfdfccf09d Author: Uwe Barthel bart...@x-reizend.de Date: 2014-03-13T23:52:55Z [FELIX-4436] handle bundle if bundle location is a opaque uri * use 'file:' instead of last index of colon for extract the path name from opaque uri * test added --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
