[GitHub] felix pull request #120: [FELIX-4447] fix regexp, thanks to Olivier Fayau

2017-09-20 Thread cgdrake 
GitHub user cgdrake opened a pull request:

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

[FELIX-4447] fix regexp, thanks to Olivier Fayau

git-svn-id: https://svn.apache.org/repos/asf/felix/trunk/scr@1591422 
13f79535-47bb-0310-9956-ffa450edef68

Given that this is a low impact and trivial fix which causes a fair bit of 
aggrevation, it would be great if this could be merged into the scr-1.8.x 
branch and released in 1.8.5.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cgdrake/felix scr-1.8.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/120.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #120


commit 29e5f8d247c5e927b6e703a7b1ed2f87d5015fa7
Author: David Jencks 
Date:   2014-04-30T18:01:38Z

[FELIX-4447] fix regexp, thanks to Olivier Fayau

git-svn-id: https://svn.apache.org/repos/asf/felix/trunk/scr@1591422 
13f79535-47bb-0310-9956-ffa450edef68




---

[jira] [Commented] (FELIX-4447) Regression in ScrShellCommand (NPE caused by falsy regex)

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

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

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

GitHub user cgdrake opened a pull request:

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

[FELIX-4447] fix regexp, thanks to Olivier Fayau

git-svn-id: https://svn.apache.org/repos/asf/felix/trunk/scr@1591422 
13f79535-47bb-0310-9956-ffa450edef68

Given that this is a low impact and trivial fix which causes a fair bit of 
aggrevation, it would be great if this could be merged into the scr-1.8.x 
branch and released in 1.8.5.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cgdrake/felix scr-1.8.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/120.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #120


commit 29e5f8d247c5e927b6e703a7b1ed2f87d5015fa7
Author: David Jencks 
Date:   2014-04-30T18:01:38Z

[FELIX-4447] fix regexp, thanks to Olivier Fayau

git-svn-id: https://svn.apache.org/repos/asf/felix/trunk/scr@1591422 
13f79535-47bb-0310-9956-ffa450edef68




> Regression in ScrShellCommand (NPE caused by falsy regex)
> -
>
> Key: FELIX-4447
> URL: https://issues.apache.org/jira/browse/FELIX-4447
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR), Script Console Plugin
>Affects Versions: scr-1.8.0, scr-1.8.2
>Reporter: Olivier Fayau
>Assignee: David Jencks
>  Labels: easyfix
> Fix For: scr-2.0.0
>
>
> Using felix console and DS (scr + shell +shell tui), the command scr doesn't 
> work anymore.
> Sample : 
> scr list
> -> Unable to execute command: java.lang.NullPointerException
> java.lang.NullPointerException
>   at 
> org.apache.felix.scr.impl.ScrShellCommand.help(ScrShellCommand.java:116)
>   at 
> org.apache.felix.scr.impl.ScrShellCommand.execute(ScrShellCommand.java:75)
>   at 
> org.apache.felix.shell.impl.Activator$ShellServiceImpl.executeCommand(Activator.java:249)
>   at 
> org.apache.felix.shell.tui.Activator$ShellTuiRunnable.run(Activator.java:184)
>   at java.lang.Thread.run(Unknown Source)
> Looking at source code, in ScrShellCommand.execute(), command is splitted by 
> the falsy regex "//s".
> This should be "\\s+" instead.



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

Re: [ConfigAdmin] Changing handling of persistence managers

2017-09-20 Thread Carsten Ziegeler 
Grzegorz Grzybek wrote
> Hello
> 
> I like the idea of "only one PM is used" - or rather I don't like the
> idea of using a whole array of all available
> org.apache.felix.cm.PersistenceManager implementations.
> 
> In my particular case I wanted to provide "encrypting file persistence
> manager" - ideally I wanted to wrap existing FilePersistenceManager,
> so it saves/loads encrypted properties.
> The first problem was that I couldn't unregister default FPM, so I had
> to do some injection magic to replace first element of
> org.apache.felix.cm.impl.ConfigurationManager#persistenceManagers
> array.
> 
>> - the file PM is not registered as a service anymore
> 
> I'd like to be able to get it anyway (to implement "wrapping"
> persistence managers) - like configmanager is told to use
> (&(objectClass=org.apache.felix.cm.PersistenceManager)(name=encrypting)),
> but the encrypting PM itself could wrap *published*
> (&(objectClass=org.apache.felix.cm.PersistenceManager)(name=file)).
> 

Thanks for the info, so yes, this is a case to continue registering the
default PM.

Carsten

 

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

Re: [ConfigAdmin] Changing handling of persistence managers

2017-09-20 Thread Grzegorz Grzybek 
Hello

I like the idea of "only one PM is used" - or rather I don't like the
idea of using a whole array of all available
org.apache.felix.cm.PersistenceManager implementations.

In my particular case I wanted to provide "encrypting file persistence
manager" - ideally I wanted to wrap existing FilePersistenceManager,
so it saves/loads encrypted properties.
The first problem was that I couldn't unregister default FPM, so I had
to do some injection magic to replace first element of
org.apache.felix.cm.impl.ConfigurationManager#persistenceManagers
array.

> - the file PM is not registered as a service anymore

I'd like to be able to get it anyway (to implement "wrapping"
persistence managers) - like configmanager is told to use
(&(objectClass=org.apache.felix.cm.PersistenceManager)(name=encrypting)),
but the encrypting PM itself could wrap *published*
(&(objectClass=org.apache.felix.cm.PersistenceManager)(name=file)).

regards
Grzegorz Grzybek


2017-09-20 12:25 GMT+02:00 Carsten Ziegeler :
>
> Hi
>
> the current way of handling persistence managers in our config admin
> implementation is not 100% reliable and ultimately can lead to confusion
> and wrong results (see FELIX-5693 and FELIX-5685).
>
> Now, I've suggested an improvement in FELIX-5693 which should solve the
> problem and provides a 100% compatible solution. However while
> implementing this, I found out that being 100% compatible makes the code
> really ugly. So I'm wondering now if we really need to go that far.
>
> Today, one can register as many persistence managers and *all* of them
> are picked up and used ordered by service ranking. As the file PM is
> registered by default, there is always one and this one is used from the
> beginning. Some more details are in those issues.
>
> I think we should change this to:
> - only one PM is used
> - if no configuration (through framework prop) is provided the current
> file PM is used
> - the file PM is not registered as a service anymore (there is no use in
> doing so)
> - if a config is provided, this is the name of the PM (service property)
> and only if that service is available, the CM is activated/registered
>
> This simplifies the config of the CM, the handling of PMs and also the
> code. The downside is that if you want to use a custom PM it requires
> you to set a configuration. As this is usually not the common use case I
> think thats fine.
>
> If we want to be 100% compatible, then we have the ugly handling by
> default and if you want to restrict this to just the file PM you have to
> provide a config option. Which ultimately every user of our bundle
> should do (unless a custom PM should be used)
>
> WDYT?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[ConfigAdmin] Changing handling of persistence managers

2017-09-20 Thread Carsten Ziegeler 
Hi

the current way of handling persistence managers in our config admin
implementation is not 100% reliable and ultimately can lead to confusion
and wrong results (see FELIX-5693 and FELIX-5685).

Now, I've suggested an improvement in FELIX-5693 which should solve the
problem and provides a 100% compatible solution. However while
implementing this, I found out that being 100% compatible makes the code
really ugly. So I'm wondering now if we really need to go that far.

Today, one can register as many persistence managers and *all* of them
are picked up and used ordered by service ranking. As the file PM is
registered by default, there is always one and this one is used from the
beginning. Some more details are in those issues.

I think we should change this to:
- only one PM is used
- if no configuration (through framework prop) is provided the current
file PM is used
- the file PM is not registered as a service anymore (there is no use in
doing so)
- if a config is provided, this is the name of the PM (service property)
and only if that service is available, the CM is activated/registered

This simplifies the config of the CM, the handling of PMs and also the
code. The downside is that if you want to use a custom PM it requires
you to set a configuration. As this is usually not the common use case I
think thats fine.

If we want to be 100% compatible, then we have the ugly handling by
default and if you want to restrict this to just the file PM you have to
provide a config option. Which ultimately every user of our bundle
should do (unless a custom PM should be used)

WDYT?

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

[jira] [Assigned] (FELIX-5693) Improve persistent manager handling

2017-09-20 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler reassigned FELIX-5693:
---

Assignee: Carsten Ziegeler

> Improve persistent manager handling
> ---
>
> Key: FELIX-5693
> URL: https://issues.apache.org/jira/browse/FELIX-5693
> Project: Felix
>  Issue Type: Improvement
>  Components: Configuration Admin
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: configadmin-1.9.0
>
>
> The current handling of persistence managers is a little bit fragile and not 
> really deterministic.
> I propose the following enhancements:
> - Persistence managers can be registered with a "name" service property. The 
> FilePersistenceManager gets a name, e.g. "file"
> - we add a new framework property configuration - if that's empty or not 
> there, CM acts as today
> - if a value is configured, it's interpreted as a comma separated list of 
> names. This list of names makes up the PMs to be used by the implementation. 
> All of them must be registered and only these are used.
> - the PMs are used in the order they are specified in the list
> With this we have deterministic behaviour and full control while the default 
> ootb behaviour is still maintained. 



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

[jira] [Commented] (FELIX-5693) Improve persistent manager handling

2017-09-20 Thread Carsten Ziegeler (JIRA) 

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

Carsten Ziegeler commented on FELIX-5693:
-

In rev 1808980 I moved the current mechanism to a separate class and added a 
name property to the provider interface

> Improve persistent manager handling
> ---
>
> Key: FELIX-5693
> URL: https://issues.apache.org/jira/browse/FELIX-5693
> Project: Felix
>  Issue Type: Improvement
>  Components: Configuration Admin
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: configadmin-1.9.0
>
>
> The current handling of persistence managers is a little bit fragile and not 
> really deterministic.
> I propose the following enhancements:
> - Persistence managers can be registered with a "name" service property. The 
> FilePersistenceManager gets a name, e.g. "file"
> - we add a new framework property configuration - if that's empty or not 
> there, CM acts as today
> - if a value is configured, it's interpreted as a comma separated list of 
> names. This list of names makes up the PMs to be used by the implementation. 
> All of them must be registered and only these are used.
> - the PMs are used in the order they are specified in the list
> With this we have deterministic behaviour and full control while the default 
> ootb behaviour is still maintained. 



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

[jira] [Commented] (FELIX-5678) Allow merging of objects

2017-09-20 Thread David Bosschaert (JIRA) 

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

David Bosschaert commented on FELIX-5678:
-

bq.  IIUC the API is no longer open for comments, correct? So either we'd have 
to go about it this way, or build an extra layer on top of the Converter. Or, 
maybe this is something all together different.

Yes, the OSGi Converter API for the R7 release is pretty much locked down now, 
but we can still work on enhancements and improvements for R8...

> Allow merging of objects
> 
>
> Key: FELIX-5678
> URL: https://issues.apache.org/jira/browse/FELIX-5678
> Project: Felix
>  Issue Type: Bug
>  Components: Converter
>Reporter: David Leangen
>
> Given a typed object O1 and a "partial" representation of an object O2 (for 
> instance in the form of a Map), allow O2 to be merged into O1.
> Example:
> {code}
> public class Foo {
>   public String a;
>   public String b;
>   public String c;
> }
> Foo f = new Foo();
> a = "Eh!";
> b = "Be cool.";
> c = "See you later?";
> Map m = new Map<>();
> m.put("b", "Be there or be square");
> Foo f2 = Converter.convert(f).merge(m);
> {code}
> I am sure there are many ways to skin this cat.
> If the Converter API cannot be changed, what would be the best way to tackle 
> this problem?
> (In the meantime, while awaiting comments form [~bosschaert], I'll try to run 
> a few experiments to see if I can come up with something reasonable.)



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