from:"Bram Pouwelse"

[jira] [Commented] (FELIX-6180) Component initialization error message get's printed to sysout instead of logged to LogService

2019-09-11 Thread Bram Pouwelse (Jira)



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

Bram Pouwelse commented on FELIX-6180:
--

Attached a patch to initialize the default  {{SerialExecutor}} with the 
{{Logger}} used bu the {{ComponentImpl}} instance

> Component initialization error message get's printed to sysout instead of 
> logged to LogService
> --
>
> Key: FELIX-6180
> URL: https://issues.apache.org/jira/browse/FELIX-6180
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>Reporter: Bram Pouwelse
>Priority: Major
> Attachments: FELIX-6180.patch
>
>
> We had a broken component that failed to start (for a good reason): 
> {code:java}
> @Component(provides = Object.class)
> public class BrokenComponent {
> static final Locale defaultLocale = 
> Locale.forLanguageTag(System.getProperty("not.set"));
> }
> {code}
> The problem is not that it doesn't work BUT the error log  (see below) never 
> reached our central logging (which is consuming the log messages from the 
> LogService). 
> I this is caused by the fact that this is not an {{Exception}} but an 
> {{Error}}, that makes it propagate all the way to the {{SerialExecutor}} 
> which is initialized with a new {{Logger}} instance in {{ComponentImpl}} 
> instead of getting the {{Logger}} instance that was used to create the 
> {{ComponentImpl}}. 
> {code}
> ERROR: [main] Error processing tasks (java.lang.ExceptionInInitializerError)
> java.lang.ExceptionInInitializerError
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at 
> org.apache.felix.dm.impl.InvocationUtil.createInstance(InvocationUtil.java:342)
> at 
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1073)
> at 
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1046)
> at 
> org.apache.felix.dm.impl.ComponentImpl.performTransition(ComponentImpl.java:1221)
> at 
> org.apache.felix.dm.impl.ComponentImpl.handleChange(ComponentImpl.java:1166)
> at 
> org.apache.felix.dm.impl.ComponentImpl.lambda$start$2(ComponentImpl.java:502)
> at 
> org.apache.felix.dm.impl.SerialExecutor.runTask(SerialExecutor.java:138)
> at 
> org.apache.felix.dm.impl.SerialExecutor.runTasks(SerialExecutor.java:120)
> at org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:86)
> at 
> org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:105)
> at org.apache.felix.dm.impl.ComponentImpl.start(ComponentImpl.java:500)
> at 
> org.apache.felix.dm.impl.ComponentScheduler.add(ComponentScheduler.java:69)
> at org.apache.felix.dm.DependencyManager.add(DependencyManager.java:141)
> at my.project.Activator.init(Activator.java:84)
> at 
> org.apache.felix.dm.DependencyActivatorBase.start(DependencyActivatorBase.java:79)
> at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:698)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2402)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> at aQute.launcher.Launcher.startBundles(Launcher.java:528)
> at aQute.launcher.Launcher.activate(Launcher.java:427)
> at aQute.launcher.Launcher.run(Launcher.java:306)
> at aQute.launcher.Launcher.main(Launcher.java:152)
> at aQute.launcher.pre.EmbeddedLauncher.main(EmbeddedLauncher.java:65)
> Caused by: java.lang.NullPointerException
> at sun.util.locale.LocaleUtils.toLowerString(LocaleUtils.java:89)
> at sun.util.locale.LanguageTag.parse(LanguageTag.java:191)
> at java.util.Locale.forLanguageTag(Locale.java:1568)
> at MyBrokenComponent.(UserTransformerV1_2.java:17)
> ... 28 more
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Updated] (FELIX-6180) Component initialization error message get's printed to sysout instead of logged to LogService

2019-09-11 Thread Bram Pouwelse (Jira)



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

Bram Pouwelse updated FELIX-6180:
-
Attachment: FELIX-6180.patch

> Component initialization error message get's printed to sysout instead of 
> logged to LogService
> --
>
> Key: FELIX-6180
> URL: https://issues.apache.org/jira/browse/FELIX-6180
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>Reporter: Bram Pouwelse
>Priority: Major
> Attachments: FELIX-6180.patch
>
>
> We had a broken component that failed to start (for a good reason): 
> {code:java}
> @Component(provides = Object.class)
> public class BrokenComponent {
> static final Locale defaultLocale = 
> Locale.forLanguageTag(System.getProperty("not.set"));
> }
> {code}
> The problem is not that it doesn't work BUT the error log  (see below) never 
> reached our central logging (which is consuming the log messages from the 
> LogService). 
> I this is caused by the fact that this is not an {{Exception}} but an 
> {{Error}}, that makes it propagate all the way to the {{SerialExecutor}} 
> which is initialized with a new {{Logger}} instance in {{ComponentImpl}} 
> instead of getting the {{Logger}} instance that was used to create the 
> {{ComponentImpl}}. 
> {code}
> ERROR: [main] Error processing tasks (java.lang.ExceptionInInitializerError)
> java.lang.ExceptionInInitializerError
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at 
> org.apache.felix.dm.impl.InvocationUtil.createInstance(InvocationUtil.java:342)
> at 
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1073)
> at 
> org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1046)
> at 
> org.apache.felix.dm.impl.ComponentImpl.performTransition(ComponentImpl.java:1221)
> at 
> org.apache.felix.dm.impl.ComponentImpl.handleChange(ComponentImpl.java:1166)
> at 
> org.apache.felix.dm.impl.ComponentImpl.lambda$start$2(ComponentImpl.java:502)
> at 
> org.apache.felix.dm.impl.SerialExecutor.runTask(SerialExecutor.java:138)
> at 
> org.apache.felix.dm.impl.SerialExecutor.runTasks(SerialExecutor.java:120)
> at org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:86)
> at 
> org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:105)
> at org.apache.felix.dm.impl.ComponentImpl.start(ComponentImpl.java:500)
> at 
> org.apache.felix.dm.impl.ComponentScheduler.add(ComponentScheduler.java:69)
> at org.apache.felix.dm.DependencyManager.add(DependencyManager.java:141)
> at my.project.Activator.init(Activator.java:84)
> at 
> org.apache.felix.dm.DependencyActivatorBase.start(DependencyActivatorBase.java:79)
> at 
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:698)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2402)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
> at aQute.launcher.Launcher.startBundles(Launcher.java:528)
> at aQute.launcher.Launcher.activate(Launcher.java:427)
> at aQute.launcher.Launcher.run(Launcher.java:306)
> at aQute.launcher.Launcher.main(Launcher.java:152)
> at aQute.launcher.pre.EmbeddedLauncher.main(EmbeddedLauncher.java:65)
> Caused by: java.lang.NullPointerException
> at sun.util.locale.LocaleUtils.toLowerString(LocaleUtils.java:89)
> at sun.util.locale.LanguageTag.parse(LanguageTag.java:191)
> at java.util.Locale.forLanguageTag(Locale.java:1568)
> at MyBrokenComponent.(UserTransformerV1_2.java:17)
> ... 28 more
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Updated] (FELIX-6180) Component initialization error message get's printed to sysout instead of logged to LogService

2019-09-11 Thread Bram Pouwelse (Jira)



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

Bram Pouwelse updated FELIX-6180:
-
Description: 
We had a broken component that failed to start (for a good reason): 

{code:java}
@Component(provides = Object.class)
public class BrokenComponent {

static final Locale defaultLocale = 
Locale.forLanguageTag(System.getProperty("not.set"));

}
{code}

The problem is not that it doesn't work BUT the error log  (see below) never 
reached our central logging (which is consuming the log messages from the 
LogService). 

I this is caused by the fact that this is not an {{Exception}} but an 
{{Error}}, that makes it propagate all the way to the {{SerialExecutor}} which 
is initialized with a new {{Logger}} instance in {{ComponentImpl}} instead of 
getting the {{Logger}} instance that was used to create the {{ComponentImpl}}. 


{code}
ERROR: [main] Error processing tasks (java.lang.ExceptionInInitializerError)
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at 
org.apache.felix.dm.impl.InvocationUtil.createInstance(InvocationUtil.java:342)
at 
org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1073)
at 
org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1046)
at 
org.apache.felix.dm.impl.ComponentImpl.performTransition(ComponentImpl.java:1221)
at 
org.apache.felix.dm.impl.ComponentImpl.handleChange(ComponentImpl.java:1166)
at 
org.apache.felix.dm.impl.ComponentImpl.lambda$start$2(ComponentImpl.java:502)
at org.apache.felix.dm.impl.SerialExecutor.runTask(SerialExecutor.java:138)
at org.apache.felix.dm.impl.SerialExecutor.runTasks(SerialExecutor.java:120)
at org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:86)
at org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:105)
at org.apache.felix.dm.impl.ComponentImpl.start(ComponentImpl.java:500)
at 
org.apache.felix.dm.impl.ComponentScheduler.add(ComponentScheduler.java:69)
at org.apache.felix.dm.DependencyManager.add(DependencyManager.java:141)
at my.project.Activator.init(Activator.java:84)
at 
org.apache.felix.dm.DependencyActivatorBase.start(DependencyActivatorBase.java:79)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:698)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2402)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
at aQute.launcher.Launcher.startBundles(Launcher.java:528)
at aQute.launcher.Launcher.activate(Launcher.java:427)
at aQute.launcher.Launcher.run(Launcher.java:306)
at aQute.launcher.Launcher.main(Launcher.java:152)
at aQute.launcher.pre.EmbeddedLauncher.main(EmbeddedLauncher.java:65)
Caused by: java.lang.NullPointerException
at sun.util.locale.LocaleUtils.toLowerString(LocaleUtils.java:89)
at sun.util.locale.LanguageTag.parse(LanguageTag.java:191)
at java.util.Locale.forLanguageTag(Locale.java:1568)
at MyBrokenComponent.(UserTransformerV1_2.java:17)
... 28 more
{code}


  was:
We had a broken component that failed to start (for a good reason): 

{code:java}
@Component(provides = Object.class)
public class BrokenComponent {

static final Locale defaultLocale = 
Locale.forLanguageTag(System.getProperty("not.set"));

}
{code}

The problem is not that it doesn't work BUT the error log  (see below) never 
reached our central logging (which is consuming the log messages from the 
LogService). 

I this is caused by the fact that this is not an {{Exception}} but an 
{{Error}}, that makes it propagate all the way to the {{SerialExecutor}} which 
is initialized with a new {{LogService}} instance in {{ComponentImpl}} instead 
of getting the {{LogService}} instance that was used to create the 
{{ComponentImpl}}. 


{code}
ERROR: [main] Error processing tasks (java.lang.ExceptionInInitializerError)
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at 
org.apache.felix.dm.impl.InvocationUtil.createInstance(InvocationUtil.java:342)
at 
org.apache.felix.dm.impl.ComponentImpl.instantiateCom

[jira] [Created] (FELIX-6180) Component initialization error message get's printed to sysout instead of logged to LogService

2019-09-11 Thread Bram Pouwelse (Jira)

Bram Pouwelse created FELIX-6180:


 Summary: Component initialization error message get's printed to 
sysout instead of logged to LogService
 Key: FELIX-6180
 URL: https://issues.apache.org/jira/browse/FELIX-6180
 Project: Felix
  Issue Type: Bug
  Components: Dependency Manager
Reporter: Bram Pouwelse


We had a broken component that failed to start (for a good reason): 

{code:java}
@Component(provides = Object.class)
public class BrokenComponent {

static final Locale defaultLocale = 
Locale.forLanguageTag(System.getProperty("not.set"));

}
{code}

The problem is not that it doesn't work BUT the error log  (see below) never 
reached our central logging (which is consuming the log messages from the 
LogService). 

I this is caused by the fact that this is not an {{Exception}} but an 
{{Error}}, that makes it propagate all the way to the {{SerialExecutor}} which 
is initialized with a new {{LogService}} instance in {{ComponentImpl}} instead 
of getting the {{LogService}} instance that was used to create the 
{{ComponentImpl}}. 


{code}
ERROR: [main] Error processing tasks (java.lang.ExceptionInInitializerError)
java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at 
org.apache.felix.dm.impl.InvocationUtil.createInstance(InvocationUtil.java:342)
at 
org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1073)
at 
org.apache.felix.dm.impl.ComponentImpl.instantiateComponent(ComponentImpl.java:1046)
at 
org.apache.felix.dm.impl.ComponentImpl.performTransition(ComponentImpl.java:1221)
at 
org.apache.felix.dm.impl.ComponentImpl.handleChange(ComponentImpl.java:1166)
at 
org.apache.felix.dm.impl.ComponentImpl.lambda$start$2(ComponentImpl.java:502)
at org.apache.felix.dm.impl.SerialExecutor.runTask(SerialExecutor.java:138)
at org.apache.felix.dm.impl.SerialExecutor.runTasks(SerialExecutor.java:120)
at org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:86)
at org.apache.felix.dm.impl.SerialExecutor.execute(SerialExecutor.java:105)
at org.apache.felix.dm.impl.ComponentImpl.start(ComponentImpl.java:500)
at 
org.apache.felix.dm.impl.ComponentScheduler.add(ComponentScheduler.java:69)
at org.apache.felix.dm.DependencyManager.add(DependencyManager.java:141)
at my.project.Activator.init(Activator.java:84)
at 
org.apache.felix.dm.DependencyActivatorBase.start(DependencyActivatorBase.java:79)
at 
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:698)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2402)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2308)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
at aQute.launcher.Launcher.startBundles(Launcher.java:528)
at aQute.launcher.Launcher.activate(Launcher.java:427)
at aQute.launcher.Launcher.run(Launcher.java:306)
at aQute.launcher.Launcher.main(Launcher.java:152)
at aQute.launcher.pre.EmbeddedLauncher.main(EmbeddedLauncher.java:65)
Caused by: java.lang.NullPointerException
at sun.util.locale.LocaleUtils.toLowerString(LocaleUtils.java:89)
at sun.util.locale.LanguageTag.parse(LanguageTag.java:191)
at java.util.Locale.forLanguageTag(Locale.java:1568)
at MyBrokenComponent.(UserTransformerV1_2.java:17)
... 28 more
{code}




--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (FELIX-5683) getServiceProperties returns null instead of empty dictionary

2017-08-25 Thread Bram Pouwelse (JIRA)


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

Bram Pouwelse commented on FELIX-5683:
--

There is however another change that I think would be nice.. I thinkit would be 
easier for consumers if the getServiceProperties method never returns null (so 
even if the component was initialized without service properties just return a 
new dictionary). 

> getServiceProperties returns null instead of empty dictionary
> -
>
> Key: FELIX-5683
> URL: https://issues.apache.org/jira/browse/FELIX-5683
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r9
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
>
> There are two issues:
> 1)
> In the felix users mailing list (see [1]), Bram reported the following:
> when you set a component service properties like this:
> {code}
> Component component = 
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
>  Properties());
> component.getServiceProperties().put("a", "b");
> {code}
> then you get a NPE because the component.getServiceProperties() method 
> returns null instead of the empty dictionary that has been set in the 
> setInterfaceMethod.
> This is a regression made in r9 release, in the FELIX-5522 where a 
> refactoring was done regarding aspect service properties.
> A fix can be made in order to behave like before (that is : avoid the NPE). 
> 2)
> Bram, I may be wrong but I think that one new issue is that the dictionary 
> returned by the getServiceProperties() method was so far (since the initial 
> version of felix dm 2.0.1) a copy of the service properties dictionary 
> maintained in the ComponentImpl, so if you would like to do set service 
> properties like this:
> {code}
> Component component = 
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
>  Properties());
> component.getServiceProperties().put("a", "b");
> m_dependencyManager.add(component);  // won't add "a=b" properties
> {code}
> then the "a" property will be set in the copy of the internal dictionary 
> returned by the getServiceProperties() method, and the "a=b" service 
> properties won't be set when the component is added in the 
> m_dependencyManager.
> So, if what I'm saying is correct and if you would like to see this new 
> behavior implemented, please open a new jira issue and I will manage to 
> implement it; thanks
> PS: I'm now fixing the 1) regression, in order to avoid the NPE.
> [1] http://www.mail-archive.com/users%40felix.apache.org/msg17939.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FELIX-5683) getServiceProperties returns null instead of empty dictionary

2017-08-25 Thread Bram Pouwelse (JIRA)


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

Bram Pouwelse commented on FELIX-5683:
--

[~pderop]  Thanks for the quick response! 

I'll try to do a test with the trunk version later today. 

> Bram, I may be wrong but I think that one new issue is that the dictionary 
> returned by the getServiceProperties() method was so far (since the initial 
> version of felix dm 2.0.1) a copy of the service properties dictionary 
> maintained in the ComponentImpl, so if you would like to do set service 
> properties like this:

I'm not sure that's a real issue I am aware that, furthermore I think that 
changing this behavior would be another breaking change. 

> getServiceProperties returns null instead of empty dictionary
> -
>
> Key: FELIX-5683
> URL: https://issues.apache.org/jira/browse/FELIX-5683
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>Affects Versions: org.apache.felix.dependencymanager-r9
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
>
> There are two issues:
> 1)
> In the felix users mailing list (see [1]), Bram reported the following:
> when you set a component service properties like this:
> {code}
> Component component = 
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
>  Properties());
> component.getServiceProperties().put("a", "b");
> {code}
> then you get a NPE because the component.getServiceProperties() method 
> returns null instead of the empty dictionary that has been set in the 
> setInterfaceMethod.
> This is a regression made in r9 release, in the FELIX-5522 where a 
> refactoring was done regarding aspect service properties.
> A fix can be made in order to behave like before (that is : avoid the NPE). 
> 2)
> Bram, I may be wrong but I think that one new issue is that the dictionary 
> returned by the getServiceProperties() method was so far (since the initial 
> version of felix dm 2.0.1) a copy of the service properties dictionary 
> maintained in the ComponentImpl, so if you would like to do set service 
> properties like this:
> {code}
> Component component = 
> m_dependencyManager.createComponent().setInterface(ApplicationService.class.getName(),new
>  Properties());
> component.getServiceProperties().put("a", "b");
> m_dependencyManager.add(component);  // won't add "a=b" properties
> {code}
> then the "a" property will be set in the copy of the internal dictionary 
> returned by the getServiceProperties() method, and the "a=b" service 
> properties won't be set when the component is added in the 
> m_dependencyManager.
> So, if what I'm saying is correct and if you would like to see this new 
> behavior implemented, please open a new jira issue and I will manage to 
> implement it; thanks
> PS: I'm now fixing the 1) regression, in order to avoid the NPE.
> [1] http://www.mail-archive.com/users%40felix.apache.org/msg17939.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Apache Felix Dependency Manager Release R10

2017-06-26 Thread Bram Pouwelse

-1 (non binding)

Can't rebuild from sources

On Fri, Jun 23, 2017 at 8:51 AM Pierre De Rop 
wrote:

> Hello all,
>
> I would like to call for a vote on the Dependency Manager toplevel release
> R10.
>
>
> The following issues were solved:
>
> ** Bug
> * [FELIX-5630] - NullObject is created for a required dependency
> if the component is removed and added again to the dependency manager
> * [FELIX-5636] - Component of aspect service does not have any
> service properties anymore
>
> ** Improvement
> * [FELIX-5619] - MultiProperyFilterIndex memory consumption
> * [FELIX-5623] - Improve performance of ComponentImpl.getName method
> * [FELIX-5650] - Support latest version of Gogo
> * [FELIX-5653] - Simplify DM-Lambda samples
>
>
> You can use this UNIX script to download the release and verify the
> signatures:
>
>
>
> http://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/check_staged_release.sh
>
> Usage:
>
>
> sh check_staged_release.sh r10 /tmp/felix-staging
>
> This script, unlike the original Felix check_stage_release.sh, is specific
> to the new Dependency Manager release process (see FELIX-4818) and will
> download staging from https://dist.apache.org/repos/dist/dev/felix instead
> of http://repository.apache.org/content/repositories.
>
> To rebuild the DM binaries from the source, you can then refer
> tohttps://svn.apache.org/repos/asf/felix/trunk/dependencymanager/release/
> resources/src/README.src
> 
>
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
>
> Many thanks;
>
> regards;
> /Pierre
>

[jira] [Commented] (FELIX-5533) Fix a semantic versioning issue when releasing dependency manager

2017-02-09 Thread Bram Pouwelse (JIRA)


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

Bram Pouwelse commented on FELIX-5533:
--

Hi Pierre, 

I think 2 is not a solution but it's a way to mask the problem in Eclipse but 
it can sill be useful to add the {{-fixupmessages}}. Changing the baselining 
error to a warning in Eclipse has two advantages: 
 - If a project on which other projects in the workspace depend has a 
baselining error these projects can still be built so you get a lot less red 
crosses and errors.
 - Because the build completes you can use the "Release Workspace Bundles..." 
dialog (available from the Bndtools menu) to analyze the baselining issue (in 
that view the released bundle is compared to the current workspace version).

You can forget to fix the warning in Eclipse but the baselining error will 
still fail the Gradle build so you should notice that soon enough.  

> Fix a semantic versioning issue when releasing dependency manager
> -
>
> Key: FELIX-5533
> URL: https://issues.apache.org/jira/browse/FELIX-5533
> Project: Felix
>  Issue Type: Task
>  Components: Dependency Manager, Dependency Manager Annotations, 
> Dependency Manager Lambda, Dependency Manager Runtime, Dependency Manager 
> Samples, Dependency Manager Shell
>Affects Versions: org.apache.felix.dependencymanager-r1
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
> Fix For: org.apache.felix.dependencymanager-r9
>
>
> When you release the dm binary bundles using "gradle release" or when 
> clicking on" BndTools -> Release Workspace Bundles ..."; then there is an 
> issue with the bndtools semantic versioning: once you do "gradle release", 
> then after once you clean and rebuild everything, the semantic versioning 
> then complains and says that you have to increment the micro version of all 
> released bundles.
> With the help of the Luminis team, it turns out that there are two work 
> arounds that can be done:
> 1) include the sources in released bundles, before doing "gradle release"
> 2) or declare the following in the bnd main configuration:
> {code}
> # Make baselining issues a warning instead of error when using Eclipse
> fixuptype: ${if;${is;${gestalt;batch};batch};error;warning}
> -fixupmessages: \
>   "Baseline ...";is:=${fixuptype},\
>   "The bundle version ...";is:=${fixuptype},\
>   "The baseline version ...";is:=${fixuptype}
> {code}
> The two solutions are working.
> For the moment, since including the sources in the bundles is helpful when 
> debugging under eclipse and bndtools, I'm using the 1st solution: include the 
> sources in binary bundles, using "-sources: true" in the main bnd config.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Implementation of unreleased spec and community

2017-01-18 Thread Bram Pouwelse

> I'm not talking about developing an implementation of a publicly released 
> specification.
I have absolutely no problem with that of course.

How is that different from developing an implementation for a publicly
released DRAFT specification? In both cases you create an implementation
for something that was specced outside of the Apache community.

On Wed, Jan 18, 2017 at 1:43 PM Guillaume Nodet  wrote:

> RFC-217 sorry
>https://github.com/osgi/design/tree/master/rfcs/rfc0217
>
>
>
> 2017-01-18 13:36 GMT+01:00 Guillaume Nodet :
>
> > Fwiw, I think Christian was referring to the JAX-RS WHITEBOARD, not the
> > JAX-RS spec itself.
> > That one is an RFC from the OSGi Alliance...  RFC-127 afaik.
> >
> > 2017-01-18 13:34 GMT+01:00 Neil Bartlett :
> >
> >> Christian, your example of JAX-RS Whiteboard is fascinating, because
> >> JAX-RS was designed by the Expert Groups of the JCP, not by the Apache
> >> community. The same is true of many of the JavaEE specifications
> >> implemented within Apache.
> >>
> >> So, Apache has always worked pragmatically to implement specifications
> >> emerging from external standards bodies. It seems odd therefore to
> single
> >> out OSGi.
> >>
> >> Neil
> >>
> >> > On 18 Jan 2017, at 11:25, Christian Schneider <
> ch...@die-schneider.net>
> >> wrote:
> >> >
> >> > I agree with Guillaume that the way the specs are defined is not fully
> >> compatible to the way apache projects are managed.
> >> > In apache the idea is that the design of a component is defined by the
> >> community.
> >> >
> >> > Like in jax-rs-whiteboard .. if it was a pure apache thing then
> changes
> >> in the interfaces would be proposed on the dev list and agreed on there.
> >> > As the interfaces are part of the spec this is out of direct reach for
> >> the aries community.
> >> >
> >> > On the other hand I understand that the final decision about the spec
> >> has to be at the OSGi alliance and even that only members may decide.
> >> > So I think this gap can not be fully solved but maybe we can improve
> it.
> >> >
> >> > So what I could imagine is this:
> >> >
> >> > - Changes on the spec should be immediately visible to the apache
> >> community. This could be done using a github repo where the source of
> the
> >> spec resides and an automated snapshot build. So all changes could be
> >> followed directly and the newest spec jars  would always be available.
> >> > - Protocols of the expert group meetings could be posted to the dev
> list
> >> >
> >> > Both improvements would shorten the feedback loop and give the apache
> >> community at least more visibility of the spec progress. The community
> >> could then also directly give feedback to the protocols as well as api
> >> changes on the dev list. So this would of course still not allow the
> apache
> >> community to drive the spec but I think it would be a good compromise.
> >> >
> >> > Christian
> >> >
> >> > On 18.01.2017 11:59, David Bosschaert wrote:
> >> >> Hi Guillaume,
> >> >>
> >> >> First of all, the OSGi Alliance is a very open standards development
> >> >> organization. Any organisation can join. RFPs and RFCs are developed
> >> in the
> >> >> open, specs are available for free and are free to be implemented by
> >> anyone.
> >> >>
> >> >> There is also an open feedback channel available where everyone can
> >> post
> >> >> feedback, described at https://github.com/osgi/design
> >> >>
> >> >> OSGi works very hard in defining specs that are portable and can be
> >> >> implemented without the need to pay for any licenses or anything of
> >> that
> >> >> sort.
> >> >>
> >> >> History has shown that spec implementations are really quite
> portable.
> >> >> Implementation bundles can be mixed from different sources and
> >> everything
> >> >> just works as long as you use the specced APIs.
> >> >>
> >> >> Every new spec that is being worked on in OSGi needs, besides the
> >> RFP/RFC
> >> >> and spec chapter, a Reference Implementation and a Conformance
> >> Testsuite.
> >> >> Over the past 10 years or so, Reference Implementations have
> primarily
> >> been
> >> >> implemented in open source. This has the benefit that everyone can
> see
> >> what
> >> >> the implementation is going to be and also it allows everyone to
> >> provide
> >> >> feedback and participate in the implementation. Apache committers
> have
> >> free
> >> >> access to the relevant CTs as well.
> >> >>
> >> >> I think this is all goodness. Or would you rather see that Reference
> >> >> Implementations are implemented in private?
> >> >>
> >> >> Best regards,
> >> >>
> >> >> David
> >> >>
> >> >>
> >> >> On 18 January 2017 at 10:41, Guillaume Nodet 
> >> wrote:
> >> >>
> >> >>> I'm a bit concerned by some subprojects in our communities.
> >> >>>
> >> >>> The ASF is supposed to be "community over code", so the very basic
> >> thing
> >> >>> for a project is that people can get involved.
> >> >>>
> >> >>> However, I see more and more code developped as a reference
> >> im

Re: Proposal for slight amendment to Felix provisional OSGi API policy

2016-12-23 Thread Bram Pouwelse

I Like the simple version ( org.osgi.someapi; version="0.1";
mandatory:="provisional"; provisional="felix" ), and then I think it makes
sense to advise a bit more conservative import range like
 Import-Package: org.osgi.someapi;version="[0.1,0.2)";provisional=felix

And that also implies that the version needs to be updated when a newer
version is included in a next version.


On Fri, Dec 23, 2016 at 1:41 PM Neil Bartlett  wrote:

> This suggestion from David sounds like a reasonable compromise to me.
>
> I would point out that if you are building with bnd and you put a bundle
> with a mandatory attribute on your build path, then bnd will assume that
> you want to set that attribute on your import. Thus it will work fairly
> transparently. And of course if you DON’T want provisional APIs, don’t put
> provisional bundles on your build path. As the developer this is something
> that you will have full control over.
>
> Neil
>
> > On 23 Dec 2016, at 12:36, David Bosschaert 
> wrote:
> >
> > Hi all,
> >
> > On 23 December 2016 at 12:13, Jan Willem Janssen <
> > janwillem.jans...@luminis.eu <mailto:janwillem.jans...@luminis.eu>>
> wrote:
> >
> >>
> >>> On 23 Dec 2016, at 12:30, David Bosschaert  >
> >> wrote:
> >>>
> >>> Hi Bram,
> >>>
> >>> On 23 December 2016 at 11:02, Bram Pouwelse  wrote:
> >>>
> >>>>> I think it would be nice if we could relax the policy at [1] a little
> >> bit
> >>>> and say that it is ok to release bundles with provisional API in
> >> versions <
> >>>> 1.0. The OSGi APIs always start their versions at 1.0 so an API
> version
> >> 0.2
> >>>> will never conflict with an OSGi released API.
> >>>>
> >>>> That sounds nice but you can't have major changes in the provisional
> API
> >>>> (or you'd loose semantic versioning).
> >>>>
> >>>>
> >>> There is a somewhat unwritten convention that API < 1.0 is
> 'experimental'
> >>> and therefore that exported API in versions [0.0, 1.0) does not follow
> >>> semantic versioning... Basically what you're signing up to by using
> this
> >>> 'provisional' API which has a version < 1.0 is that anything could
> >> change…
> >>
> >> Why not go for the empty version of 0.0.0 for such APIs then? I
> understand
> >> that there’s a need to express the fact that an API is still actively
> being
> >> developed and not yet final, but using versions in the range of [0,1)
> would
> >> make stuff just more complex given that they loose all semantics and are
> >> only “informational” for humans to parse and comprehend.
> >>
> >>
> > Whether we stick with 0.0.0 or allow different versions between [0.0.0,
> > 1.0) this would still suffer from Bram's point that if multiple projects
> do
> > releases that contain provisional API you don't know which one you'll get
> > from the resolver.
> >
> > This could be fixed by using mandatory attributes on the exported
> package.
> > It is a somewhat rarely used feature of OSGi. Currently the document at
> [1]
> > says to use the following decoration on the exported package:
> >  Export-Package: org.osgi.someapi; version="0.1"; mandatory:="status";
> > status="provisional"
> >
> > This means that importers can only import this package if they expressly
> > add this to the import:
> >  Import-Package: ,org.osgi.someapi;version="[0.0,1)";status="provisional"
> >
> > We could specialize this a little bit to indicate what project the
> version
> > is from
> >  org.osgi.someapi; version="0.1"; mandatory:="status,implemetation";
> > status="provisional"; implementation="felix"
> > or maybe simply:
> >  org.osgi.someapi; version="0.1"; mandatory:="provisional"; provisional
> > ="felix"
> >
> > Then the import would become:
> >  Import-Package: ,org.osgi.someapi;version="[0.0,1)";provisional=felix
> > which means that the import will only resolve to the 'felix' variant of
> the
> > provisional API. So from a resolution point of view the ambiguity is gone
> > then.
> >
> > Needless to say that these mandatory attributes will be removed once the
> > OSGi API is released and at 1.0
> >
> > Cheers,
> >
> > David
> >
> > [1]
> >
> http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
> <
> http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
> >
>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

2016-12-23 Thread Bram Pouwelse

In that case I don't like the idea of released bundles using API versions <
1. What if some other bundle is providing that same package there would be
no way for te resolver to know that those packages are actually not
compatible.

On Fri, Dec 23, 2016 at 12:30 PM David Bosschaert <
david.bosscha...@gmail.com> wrote:

> Hi Bram,
>
> On 23 December 2016 at 11:02, Bram Pouwelse  wrote:
>
> > > I think it would be nice if we could relax the policy at [1] a little
> bit
> > and say that it is ok to release bundles with provisional API in
> versions <
> > 1.0. The OSGi APIs always start their versions at 1.0 so an API version
> 0.2
> > will never conflict with an OSGi released API.
> >
> > That sounds nice but you can't have major changes in the provisional API
> > (or you'd loose semantic versioning).
> >
> >
> There is a somewhat unwritten convention that API < 1.0 is 'experimental'
> and therefore that exported API in versions [0.0, 1.0) does not follow
> semantic versioning... Basically what you're signing up to by using this
> 'provisional' API which has a version < 1.0 is that anything could
> change...
>
> Cheers,
>
> David
>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

2016-12-23 Thread Bram Pouwelse

> I think it would be nice if we could relax the policy at [1] a little bit
and say that it is ok to release bundles with provisional API in versions <
1.0. The OSGi APIs always start their versions at 1.0 so an API version 0.2
will never conflict with an OSGi released API.

That sounds nice but you can't have major changes in the provisional API
(or you'd loose semantic versioning).

Also not sure how big the imports issue is, if the api is fully compatible
that would be a find /replace?

Regards,
Bram

On Fri, Dec 23, 2016 at 11:30 AM David Bosschaert <
david.bosscha...@gmail.com> wrote:

Hi all,

The Felix project has a policy to prevent any releases that contain
provisional, unreleased OSGi APIs [1].

Developing OSGi APIs generally takes a substantial amount of time. In OSGi
RFPs and RFCs are written. Reference Implementations are developed, often
in Open Source such as here at Felix. Conformance Testsuites are written
and the actual spec is written. Then the whole package is voted on a number
of times by the OSGi membership before the spec is published.

Especially when creating a new spec having the implementation used as
widely as possible is very useful for gathering feedback. OTOH the policy
at [1] stands a bit in the way of wider adoption. It requires everyone to
build their own bundles before they can use it or they have to depend on
published snapshots which can really be unstable. If people want to release
an early implementation the policy at [1] requires the OSGi packages to be
renamed, which essentially makes them unusable by early adopters since they
have to change all their imports in their Java source files to pick up the
renamed package name.

I think it would be nice if we could relax the policy at [1] a little bit
and say that it is ok to release bundles with provisional API in versions <
1.0. The OSGi APIs always start their versions at 1.0 so an API version 0.2
will never conflict with an OSGi released API. We should also add the
@Deprecated annotations and the mandatory 'provisional' attribute, but I
think in this case, where the exported API has a version of < 1.0 it could
be ok to not require the package rename.
This will allow users to use the API in their code based on stable Felix
artifacts, and as the API package does not change once at 1.0 they will not
have to change their source code to migrate from the
org.apache.felix.someapi to org.osgi.someapi. They will need to make
changes to the metadata for the import to work with the released 1.0
version but this is usually somewhere central in a build file...

Disclosure: I would like to release the Felix Converter [2] like this and
have already added the @Deprecate and 'provisional' mandatory attribute...

Thoughts anyone?

Best regards,

David

[1]
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
[2] https://svn.apache.org/repos/asf/felix/trunk/converter/converter

[jira] [Created] (FELIX-5449) gogo jline shell completely dies on unexpected tab character

2016-12-15 Thread Bram Pouwelse (JIRA)

Bram Pouwelse created FELIX-5449:


 Summary: gogo jline shell completely dies on unexpected tab 
character
 Key: FELIX-5449
 URL: https://issues.apache.org/jira/browse/FELIX-5449
 Project: Felix
  Issue Type: Bug
  Components: Gogo JLine
Reporter: Bram Pouwelse


Had a quick look at the new org.apache.felix.gogo.jline 1.0.2 that is to be 
released in an Eclipse project. When a non exising comand is followed by a tab 
character the console completely dies with the stacktrace below. 

To reproduce just type {{l}} {{\[tab\]}} and hit return


{code}
g! l
gogoArithmeticException: / by zero
java.lang.ArithmeticException: / by zero
at org.jline.reader.impl.LineReaderImpl.toColumns(LineReaderImpl.java:4293)
at org.jline.reader.impl.LineReaderImpl.toColumns(LineReaderImpl.java:4268)
at 
org.jline.reader.impl.LineReaderImpl.computePost(LineReaderImpl.java:4232)
at org.jline.reader.impl.LineReaderImpl.doList(LineReaderImpl.java:4082)
at org.jline.reader.impl.LineReaderImpl.doComplete(LineReaderImpl.java:3768)
at 
org.jline.reader.impl.LineReaderImpl.expandOrComplete(LineReaderImpl.java:3516)
at org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:533)
at org.apache.felix.gogo.jline.Shell.runShell(Shell.java:407)
at org.apache.felix.gogo.jline.Shell.gosh(Shell.java:329)
at 
org.apache.felix.gogo.jline.Activator.lambda$startShell$0(Activator.java:137)
at java.lang.Thread.run(Thread.java:745)

{code}



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

Re: [VOTE] Release Apache Felix SCR 2.0.4

2016-07-18 Thread Bram Pouwelse

Hi,

I just downloaded this version but the website still links to 2.0.2 (
http://ftp.nluug.nl/internet/apache//felix/org.apache.felix.scr-2.0.2.jar)
that version is not available there anymore but changing the link version
in the link to 2.0.4 works.

Regards,
Bram

On Fri, Jul 8, 2016 at 10:03 AM Carsten Ziegeler 
wrote:

> The vote passes with four binding +1 votes and three non binding +1 votes
>
> Thanks everyone
>
>  Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Created] (FELIX-5274) remove callback fails after manually removing dynamic dependencies

2016-06-01 Thread Bram Pouwelse (JIRA)

Bram Pouwelse created FELIX-5274:


 Summary: remove callback fails after manually removing dynamic 
dependencies
 Key: FELIX-5274
 URL: https://issues.apache.org/jira/browse/FELIX-5274
 Project: Felix
  Issue Type: Bug
  Components: Dependency Manager
Affects Versions: org.apache.felix.dependencymanager-r8
Reporter: Bram Pouwelse


When dynamic instance bound dependencies are removed in the component destroy 
dm fails to call the remove callback. 

I use an adapter service like 
{code}
manager.add(createAdapterService(ApplicationService.class, null, "onAdd", 
"onChange", "onRemove")
  .setInterface(Servlet.class.getName(), null)
  .setImplementation(WinkServlet.class)
  .setCallbacks("dmInit", "dmStart", "dmStop", "dmDestroy")
  );
{code}

In the WinkServlet init callback an additional dependency is added and this is 
removed in the destroy callback. When the component is removed I get log 
messages like

{code}
ERROR org.amdatu.web.rest.wink - [main] "onRemove" callback not found on 
component instances []
{code}

[http://www.mail-archive.com/users%40felix.apache.org/msg17300.html]



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

[jira] [Updated] (FELIX-5236) Single @Property annotation on a type doesn't work

2016-04-15 Thread Bram Pouwelse (JIRA)


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

Bram Pouwelse updated FELIX-5236:
-
Summary: Single @Property annotation on a type doesn't work  (was: Single 
@Property annotations on a type doesn't work)

> Single @Property annotation on a type doesn't work
> --
>
> Key: FELIX-5236
> URL: https://issues.apache.org/jira/browse/FELIX-5236
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager Annotations
>Affects Versions: org.apache.felix.dependencymanager-r8
>Reporter: Bram Pouwelse
>
> FELIX-5180 introduced the option to add @Property annotations on a type, this 
> doesn't work in case there is only a single property. 
>  The {{AnnotationCollector}} gets the @Property annotations by reading the 
> value of the @RepatableProperty annotation. This @RepeatableProperty is only 
> available when there is more than one @Property annotation. 
> {quote}
>  If more than one annotation of the requested type is present, you can obtain 
> them by first getting their container annotation. 
> {quote}
> https://docs.oracle.com/javase/tutorial/java/annotations/repeating.html



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

[jira] [Created] (FELIX-5236) Single @Property annotations on a type doesn't work

2016-04-15 Thread Bram Pouwelse (JIRA)

Bram Pouwelse created FELIX-5236:


 Summary: Single @Property annotations on a type doesn't work
 Key: FELIX-5236
 URL: https://issues.apache.org/jira/browse/FELIX-5236
 Project: Felix
  Issue Type: Bug
  Components: Dependency Manager Annotations
Affects Versions: org.apache.felix.dependencymanager-r8
Reporter: Bram Pouwelse


FELIX-5180 introduced the option to add @Property annotations on a type, this 
doesn't work in case there is only a single property. 

 The {{AnnotationCollector}} gets the @Property annotations by reading the 
value of the @RepatableProperty annotation. This @RepeatableProperty is only 
available when there is more than one @Property annotation. 

{quote}
 If more than one annotation of the requested type is present, you can obtain 
them by first getting their container annotation. 
{quote}
https://docs.oracle.com/javase/tutorial/java/annotations/repeating.html



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

[jira] [Closed] (FELIX-5214) HttpWhiteboard servlet / filter init param prefix ignored

2016-03-13 Thread Bram Pouwelse (JIRA)


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

Bram Pouwelse closed FELIX-5214.

Resolution: Invalid

Sorry misinterpreted that one ... you're right.

> HttpWhiteboard servlet / filter init param prefix ignored
> -
>
> Key: FELIX-5214
> URL: https://issues.apache.org/jira/browse/FELIX-5214
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http.jetty-3.1.6
>Reporter: Bram Pouwelse
>
> The Http Whiteboard spec (OSGi cmpn 140) defines service properties to 
> configure the prefix for Servlet / Filter init params. These are ignored by 
> the Felix Http service and the default is always used. 
> For Filters it should be possible to specify the prefix using : 
> HTTP_WHITEBOARD_FILTER_INIT_PARAM_PREFIX (OSGi cmpn 140.16.2.13)
> For Servlets it should be possible to specify the prefix using : 
> HTTP_WHITEBOARD_SERVLET_INIT_PARAM_PREFIX (OSGi cmpn 140.16.2.23)



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

[jira] [Created] (FELIX-5214) HttpWhiteboard servlet / filter init param prefix ignored

2016-03-13 Thread Bram Pouwelse (JIRA)

Bram Pouwelse created FELIX-5214:


 Summary: HttpWhiteboard servlet / filter init param prefix ignored
 Key: FELIX-5214
 URL: https://issues.apache.org/jira/browse/FELIX-5214
 Project: Felix
  Issue Type: Bug
  Components: HTTP Service
Affects Versions: http.jetty-3.1.6
Reporter: Bram Pouwelse


The Http Whiteboard spec (OSGi cmpn 140) defines service properties to 
configure the prefix for Servlet / Filter init params. These are ignored by the 
Felix Http service and the default is always used. 

For Filters it should be possible to specify the prefix using : 
HTTP_WHITEBOARD_FILTER_INIT_PARAM_PREFIX (OSGi cmpn 140.16.2.13)

For Servlets it should be possible to specify the prefix using : 
HTTP_WHITEBOARD_SERVLET_INIT_PARAM_PREFIX (OSGi cmpn 140.16.2.23)



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

Re: [CANCEL] [VOTE] Apache Felix Dependency Manager Release R7

2016-03-01 Thread Bram Pouwelse

Hi Pierre,

The license-gradle-plugin [1] might be a useful gradle plugin to help
prevent this in the future, we use it in the Amdatu builds (must admit that
sometimes it's annoying as it fails the build when you forgot to add a
license header ;) )

Regards,
Bram

1: https://github.com/hierynomus/license-gradle-plugin

On Tue, Mar 1, 2016 at 11:02 AM Pierre De Rop 
wrote:

> I'm canceling the vote for the DM r7 release because I forgot to include
> the license files in the new org.apache.felix.dependencymanager.lambda
> bundle.
>
> I will restart a vote with a new r8 version.
>
> regards;
> /Pierre
>

[jira] [Created] (FELIX-5190) Use OSGi R6 Http Whiteboard instead of custom http listener

2016-02-18 Thread Bram Pouwelse (JIRA)

Bram Pouwelse created FELIX-5190:


 Summary: Use OSGi R6 Http Whiteboard instead of custom http 
listener
 Key: FELIX-5190
 URL: https://issues.apache.org/jira/browse/FELIX-5190
 Project: Felix
  Issue Type: Task
Reporter: Bram Pouwelse






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

[jira] [Closed] (FELIX-5190) Use OSGi R6 Http Whiteboard instead of custom http listener

2016-02-18 Thread Bram Pouwelse (JIRA)


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

Bram Pouwelse closed FELIX-5190.

Resolution: Fixed

Oops this was an Apache ACE task. closing this one.

> Use OSGi R6 Http Whiteboard instead of custom http listener
> ---
>
> Key: FELIX-5190
> URL: https://issues.apache.org/jira/browse/FELIX-5190
> Project: Felix
>  Issue Type: Task
>    Reporter: Bram Pouwelse
>




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

[jira] [Created] (FELIX-5103) ArrayIndexOutOfBoundsException during bundle update

2015-11-16 Thread Bram Pouwelse (JIRA)

Bram Pouwelse created FELIX-5103:


 Summary: ArrayIndexOutOfBoundsException during bundle update
 Key: FELIX-5103
 URL: https://issues.apache.org/jira/browse/FELIX-5103
 Project: Felix
  Issue Type: Bug
  Components: Framework
Affects Versions: framework-5.2.0, framework-4.2.1
Reporter: Bram Pouwelse


I have traces like the one below quite often when bndtools is updating bundles 
in a running framework.  

{code}
! Error in updating the framework from the properties: Index: 0, Size: 0
! Bundle files does not exist: 
/Users/brampouwelse/git-repos/path/to/project/generated/mybundle.jar
ERROR: Bundle mybundle [251] Unable to update the bundle. 
(java.lang.IndexOutOfBoundsException: Index: 0, Size: 0)
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at org.apache.felix.framework.BundleImpl.adapt(BundleImpl.java:1064)
at 
org.apache.felix.framework.BundleImpl.getSymbolicName(BundleImpl.java:896)
at 
org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1226)
at org.apache.felix.framework.BundleImpl.revise(BundleImpl.java:1141)
at org.apache.felix.framework.Felix.updateBundle(Felix.java:2282)
at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:973)
at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:960)
at aQute.launcher.Launcher.synchronizeFiles(Launcher.java:534)
at aQute.launcher.Launcher.update(Launcher.java:405)
at aQute.launcher.Launcher$1.run(Launcher.java:194)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
! Failed to update bundle 
/Users/brampouwelse/git-repos/path/to/project/generated/mybundle.jar, exception 
Update of bundle mybundle [251] failed.
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at org.apache.felix.framework.BundleImpl.adapt(BundleImpl.java:1064)
ERROR: Bundle myotherbundle [252] Unable to update the bundle. 
(java.lang.IndexOutOfBoundsException: Index: 0, Size: 0)
at 
org.apache.felix.framework.BundleImpl.getSymbolicName(BundleImpl.java:896)
at 
org.apache.felix.framework.BundleImpl.createRevision(BundleImpl.java:1226)
at org.apache.felix.framework.BundleImpl.revise(BundleImpl.java:1141)
at org.apache.felix.framework.Felix.updateBundle(Felix.java:2282)
at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:973)
at org.apache.felix.framework.BundleImpl.update(BundleImpl.java:960)
at aQute.launcher.Launcher.synchronizeFiles(Launcher.java:534)
at aQute.launcher.Launcher.update(Launcher.java:405)
at aQute.launcher.Launcher$1.run(Launcher.java:194)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
! Failed to update bundle 
/Users/brampouwelse/git-repos/path/to/project/generated/myotherbundle.jar, 
exception Update of bundle myotherbundle [252] failed.
{code}

Just had a look at the Felix code and this part is interesting. 

{code:title=BundleImpl.java}
synchronized void revise(String location, InputStream is)
throws Exception
{
// This operation will increase the revision count for the bundle.
m_archive.revise(location, is);
try
{
BundleRevision revision = createRevision(true);
addRevision(revision);
}
catch (Exception ex)
{
m_archive.rollbackRevise();
throw ex;
}
}
{code}

If the {{createRevision}} call throws an exception 
{{m_archive.rollbackRevise()}} is called this is removing revision at index 0 
but the new revision was never added so it's removing the current revision 
instead of the new revision.  



Link to the bndtools issue: https://github.com/bndtools/bndtools/issues/1217



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

[jira] [Commented] (FELIX-4869) Callbacks not invoked for dependencies that are added after the component is initialized

2015-04-28 Thread Bram Pouwelse (JIRA)


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

Bram Pouwelse commented on FELIX-4869:
--

Just tested the version from trunk and I can confirm that your fix works.

Thanks again for the quick response and fix!

> Callbacks not invoked for dependencies that are added after the component is 
> initialized
> 
>
> Key: FELIX-4869
> URL: https://issues.apache.org/jira/browse/FELIX-4869
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>    Reporter: Bram Pouwelse
>Assignee: Pierre De Rop
>
> When adding a ServiceDependency after the component is initialized the 
> dependency manager doesn't invoke callbacks for services already registered 
> before the dependency was added.
> I'm using the 4.0.1 version of the dependency manager.
> I've created a small example to demonstrate the issue. 
> {code:title=TestComponent.java}
> ...
> public class TestComponent {
>   private volatile DependencyManager dm; 
>   private volatile Component c; 
>   
>   public void addDependency(){
> 
> c.add(dm.createServiceDependency().setService(Object.class).setCallbacks("add",
>  "remove"));
>   }
>   
>   public void add(ServiceReference ref) {
>System.out.println("added " + ref)
>   }
>   
>   public void remove(ServiceReference ref) {
> System.out.println("removed " + ref)
>   }
> } 
> {code}
> When the dependency is added *after* the services are registered the add 
> callback is never invoked. 
> {code:title=Activator.java}
> ...
> @Override
> public void init(BundleContext ctx, DependencyManager dm) throws Exception {
>   TestComponent testComponent = new TestComponent();
>   dm.add(createComponent().setImplementation(testComponent));
>  
>   ctx.registerService(Object.class, new Object(), null);
>   ctx.registerService(Object.class, new Object(), null);
>   testComponent.addDependency();  
> }
> ...
> {code}
> When the dependency is added *before* the services are registered the add 
> callback are invoked. 
> {code:title=Activator.java}
> ...
> @Override
> public void init(BundleContext ctx, DependencyManager dm) throws Exception {
>   TestComponent testComponent = new TestComponent();
>   dm.add(createComponent().setImplementation(testComponent));
>   
>   testComponent.addDependency();  
>  
>   ctx.registerService(Object.class, new Object(), null);
>   ctx.registerService(Object.class, new Object(), null);
> }
> ...
> {code}
> I've noticed something similar when adding multiple service dependencies in 
> the init method. When adding the dependencies in one call to 
> Component#add(Dependency...) everything seems to work as expected but when 
> calling the add method one component at a time callbacks not invoked for the 
> second service dependency. 



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

[jira] [Commented] (FELIX-4869) Callbacks not invoked for dependencies that are added after the component is initialized

2015-04-28 Thread Bram Pouwelse (JIRA)


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

Bram Pouwelse commented on FELIX-4869:
--

Good to hear you've found the issue, and even better that you'll have a patch 
today :) 

Are there snapshots available that I can use so I can give it a try? a release 
next week is ok for me :)  

> Callbacks not invoked for dependencies that are added after the component is 
> initialized
> 
>
> Key: FELIX-4869
> URL: https://issues.apache.org/jira/browse/FELIX-4869
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>Reporter: Bram Pouwelse
>Assignee: Pierre De Rop
>
> When adding a ServiceDependency after the component is initialized the 
> dependency manager doesn't invoke callbacks for services already registered 
> before the dependency was added.
> I'm using the 4.0.1 version of the dependency manager.
> I've created a small example to demonstrate the issue. 
> {code:title=TestComponent.java}
> ...
> public class TestComponent {
>   private volatile DependencyManager dm; 
>   private volatile Component c; 
>   
>   public void addDependency(){
> 
> c.add(dm.createServiceDependency().setService(Object.class).setCallbacks("add",
>  "remove"));
>   }
>   
>   public void add(ServiceReference ref) {
>System.out.println("added " + ref)
>   }
>   
>   public void remove(ServiceReference ref) {
> System.out.println("removed " + ref)
>   }
> } 
> {code}
> When the dependency is added *after* the services are registered the add 
> callback is never invoked. 
> {code:title=Activator.java}
> ...
> @Override
> public void init(BundleContext ctx, DependencyManager dm) throws Exception {
>   TestComponent testComponent = new TestComponent();
>   dm.add(createComponent().setImplementation(testComponent));
>  
>   ctx.registerService(Object.class, new Object(), null);
>   ctx.registerService(Object.class, new Object(), null);
>   testComponent.addDependency();  
> }
> ...
> {code}
> When the dependency is added *before* the services are registered the add 
> callback are invoked. 
> {code:title=Activator.java}
> ...
> @Override
> public void init(BundleContext ctx, DependencyManager dm) throws Exception {
>   TestComponent testComponent = new TestComponent();
>   dm.add(createComponent().setImplementation(testComponent));
>   
>   testComponent.addDependency();  
>  
>   ctx.registerService(Object.class, new Object(), null);
>   ctx.registerService(Object.class, new Object(), null);
> }
> ...
> {code}
> I've noticed something similar when adding multiple service dependencies in 
> the init method. When adding the dependencies in one call to 
> Component#add(Dependency...) everything seems to work as expected but when 
> calling the add method one component at a time callbacks not invoked for the 
> second service dependency. 



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

[jira] [Commented] (FELIX-4869) Callbacks not invoked for dependencies that are added after the component is initialized

2015-04-28 Thread Bram Pouwelse (JIRA)


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

Bram Pouwelse commented on FELIX-4869:
--

Hello Pierre, 

Thanks for the quick reply, I did check the log service for errors but nothing 
(at least not with the log level error ) 

> Callbacks not invoked for dependencies that are added after the component is 
> initialized
> 
>
> Key: FELIX-4869
> URL: https://issues.apache.org/jira/browse/FELIX-4869
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>    Reporter: Bram Pouwelse
>Assignee: Pierre De Rop
>
> When adding a ServiceDependency after the component is initialized the 
> dependency manager doesn't invoke callbacks for services already registered 
> before the dependency was added.
> I'm using the 4.0.1 version of the dependency manager.
> I've created a small example to demonstrate the issue. 
> {code:title=TestComponent.java}
> ...
> public class TestComponent {
>   private volatile DependencyManager dm; 
>   private volatile Component c; 
>   
>   public void addDependency(){
> 
> c.add(dm.createServiceDependency().setService(Object.class).setCallbacks("add",
>  "remove"));
>   }
>   
>   public void add(ServiceReference ref) {
>System.out.println("added " + ref)
>   }
>   
>   public void remove(ServiceReference ref) {
> System.out.println("removed " + ref)
>   }
> } 
> {code}
> When the dependency is added *after* the services are registered the add 
> callback is never invoked. 
> {code:title=Activator.java}
> ...
> @Override
> public void init(BundleContext ctx, DependencyManager dm) throws Exception {
>   TestComponent testComponent = new TestComponent();
>   dm.add(createComponent().setImplementation(testComponent));
>  
>   ctx.registerService(Object.class, new Object(), null);
>   ctx.registerService(Object.class, new Object(), null);
>   testComponent.addDependency();  
> }
> ...
> {code}
> When the dependency is added *before* the services are registered the add 
> callback are invoked. 
> {code:title=Activator.java}
> ...
> @Override
> public void init(BundleContext ctx, DependencyManager dm) throws Exception {
>   TestComponent testComponent = new TestComponent();
>   dm.add(createComponent().setImplementation(testComponent));
>   
>   testComponent.addDependency();  
>  
>   ctx.registerService(Object.class, new Object(), null);
>   ctx.registerService(Object.class, new Object(), null);
> }
> ...
> {code}
> I've noticed something similar when adding multiple service dependencies in 
> the init method. When adding the dependencies in one call to 
> Component#add(Dependency...) everything seems to work as expected but when 
> calling the add method one component at a time callbacks not invoked for the 
> second service dependency. 



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

[jira] [Created] (FELIX-4869) Callbacks not invoked for dependencies that are added after the component is initialized

2015-04-27 Thread Bram Pouwelse (JIRA)

Bram Pouwelse created FELIX-4869:


 Summary: Callbacks not invoked for dependencies that are added 
after the component is initialized
 Key: FELIX-4869
 URL: https://issues.apache.org/jira/browse/FELIX-4869
 Project: Felix
  Issue Type: Bug
  Components: Dependency Manager
Reporter: Bram Pouwelse


When adding a ServiceDependency after the component is initialized the 
dependency manager doesn't invoke callbacks for services already registered 
before the dependency was added.

I'm using the 4.0.1 version of the dependency manager.

I've created a small example to demonstrate the issue. 
{code:title=TestComponent.java}
...
public class TestComponent {
  private volatile DependencyManager dm; 
  private volatile Component c; 
  
  public void addDependency(){

c.add(dm.createServiceDependency().setService(Object.class).setCallbacks("add", 
"remove"));
  }
  
  public void add(ServiceReference ref) {
   System.out.println("added " + ref)
  }
  
  public void remove(ServiceReference ref) {
System.out.println("removed " + ref)
  }
} 
{code}

When the dependency is added *after* the services are registered the add 
callback is never invoked. 
{code:title=Activator.java}
...
@Override
public void init(BundleContext ctx, DependencyManager dm) throws Exception {
TestComponent testComponent = new TestComponent();
dm.add(createComponent().setImplementation(testComponent));
 
ctx.registerService(Object.class, new Object(), null);
ctx.registerService(Object.class, new Object(), null);

testComponent.addDependency();  
}
...
{code}

When the dependency is added *before* the services are registered the add 
callback are invoked. 
{code:title=Activator.java}
...
@Override
public void init(BundleContext ctx, DependencyManager dm) throws Exception {
TestComponent testComponent = new TestComponent();
dm.add(createComponent().setImplementation(testComponent));

testComponent.addDependency();  
 
ctx.registerService(Object.class, new Object(), null);
ctx.registerService(Object.class, new Object(), null);
}
...
{code}

I've noticed something similar when adding multiple service dependencies in the 
init method. When adding the dependencies in one call to 
Component#add(Dependency...) everything seems to work as expected but when 
calling the add method one component at a time callbacks not invoked for the 
second service dependency. 




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

[jira] [Commented] (FELIX-6180) Component initialization error message get's printed to sysout instead of logged to LogService

[jira] [Updated] (FELIX-6180) Component initialization error message get's printed to sysout instead of logged to LogService

[jira] [Updated] (FELIX-6180) Component initialization error message get's printed to sysout instead of logged to LogService

[jira] [Created] (FELIX-6180) Component initialization error message get's printed to sysout instead of logged to LogService

[jira] [Commented] (FELIX-5683) getServiceProperties returns null instead of empty dictionary

[jira] [Commented] (FELIX-5683) getServiceProperties returns null instead of empty dictionary

Re: [VOTE] Apache Felix Dependency Manager Release R10

[jira] [Commented] (FELIX-5533) Fix a semantic versioning issue when releasing dependency manager

Re: Implementation of unreleased spec and community

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Re: Proposal for slight amendment to Felix provisional OSGi API policy

[jira] [Created] (FELIX-5449) gogo jline shell completely dies on unexpected tab character

Re: [VOTE] Release Apache Felix SCR 2.0.4

[jira] [Created] (FELIX-5274) remove callback fails after manually removing dynamic dependencies

[jira] [Updated] (FELIX-5236) Single @Property annotation on a type doesn't work

[jira] [Created] (FELIX-5236) Single @Property annotations on a type doesn't work

[jira] [Closed] (FELIX-5214) HttpWhiteboard servlet / filter init param prefix ignored

[jira] [Created] (FELIX-5214) HttpWhiteboard servlet / filter init param prefix ignored

Re: [CANCEL] [VOTE] Apache Felix Dependency Manager Release R7

[jira] [Created] (FELIX-5190) Use OSGi R6 Http Whiteboard instead of custom http listener

[jira] [Closed] (FELIX-5190) Use OSGi R6 Http Whiteboard instead of custom http listener

[jira] [Created] (FELIX-5103) ArrayIndexOutOfBoundsException during bundle update

[jira] [Commented] (FELIX-4869) Callbacks not invoked for dependencies that are added after the component is initialized

[jira] [Commented] (FELIX-4869) Callbacks not invoked for dependencies that are added after the component is initialized

[jira] [Commented] (FELIX-4869) Callbacks not invoked for dependencies that are added after the component is initialized

[jira] [Created] (FELIX-4869) Callbacks not invoked for dependencies that are added after the component is initialized

27 matches

Site Navigation

Mail list logo

Footer information