date:20170220

Re: [utils] support ordering for JSON objects in JSONParser?

2017-02-20 Thread David Leangen


I don’t particularly see a problem with it.

+1 (for keeping, non binding)


Cheers,
=David



> On Feb 21, 2017, at 4:34 PM, Stefan Seifert  wrote:
> 
> i created FELIX-5556 to make sure JSON object order is retained when parsing 
> a JSON file, and reverted the commit after the complaint from felix.
> 
> background:
> - the original JSON spec [1] clearly defined JSON objects "is an unordered 
> collection"
> - the revised JSON spec [2] states the same, but adds an additional paragraph
> 
> "JSON parsing libraries have been observed to differ as to whether or
> not they make the ordering of object members visible to calling
> software.  Implementations whose behavior does not depend on member
> ordering will be interoperable in the sense that they will not be
> affected by these differences."
> 
> do we want to support it in the felix utils JSONParser? seems to set wrong 
> expectations following the spec, but other much used libs as gson and jackson 
> seem to do it by default. so if no one votes to explicitly support it i will 
> cancel FELIX-5556.
> 
> stefan
> 
> [1] https://www.ietf.org/rfc/rfc4627.txt
> [2] https://tools.ietf.org/html/rfc7159

[utils] support ordering for JSON objects in JSONParser?

2017-02-20 Thread Stefan Seifert

i created FELIX-5556 to make sure JSON object order is retained when parsing a 
JSON file, and reverted the commit after the complaint from felix.

background:
- the original JSON spec [1] clearly defined JSON objects "is an unordered 
collection"
- the revised JSON spec [2] states the same, but adds an additional paragraph

"JSON parsing libraries have been observed to differ as to whether or
not they make the ordering of object members visible to calling
software.  Implementations whose behavior does not depend on member
ordering will be interoperable in the sense that they will not be
affected by these differences."

do we want to support it in the felix utils JSONParser? seems to set wrong 
expectations following the spec, but other much used libs as gson and jackson 
seem to do it by default. so if no one votes to explicitly support it i will 
cancel FELIX-5556.

stefan

[1] https://www.ietf.org/rfc/rfc4627.txt
[2] https://tools.ietf.org/html/rfc7159

[jira] [Reopened] (FELIX-5556) JSONParser does not retain object order

2017-02-20 Thread Stefan Seifert (JIRA)


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

Stefan Seifert reopened FELIX-5556:
---

reverted in rev. 1783837 due to objection in mailing list - starting further 
discussion there
https://lists.apache.org/thread.html/9628699bf4bf9cfaa05c1d1752fe9e374a987e72ef3065104768a2dc@%3Cdev.felix.apache.org%3E

> JSONParser does not retain object order
> ---
>
> Key: FELIX-5556
> URL: https://issues.apache.org/jira/browse/FELIX-5556
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Affects Versions: utils-1.9.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: utils-1.9.2
>
>
> the {{JSONParser}} does not retain the order of objects the JSON files it 
> parses. the order is randomly based on the HashMap implementation used 
> internally.



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

[jira] [Created] (FELIX-5557) Updates to section 112.8.2.2 Coercing Component Property Values

2017-02-20 Thread Carsten Ziegeler (JIRA)

Carsten Ziegeler created FELIX-5557:
---

 Summary: Updates to section 112.8.2.2 Coercing Component Property 
Values
 Key: FELIX-5557
 URL: https://issues.apache.org/jira/browse/FELIX-5557
 Project: Felix
  Issue Type: Sub-task
  Components: Declarative Services (SCR)
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
Priority: Minor
 Fix For: scr-2.1.0


Section 112.8.2.2  Coercing Component Property Values has been updated: If 
there is no corresponding component property for a component property type 
method, the component property type method must return an empty array for array 
method types. Previously this used to be "null"



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

Re: [jira] [Resolved] (FELIX-5556) JSONParser does not retain object order

2017-02-20 Thread Felix Meschberger

Hi all

I think this is a very bad idea !

According to RFC 4627 [1]:

> An object is an unordered collection of zero or more name/value
> pairs, where a name is a string and a value is a string, number,
> boolean, null, object, or array.

Parsing the JSON and then storing in a defined order creates expectations which 
are not valid. There is no defined order amongst properties in an object and we 
must not create the impression that there would be and even start having 
applications depending on it.

Therefore I strongly suggest to revert this change and go back to using a 
HashMap.

Regards
Felix

[1] https://www.ietf.org/rfc/rfc4627.txt

> Am 20.02.2017 um 23:08 schrieb Stefan Seifert (JIRA) :
> 
> 
> [ 
> https://issues.apache.org/jira/browse/FELIX-5556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
> 
> Stefan Seifert resolved FELIX-5556.
> ---
>Resolution: Fixed
> 
> Completed: At revision: 1783803  
> 
> 
>> JSONParser does not retain object order
>> ---
>> 
>>Key: FELIX-5556
>>URL: https://issues.apache.org/jira/browse/FELIX-5556
>>Project: Felix
>> Issue Type: Bug
>> Components: Utils
>>   Affects Versions: utils-1.9.0
>>   Reporter: Stefan Seifert
>>   Assignee: Stefan Seifert
>>Fix For: utils-1.9.2
>> 
>> 
>> the {{JSONParser}} does not retain the order of objects the JSON files it 
>> parses. the order is randomly based on the HashMap implementation used 
>> internally.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)

[jira] [Closed] (FELIX-5553) Cannot load native libraries in Windows Server 2016 with the name win32

2017-02-20 Thread Nicolas Roduit (JIRA)


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

Nicolas Roduit closed FELIX-5553.
-

> Cannot load native libraries in Windows Server 2016 with the name win32
> ---
>
> Key: FELIX-5553
> URL: https://issues.apache.org/jira/browse/FELIX-5553
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-5.6.1
>Reporter: Nicolas Roduit
>Assignee: Karl Pauls
> Fix For: framework-5.6.4
>
>
> With a bundle config:
> lib.dll; processor=x86-64; osname=win32
> The dll won't be loaded on Windows Server 2016.
> PR: https://github.com/apache/felix/pull/93



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

[jira] [Closed] (FELIX-4837) Workaround for JNLPClassLoader in ShutdownHook

2017-02-20 Thread Nicolas Roduit (JIRA)


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

Nicolas Roduit closed FELIX-4837.
-

> Workaround for JNLPClassLoader in ShutdownHook 
> ---
>
> Key: FELIX-4837
> URL: https://issues.apache.org/jira/browse/FELIX-4837
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-5.0.1, framework-5.6.1
> Environment: all
>Reporter: Nicolas Roduit
>Assignee: Karl Pauls
> Fix For: framework-5.6.4
>
>
> This a workaround of the issue that I submitted on 
> https://bugs.openjdk.java.net/browse/JDK-8054639
> The Java Web Start classloader doesn't support to have anonymous classes or 
> enum within the shutdown hook.
> The patch below allows to stop all the bundles correctly when calling  
> m_felix.stop() in the shutdown hook. Otherwise the framework throws an 
> exception and do not call the bundle stop. This is a problem when each bundle 
> write its preferences or state during the stop method.
> {code} 
> diff --git a/framework/src/main/java/org/apache/felix/framework/Felix.java 
> b/framework/src/main/java/org/apache/felix/framework/Felix.java
> index c6b305a..e44ccea 100644
> --- a/framework/src/main/java/org/apache/felix/framework/Felix.java
> +++ b/framework/src/main/java/org/apache/felix/framework/Felix.java
> @@ -1023,7 +1023,7 @@
>  {
>  // Spec says stop() on SystemBundle should return immediately and
>  // shutdown framework on another thread.
> -new Thread(new Runnable() {
> +Thread t = new Thread( "FelixShutdown"){
>  public void run()
>  {
>  try
> @@ -1038,7 +1038,8 @@
>  ex);
>  }
>  }
> -}, "FelixShutdown").start();
> +};
> +t.start();
>  }
>  }
> {code}



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

Re: Volunteer for service diagnostics plugin (Scala)?

2017-02-20 Thread Carsten Ziegeler

Arjun Panday wrote
> Hi Carsten,
> 
> I removed the org.json dependency from the servicediagnostics plugin.
> Sorry again for the delay and many thanks to Pierre De Rop for helping me
> with svn and jira; I was quite rusted!
> I guess we need to cut a new release now?
> 
Hi Arjun

great and thanks for the help!

Yes, a new release would be great.

Regards
Carsten

 

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (FELIX-5549) Factory component fails to reactivate after config changes

2017-02-20 Thread David Jencks (JIRA)


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

David Jencks commented on FELIX-5549:
-

I have very little confidence that our words are communicating much. I don't 
see any evidence of anything unusual from any of the output you have quoted, 
but you seem to be saying there is behavior that isn't shown in the quoted 
output but ought to be logged, judging by your code.  I tries building your 
project and got

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.3:compile (default-compile) on 
project blueprint-ds-config-reload: Fatal error compiling: invalid target 
release: 1.8 -> [Help 1]

I've looked at the existing integration tests and think that the situation you 
have set up is the same as that tested in 
org.apache.felix.scr.integration.ComponentFactoryTest 
test_component_factory_optional_configuration_nomodify, which appears to 
validate that the behavior is as I described.  Could you take a look at this 
test and see if it replicates what you are trying to show?

To reiterate, configuration activity should not affect the registered 
ComponentFactory service in any externally visible way, but with no modify 
method all the component instances created by calling newInstance will be 
destroyed.  If you are seeing the ComponentFactory service affected please show 
this unequivocally in some logs.  If you can record ds debug logging that 
should show in detail what is going on.

> Factory component fails to reactivate after config changes
> --
>
> Key: FELIX-5549
> URL: https://issues.apache.org/jira/browse/FELIX-5549
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
> Environment: Karaf 4.0.8
>Reporter: Alex Soto
>
> A factory component fails to reactive after the configuration changes.  
> Initially, the component initializes normally.  After it is in Active state, 
> the configuration referenced by the component _configurationPid_  changes, 
> which causes the component to not activate again.
> A minimal application demonstrating this behavior is available here:
> https://github.com/lexsoto/blueprint-ds-config-reload



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

Re: [utils] support comments in JSONOParser?

2017-02-20 Thread David Leangen


Agree that it would be a very nice feature to have.

HOWEVER, this is how the scope creep starts. The original thought was to have a 
very simple parser.


What about a separate (possibly even configurable) pre-parser instead?


Cheers,
=David


> On Feb 21, 2017, at 7:17 AM, Stefan Seifert  wrote:
> 
> the new json parser added to Felix Utils fails when the JSON files contain 
> comments like /* comment */.
> 
> i known that the JSON format [1] officially does not support comments at all, 
> but most JSON parsers nowadays seem to support them by just skipping comments 
> when parsing a JSON file. should the felix parser support this as well? 
> perhaps configurable via a strict and non-strict mode?
> 
> stefan
> 
> [1] https://tools.ietf.org/html/rfc7159
> 
>

Re: Volunteer for service diagnostics plugin (Scala)?

2017-02-20 Thread Arjun Panday

Hi Carsten,

I removed the org.json dependency from the servicediagnostics plugin.
Sorry again for the delay and many thanks to Pierre De Rop for helping me
with svn and jira; I was quite rusted!
I guess we need to cut a new release now?

Thanks,
Arjun

On Mon, Feb 20, 2017 at 8:55 AM, Carsten Ziegeler 
wrote:

> Hi,
>
> we have only one single module left where we have to replace the usage
> of org.json: the service diagnostics plugin.
> This one is written in Scala. I assume the replacement is not that
> difficult.
> So if there are any volunteers for this, feel free to pick up FELIX-5554.
>
> Thanks
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

[jira] [Resolved] (FELIX-5554) Remove usage of org.json from service diagnostics plugin

2017-02-20 Thread Pierre De Rop (JIRA)


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

Pierre De Rop resolved FELIX-5554.
--
Resolution: Fixed

> Remove usage of org.json from service diagnostics plugin
> 
>
> Key: FELIX-5554
> URL: https://issues.apache.org/jira/browse/FELIX-5554
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Carsten Ziegeler
> Fix For: webconsole-servicediagnostics-plugin 0.1.4
>
>
> The servicediagnostics plugin is using org.json in it's scala code. We need 
> to replace it, probably with the json writer from the utils module



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

[jira] [Commented] (FELIX-5554) Remove usage of org.json from service diagnostics plugin

2017-02-20 Thread Arjun Panday (JIRA)


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

Arjun Panday commented on FELIX-5554:
-

Dependency on org.json removed in Committed revision 1783807 of felix-trunk. 

> Remove usage of org.json from service diagnostics plugin
> 
>
> Key: FELIX-5554
> URL: https://issues.apache.org/jira/browse/FELIX-5554
> Project: Felix
>  Issue Type: Improvement
>  Components: Web Console
>Reporter: Carsten Ziegeler
> Fix For: webconsole-servicediagnostics-plugin 0.1.4
>
>
> The servicediagnostics plugin is using org.json in it's scala code. We need 
> to replace it, probably with the json writer from the utils module



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

[utils] support comments in JSONOParser?

2017-02-20 Thread Stefan Seifert

the new json parser added to Felix Utils fails when the JSON files contain 
comments like /* comment */.

i known that the JSON format [1] officially does not support comments at all, 
but most JSON parsers nowadays seem to support them by just skipping comments 
when parsing a JSON file. should the felix parser support this as well? perhaps 
configurable via a strict and non-strict mode?

stefan

[1] https://tools.ietf.org/html/rfc7159

[jira] [Resolved] (FELIX-5556) JSONParser does not retain object order

2017-02-20 Thread Stefan Seifert (JIRA)


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

Stefan Seifert resolved FELIX-5556.
---
Resolution: Fixed

Completed: At revision: 1783803  


> JSONParser does not retain object order
> ---
>
> Key: FELIX-5556
> URL: https://issues.apache.org/jira/browse/FELIX-5556
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Affects Versions: utils-1.9.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: utils-1.9.2
>
>
> the {{JSONParser}} does not retain the order of objects the JSON files it 
> parses. the order is randomly based on the HashMap implementation used 
> internally.



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

[jira] [Created] (FELIX-5556) JSONParser does not retain object order

2017-02-20 Thread Stefan Seifert (JIRA)

Stefan Seifert created FELIX-5556:
-

 Summary: JSONParser does not retain object order
 Key: FELIX-5556
 URL: https://issues.apache.org/jira/browse/FELIX-5556
 Project: Felix
  Issue Type: Bug
  Components: Utils
Affects Versions: utils-1.9.0
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: utils-1.9.2


the {{JSONParser}} does not retain the order of objects the JSON files it 
parses. the order is randomly based on the HashMap implementation used 
internally.



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

Re: [RESULT] [VOTE] framework 5.6.2, resolver 1.12.0, and related subproject releases

2017-02-20 Thread Karl Pauls

Time to call the vote on the Felix framework 5.6.2, resolver 1.12.0,
and related subproject releases.

* +1 votes from Carsten Ziegeler, Jean-Baptiste Onofre, Clement
Escoffier, Guillaume Nodet, David Bosschaert, and Karl Pauls.

* No other votes.

The vote is successful. I will make the release artifacts available as
soon as possible.

Re: [VOTE] framework 5.6.2, resolver 1.12.0, and related subproject releases

2017-02-20 Thread Karl Pauls

+1

regards,

Karl

On Fri, Feb 17, 2017 at 10:01 AM, David Bosschaert
 wrote:
> +1
>
> David
>
> On 16 February 2017 at 21:38, Karl Pauls  wrote:
>
>> I would like to call a vote on the following subproject releases:
>>
>> resolver 1.12.0
>> framework  5.6.2
>> main 5.6.2
>> main.distribution 5.6.2
>>
>> The main changelogs are in jira and at:
>> https://svn.apache.org/repos/asf/felix/releases/org.apache.
>> felix.framework-5.6.2/doc/changelog.txt
>> https://svn.apache.org/repos/asf/felix/releases/org.apache.
>> felix.resolver-1.12.0/doc/changelog.txt
>>
>> Staging repositories:
>> https://repository.apache.org/content/repositories/orgapachefelix-1169/
>> https://repository.apache.org/content/repositories/orgapachefelix-1170/
>>
>> 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 1169 /tmp/felix-staging
>> sh check_staged_release.sh 1170 /tmp/felix-staging
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>>



-- 
Karl Pauls
karlpa...@gmail.com

[GitHub] felix pull request #93: [FELIX-5553] Add Windows Server 2016 alias for nativ...

2017-02-20 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/93


---
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 #94: [FELIX-4837] Fix issue with JNLPClassLoader in Shutd...

2017-02-20 Thread asfgit

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/94


---
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.
---

[jira] [Resolved] (FELIX-5553) Cannot load native libraries in Windows Server 2016 with the name win32

2017-02-20 Thread Karl Pauls (JIRA)


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

Karl Pauls resolved FELIX-5553.
---
   Resolution: Fixed
Fix Version/s: framework-5.6.4

I committed support for this in r1783787. Please close if it works for you.

> Cannot load native libraries in Windows Server 2016 with the name win32
> ---
>
> Key: FELIX-5553
> URL: https://issues.apache.org/jira/browse/FELIX-5553
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-5.6.1
>Reporter: Nicolas Roduit
>Assignee: Karl Pauls
> Fix For: framework-5.6.4
>
>
> With a bundle config:
> lib.dll; processor=x86-64; osname=win32
> The dll won't be loaded on Windows Server 2016.
> PR: https://github.com/apache/felix/pull/93



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

[jira] [Commented] (FELIX-5553) Cannot load native libraries in Windows Server 2016 with the name win32

2017-02-20 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on FELIX-5553:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/93


> Cannot load native libraries in Windows Server 2016 with the name win32
> ---
>
> Key: FELIX-5553
> URL: https://issues.apache.org/jira/browse/FELIX-5553
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-5.6.1
>Reporter: Nicolas Roduit
>Assignee: Karl Pauls
> Fix For: framework-5.6.4
>
>
> With a bundle config:
> lib.dll; processor=x86-64; osname=win32
> The dll won't be loaded on Windows Server 2016.
> PR: https://github.com/apache/felix/pull/93



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

[jira] [Assigned] (FELIX-5553) Cannot load native libraries in Windows Server 2016 with the name win32

2017-02-20 Thread Karl Pauls (JIRA)


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

Karl Pauls reassigned FELIX-5553:
-

Assignee: Karl Pauls

> Cannot load native libraries in Windows Server 2016 with the name win32
> ---
>
> Key: FELIX-5553
> URL: https://issues.apache.org/jira/browse/FELIX-5553
> Project: Felix
>  Issue Type: Bug
>Affects Versions: framework-5.6.1
>Reporter: Nicolas Roduit
>Assignee: Karl Pauls
>
> With a bundle config:
> lib.dll; processor=x86-64; osname=win32
> The dll won't be loaded on Windows Server 2016.
> PR: https://github.com/apache/felix/pull/93



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

[jira] [Updated] (FELIX-4837) Workaround for JNLPClassLoader in ShutdownHook

2017-02-20 Thread Karl Pauls (JIRA)


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

Karl Pauls updated FELIX-4837:
--
Fix Version/s: framework-5.6.4

> Workaround for JNLPClassLoader in ShutdownHook 
> ---
>
> Key: FELIX-4837
> URL: https://issues.apache.org/jira/browse/FELIX-4837
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-5.0.1, framework-5.6.1
> Environment: all
>Reporter: Nicolas Roduit
>Assignee: Karl Pauls
> Fix For: framework-5.6.4
>
>
> This a workaround of the issue that I submitted on 
> https://bugs.openjdk.java.net/browse/JDK-8054639
> The Java Web Start classloader doesn't support to have anonymous classes or 
> enum within the shutdown hook.
> The patch below allows to stop all the bundles correctly when calling  
> m_felix.stop() in the shutdown hook. Otherwise the framework throws an 
> exception and do not call the bundle stop. This is a problem when each bundle 
> write its preferences or state during the stop method.
> {code} 
> diff --git a/framework/src/main/java/org/apache/felix/framework/Felix.java 
> b/framework/src/main/java/org/apache/felix/framework/Felix.java
> index c6b305a..e44ccea 100644
> --- a/framework/src/main/java/org/apache/felix/framework/Felix.java
> +++ b/framework/src/main/java/org/apache/felix/framework/Felix.java
> @@ -1023,7 +1023,7 @@
>  {
>  // Spec says stop() on SystemBundle should return immediately and
>  // shutdown framework on another thread.
> -new Thread(new Runnable() {
> +Thread t = new Thread( "FelixShutdown"){
>  public void run()
>  {
>  try
> @@ -1038,7 +1038,8 @@
>  ex);
>  }
>  }
> -}, "FelixShutdown").start();
> +};
> +t.start();
>  }
>  }
> {code}



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

[jira] [Resolved] (FELIX-4837) Workaround for JNLPClassLoader in ShutdownHook

2017-02-20 Thread Karl Pauls (JIRA)


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

Karl Pauls resolved FELIX-4837.
---
Resolution: Fixed

I committed this in r1783785. Please close this issue if it works for you.

> Workaround for JNLPClassLoader in ShutdownHook 
> ---
>
> Key: FELIX-4837
> URL: https://issues.apache.org/jira/browse/FELIX-4837
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-5.0.1, framework-5.6.1
> Environment: all
>Reporter: Nicolas Roduit
>Assignee: Karl Pauls
>
> This a workaround of the issue that I submitted on 
> https://bugs.openjdk.java.net/browse/JDK-8054639
> The Java Web Start classloader doesn't support to have anonymous classes or 
> enum within the shutdown hook.
> The patch below allows to stop all the bundles correctly when calling  
> m_felix.stop() in the shutdown hook. Otherwise the framework throws an 
> exception and do not call the bundle stop. This is a problem when each bundle 
> write its preferences or state during the stop method.
> {code} 
> diff --git a/framework/src/main/java/org/apache/felix/framework/Felix.java 
> b/framework/src/main/java/org/apache/felix/framework/Felix.java
> index c6b305a..e44ccea 100644
> --- a/framework/src/main/java/org/apache/felix/framework/Felix.java
> +++ b/framework/src/main/java/org/apache/felix/framework/Felix.java
> @@ -1023,7 +1023,7 @@
>  {
>  // Spec says stop() on SystemBundle should return immediately and
>  // shutdown framework on another thread.
> -new Thread(new Runnable() {
> +Thread t = new Thread( "FelixShutdown"){
>  public void run()
>  {
>  try
> @@ -1038,7 +1038,8 @@
>  ex);
>  }
>  }
> -}, "FelixShutdown").start();
> +};
> +t.start();
>  }
>  }
> {code}



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

[jira] [Commented] (FELIX-4837) Workaround for JNLPClassLoader in ShutdownHook

2017-02-20 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on FELIX-4837:
---

Github user asfgit closed the pull request at:

https://github.com/apache/felix/pull/94


> Workaround for JNLPClassLoader in ShutdownHook 
> ---
>
> Key: FELIX-4837
> URL: https://issues.apache.org/jira/browse/FELIX-4837
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-5.0.1, framework-5.6.1
> Environment: all
>Reporter: Nicolas Roduit
>Assignee: Karl Pauls
> Fix For: framework-5.6.4
>
>
> This a workaround of the issue that I submitted on 
> https://bugs.openjdk.java.net/browse/JDK-8054639
> The Java Web Start classloader doesn't support to have anonymous classes or 
> enum within the shutdown hook.
> The patch below allows to stop all the bundles correctly when calling  
> m_felix.stop() in the shutdown hook. Otherwise the framework throws an 
> exception and do not call the bundle stop. This is a problem when each bundle 
> write its preferences or state during the stop method.
> {code} 
> diff --git a/framework/src/main/java/org/apache/felix/framework/Felix.java 
> b/framework/src/main/java/org/apache/felix/framework/Felix.java
> index c6b305a..e44ccea 100644
> --- a/framework/src/main/java/org/apache/felix/framework/Felix.java
> +++ b/framework/src/main/java/org/apache/felix/framework/Felix.java
> @@ -1023,7 +1023,7 @@
>  {
>  // Spec says stop() on SystemBundle should return immediately and
>  // shutdown framework on another thread.
> -new Thread(new Runnable() {
> +Thread t = new Thread( "FelixShutdown"){
>  public void run()
>  {
>  try
> @@ -1038,7 +1038,8 @@
>  ex);
>  }
>  }
> -}, "FelixShutdown").start();
> +};
> +t.start();
>  }
>  }
> {code}



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

adaptTo() 2017 Conference in Berlin

2017-02-20 Thread Stefan Seifert

Good morning everyone,

focusing on Apache Sling, Apache Felix and Apache Jackrabbit, the adaptTo() 
conference in Berlin is aimed at developers using some or all if this stack.

If you are not familiar with our event yet, you might find something 
interesting in the sessions from last year http://adapt.to/2016/schedule

Conference Date is 25-27 September; latest information can be found on 
http://adapt.to
Our Call for Papers is open now until 21 April http://adapt.to/cfp
Early Bird Tickets will save you -15% http://adapt.to/tickets

Have a great week and we look forward to seeing you in Berlin.

Kind regards on behalf of the adaptTo() Team,
Stefan

p.s. Apache Sling/Felix/Jackrabbit Comitters receive a discount - see 
https://adapt.to/conference

[jira] [Commented] (FELIX-4837) Workaround for JNLPClassLoader in ShutdownHook

2017-02-20 Thread David Bosschaert (JIRA)


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

David Bosschaert commented on FELIX-4837:
-

The fix looks a bit weird but yeah, if it works around a problem that exists in 
JDK 6,7 or 8 then I think we should take it. In any case it won't do any harm 
AFAICS.

> Workaround for JNLPClassLoader in ShutdownHook 
> ---
>
> Key: FELIX-4837
> URL: https://issues.apache.org/jira/browse/FELIX-4837
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: framework-5.0.1, framework-5.6.1
> Environment: all
>Reporter: Nicolas Roduit
>Assignee: Karl Pauls
>
> This a workaround of the issue that I submitted on 
> https://bugs.openjdk.java.net/browse/JDK-8054639
> The Java Web Start classloader doesn't support to have anonymous classes or 
> enum within the shutdown hook.
> The patch below allows to stop all the bundles correctly when calling  
> m_felix.stop() in the shutdown hook. Otherwise the framework throws an 
> exception and do not call the bundle stop. This is a problem when each bundle 
> write its preferences or state during the stop method.
> {code} 
> diff --git a/framework/src/main/java/org/apache/felix/framework/Felix.java 
> b/framework/src/main/java/org/apache/felix/framework/Felix.java
> index c6b305a..e44ccea 100644
> --- a/framework/src/main/java/org/apache/felix/framework/Felix.java
> +++ b/framework/src/main/java/org/apache/felix/framework/Felix.java
> @@ -1023,7 +1023,7 @@
>  {
>  // Spec says stop() on SystemBundle should return immediately and
>  // shutdown framework on another thread.
> -new Thread(new Runnable() {
> +Thread t = new Thread( "FelixShutdown"){
>  public void run()
>  {
>  try
> @@ -1038,7 +1038,8 @@
>  ex);
>  }
>  }
> -}, "FelixShutdown").start();
> +};
> +t.start();
>  }
>  }
> {code}



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

[VOTE RESULT] Release Apache Felix Webconsole Plugins: Event 1.1.6 and PackageAdmin 1.0.4

2017-02-20 Thread Carsten Ziegeler

The vote passes with three binding and one non binding +1 votes

Thanks

 Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Commented] (FELIX-5549) Factory component fails to reactivate after config changes

2017-02-20 Thread Alex Soto (JIRA)


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

Alex Soto commented on FELIX-5549:
--

So you are saying this works as expected.

I find this behavior is very odd; it seems to go against the dynamism, which is 
probably the main selling point of the framework. Components should come and go 
in a dynamic way, but in this case, the component just goes away, and never 
comes back.  It is also very counter-intuitive, since the other kind of 
component will be reactivated when its configuration changes, but not this. To 
be clear,  I am only talking about the 
org.osgi.service.component.ComponentFactory, which gets deactivated and never 
reactivated again.  I understand that instances of FactoryComp will not be 
automatically reactivated, since it is flagged as factory component, and that 
is fine.  My problem is that the Witheboard pattern is broken; a change of the 
configuration stops the ComponentFactory, but I need it to be reactivated with 
the new configuration values, not stopped.

On a different note, I do think factory components are useful, and I have 
designed my solution based on this mechanism.  Are factory component going to 
be removed in a future release?  If not, I think this should be fixed.  Unless 
there is a reason for this odd behavior, which I don't see right now.   Do you 
know what is the rationale behind this behavior?



> Factory component fails to reactivate after config changes
> --
>
> Key: FELIX-5549
> URL: https://issues.apache.org/jira/browse/FELIX-5549
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
> Environment: Karaf 4.0.8
>Reporter: Alex Soto
>
> A factory component fails to reactive after the configuration changes.  
> Initially, the component initializes normally.  After it is in Active state, 
> the configuration referenced by the component _configurationPid_  changes, 
> which causes the component to not activate again.
> A minimal application demonstrating this behavior is available here:
> https://github.com/lexsoto/blueprint-ds-config-reload



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

[jira] [Commented] (FELIX-5555) JSONParser is not handling escape char properly

2017-02-20 Thread Julian Reschke (JIRA)


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

Julian Reschke commented on FELIX-:
---

Indeed, see :

{noformat}
   string = quotation-mark *char quotation-mark

   char = unescaped /
   escape (
   %x22 /  ; "quotation mark  U+0022
   %x5C /  ; \reverse solidus U+005C
   %x2F /  ; /solidus U+002F
   %x62 /  ; bbackspace   U+0008
   %x66 /  ; fform feed   U+000C
   %x6E /  ; nline feed   U+000A
   %x72 /  ; rcarriage return U+000D
   %x74 /  ; ttab U+0009
   %x75 4HEXDIG )  ; uU+

   escape = %x5C  ; \

   quotation-mark = %x22  ; "

   unescaped = %x20-21 / %x23-5B / %x5D-10
{noformat}

> JSONParser is not handling escape char properly
> ---
>
> Key: FELIX-
> URL: https://issues.apache.org/jira/browse/FELIX-
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Affects Versions: utils-1.9.0
>Reporter: Chetan Mehrotra
> Fix For: utils-1.9.2
>
>
> {{JSONWriter}} currently adds an escape char for '/'. So "foo=/bar" is 
> rendered as 
> {noformat}
> {"foo":"\/bar"}
> {noformat}
> When such a json is read via {{JSONParser}} then the '\' is not removed
> Following test fails
> {code}
> @Test
> public void escapeChar() throws Exception{
> StringWriter sw = new StringWriter();
> JSONWriter js = new JSONWriter(sw);
> js.object().key("foo").value("/bar").endObject().flush();
> 
> JSONParser jp = new JSONParser(sw.toString());
> assertEquals("/bar", jp.getParsed().get("foo"));
> }
> {code}



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

[jira] [Commented] (FELIX-5555) JSONParser is not handling escape char properly

2017-02-20 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on FELIX-:


bq. escaping of the writer is correct, a slash can be espaced - it's not a must 
though

http://stackoverflow.com/questions/1580647/json-why-are-forward-slashes-escaped 
also confirms that. FWIW org.json.JSONObject did not escaped the slash but its 
done by other libraries

> JSONParser is not handling escape char properly
> ---
>
> Key: FELIX-
> URL: https://issues.apache.org/jira/browse/FELIX-
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Affects Versions: utils-1.9.0
>Reporter: Chetan Mehrotra
> Fix For: utils-1.9.2
>
>
> {{JSONWriter}} currently adds an escape char for '/'. So "foo=/bar" is 
> rendered as 
> {noformat}
> {"foo":"\/bar"}
> {noformat}
> When such a json is read via {{JSONParser}} then the '\' is not removed
> Following test fails
> {code}
> @Test
> public void escapeChar() throws Exception{
> StringWriter sw = new StringWriter();
> JSONWriter js = new JSONWriter(sw);
> js.object().key("foo").value("/bar").endObject().flush();
> 
> JSONParser jp = new JSONParser(sw.toString());
> assertEquals("/bar", jp.getParsed().get("foo"));
> }
> {code}



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

[jira] [Resolved] (FELIX-5351) 5.7 Coordinations

2017-02-20 Thread Carsten Ziegeler (JIRA)


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

Carsten Ziegeler resolved FELIX-5351.
-
Resolution: Fixed

> 5.7 Coordinations
> -
>
> Key: FELIX-5351
> URL: https://issues.apache.org/jira/browse/FELIX-5351
> Project: Felix
>  Issue Type: Sub-task
>  Components: Configuration Admin
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: configadmin-1.9.0
>
>
> If configurations are created, updated or deleted and an implicit 
> coordination exists, Configuration Admin should delay updating the 
> ManagedService(Factory) and notifying the async configuration listeners until 
> the coordination completes (either ends or fails)



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

[jira] [Commented] (FELIX-5555) JSONParser is not handling escape char properly

2017-02-20 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra commented on FELIX-:


Added ignored test in 1783740. 

> JSONParser is not handling escape char properly
> ---
>
> Key: FELIX-
> URL: https://issues.apache.org/jira/browse/FELIX-
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Affects Versions: utils-1.9.0
>Reporter: Chetan Mehrotra
> Fix For: utils-1.9.2
>
>
> {{JSONWriter}} currently adds an escape char for '/'. So "foo=/bar" is 
> rendered as 
> {noformat}
> {"foo":"\/bar"}
> {noformat}
> When such a json is read via {{JSONParser}} then the '\' is not removed
> Following test fails
> {code}
> @Test
> public void escapeChar() throws Exception{
> StringWriter sw = new StringWriter();
> JSONWriter js = new JSONWriter(sw);
> js.object().key("foo").value("/bar").endObject().flush();
> 
> JSONParser jp = new JSONParser(sw.toString());
> assertEquals("/bar", jp.getParsed().get("foo"));
> }
> {code}



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

[jira] [Updated] (FELIX-5555) JSONParser is not handling escape char properly

2017-02-20 Thread Chetan Mehrotra (JIRA)


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

Chetan Mehrotra updated FELIX-:
---
Summary: JSONParser is not handling escape char properly  (was: JSONParser 
is not removing escape char)

> JSONParser is not handling escape char properly
> ---
>
> Key: FELIX-
> URL: https://issues.apache.org/jira/browse/FELIX-
> Project: Felix
>  Issue Type: Bug
>  Components: Utils
>Affects Versions: utils-1.9.0
>Reporter: Chetan Mehrotra
> Fix For: utils-1.9.2
>
>
> {{JSONWriter}} currently adds an escape char for '/'. So "foo=/bar" is 
> rendered as 
> {noformat}
> {"foo":"\/bar"}
> {noformat}
> When such a json is read via {{JSONParser}} then the '\' is not removed
> Following test fails
> {code}
> @Test
> public void escapeChar() throws Exception{
> StringWriter sw = new StringWriter();
> JSONWriter js = new JSONWriter(sw);
> js.object().key("foo").value("/bar").endObject().flush();
> 
> JSONParser jp = new JSONParser(sw.toString());
> assertEquals("/bar", jp.getParsed().get("foo"));
> }
> {code}



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

[jira] [Created] (FELIX-5555) JSONParser is not removing escape char

2017-02-20 Thread Chetan Mehrotra (JIRA)

Chetan Mehrotra created FELIX-:
--

 Summary: JSONParser is not removing escape char
 Key: FELIX-
 URL: https://issues.apache.org/jira/browse/FELIX-
 Project: Felix
  Issue Type: Bug
  Components: Utils
Affects Versions: utils-1.9.0
Reporter: Chetan Mehrotra
 Fix For: utils-1.9.2


{{JSONWriter}} currently adds an escape char for '/'. So "foo=/bar" is rendered 
as 
{noformat}
{"foo":"\/bar"}
{noformat}

When such a json is read via {{JSONParser}} then the '\' is not removed

Following test fails
{code}
@Test
public void escapeChar() throws Exception{
StringWriter sw = new StringWriter();
JSONWriter js = new JSONWriter(sw);
js.object().key("foo").value("/bar").endObject().flush();

JSONParser jp = new JSONParser(sw.toString());
assertEquals("/bar", jp.getParsed().get("foo"));
}
{code}



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

Re: Volunteer for service diagnostics plugin (Scala)?

2017-02-20 Thread Joune

Hi,

Sorry everyone, I should have done this already, I'll do it.

Thanks,
Arjun


--
http://arjunpanday.tumblr.com
http://www.arjunpanday.fr

On Mon, Feb 20, 2017 at 8:55 AM, Carsten Ziegeler 
wrote:

> Hi,
>
> we have only one single module left where we have to replace the usage
> of org.json: the service diagnostics plugin.
> This one is written in Scala. I assume the replacement is not that
> difficult.
> So if there are any volunteers for this, feel free to pick up FELIX-5554.
>
> Thanks
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

37 matches

Mail list logo