[jira] [Created] (FELIX-5945) Avoid unnecessary reflection

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created FELIX-5945:
---

 Summary: Avoid unnecessary reflection
 Key: FELIX-5945
 URL: https://issues.apache.org/jira/browse/FELIX-5945
 Project: Felix
  Issue Type: Improvement
  Components: Configurator
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: configurator-1.0.8


For reading the state model, currently reflection is used to set final fields. 
If we switch to non final fields we can avoid the reflection



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5913) Support Android

[Tom Rutchik (JIRA)]

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

Tom Rutchik commented on FELIX-5913:


Paul,

I've done a quick inspection of your trunk. It contains the import statement:

Import dalvik.system.PathClassLoader 

That's an android dependency and you can't do that unless you're planning to 
support two org.apache.felix.framework versions: one for Java VM and another 
for Dalvik VM. It'll probably produce compiler/lint errors in Java.  That's the 
general assumption I've been working on.  If you can use PathClassLoader as a 
first order class, as opposed to loading it using java reflections 
(Class.forName(classname)) that certainly lends itself to a much simpler 
solution, since one can't extend a class by a class obtained through java 
reflections.

-Tom Rutchik



> Support Android
> ---
>
> Key: FELIX-5913
> URL: https://issues.apache.org/jira/browse/FELIX-5913
> Project: Felix
>  Issue Type: Wish
>  Components: Framework
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Tom Rutchik
>Priority: Major
> Attachments: BundleWiringImpl.java, 
> FelixAndroidSupportImplementationNotes.pdf
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> The lastest 6.0.0 and 6.0.1 release no longer works on Android.
> The code form the 5.6.10 version necessary to make it work was not ported 
> into these versions.
> Some code needs to be added to the class BundleWiringImpl class to allow for 
> android support. All of the code necessary to due that can be found in the 
> 5.6.10 version.
> I've added the code and have tested it and it's working fine again.  I've 
> attached an implementation of BundleWiringImpl that works with android. It's 
> basically the 6.0.1 implementation with the extra code from 5.6.10.  You 
> should be able to do a file diff on the 6.0.1 to see where I had to add the 
> missing code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5913) Support Android

[Tom Rutchik (JIRA)]

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

Tom Rutchik commented on FELIX-5913:


Paul,

I'm not quite following the argument.  The statement:
"However, I think it is somewhat problematic that we can not be the classloader 
itself."
Is what's confusing me. The claim seem to suggest I've made some kind of false 
assumption.  That could be case, but I'm not seeing it.

 In the case of not running on an android system, there's really no change in 
how the code executes.  I'm also not seeing any direct dependences on Android. 
In my inspection, all the android classes only come into play when you're 
running on an Android VM.  And all those classes are all produced through Java 
reflections, so it shouldn't interfer with the Java implementation.  I also 
don't see any import statements that have any android dependencies in them.

All I've done is subclassed the BundleClassLoader and delegated the loadClass 
method to a PathClassLoader (produce through Java reflection) whose parent is 
the normal BundleClassLoader. It's only affect is that it tries the 
PathClassLoader's path to load the class if the BundleClassLoader fails to load 
the class; this is effectively what the 5.6.10 version did except it did it as 
a direct call to the DexFile class after as the last step of the 
BundleCLassLoader.  In the new model, the BundleClassLoader fails and then the 
PathClassLoader tries to see if it can find the class on its path.

I also don't see how BundleReference and Lazy Evaluation would be affected.  
Are they using some different mechanism that bypasses the normal 
BundleClassLoader?  I was only aware of the one place in the code that DexFile 
was used, and that was in the BundleWiringImpl!  If that's not the case, then 
yes, there is something wrong, but I don't think so.

What I'm trying to say, IMHO is that the code changes I made all  preserve the 
original semantics (SPT - semantic preservation transformation). How 
BundleWiringImp Class and the BundleClassLoader was used before, remains the 
same. In the case of the Java VM, you work directly with the BundleClassLoader, 
and in the case of the Dalvik VM your actually working with the 
DexBundleClassLoader, which is treated like any other BundleClassLoader.

--
That said, I will be looking at your branch and see how you approached the 
problem.  Maybe that'll clear up some of the confusing that I referred to 
above.  I'll try to send you some comment back tomorrow.  I can also try 
running it in my  project to test it out.

-Tom Rutchik



> Support Android
> ---
>
> Key: FELIX-5913
> URL: https://issues.apache.org/jira/browse/FELIX-5913
> Project: Felix
>  Issue Type: Wish
>  Components: Framework
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Tom Rutchik
>Priority: Major
> Attachments: BundleWiringImpl.java, 
> FelixAndroidSupportImplementationNotes.pdf
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> The lastest 6.0.0 and 6.0.1 release no longer works on Android.
> The code form the 5.6.10 version necessary to make it work was not ported 
> into these versions.
> Some code needs to be added to the class BundleWiringImpl class to allow for 
> android support. All of the code necessary to due that can be found in the 
> 5.6.10 version.
> I've added the code and have tested it and it's working fine again.  I've 
> attached an implementation of BundleWiringImpl that works with android. It's 
> basically the 6.0.1 implementation with the extra code from 5.6.10.  You 
> should be able to do a file diff on the 6.0.1 to see where I had to add the 
> missing code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (FELIX-5913) Support Android

[Karl Pauls (JIRA)]

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

Karl Pauls edited comment on FELIX-5913 at 9/26/18 10:11 PM:
-

[~tom.phinneyri...@gmail.com], I had a look at your PR and I think it is going 
into the right direction. Thanks a lot for your effort!

However, I think it is somewhat problematic that we can not be the classloader 
itself. That will make certain things not work like e.g. the BundleReference 
and lazy activation. Furthermore, we are making assumptions about being the 
classloader in some other parts of the framework which might be problematic. 

After thinking about it some more, I might have found a solution to that 
problem. I created a POC based on your work that adds a fake 
dalvik.PathClassLoader class (in order to compile without dependencies on 
android) and use that to extend it in a new BundleClassLoaderDalvik. 

I created a branch that you should be able to checkout/fork here: 
https://github.com/karlpauls/felix/tree/android

and a PR (in case you prefer a diff): https://github.com/karlpauls/felix/pull/2 

Could you test the POC on Android and see if it works (or if not, see if you 
could massage it to work)? 


was (Author: karlpauls):
[~tom.phinneyri...@gmail.com], I had a look at our PR and I think it is going 
into the right direction. 

However, I think it is somewhat problematic that we can not be the classloader 
itself. That will make certain things not work like e.g. the BundleReference 
and lazy activation. Furthermore, we are making assumptions about being the 
classloader in some other parts of the framework which might be problematic. 

After thinking about it some more, I might have found a solution to that 
problem. I created a POC based on your work that adds a fake 
dalvik.PathClassLoader class (in order to compile without dependencies on 
android) and use that to extend it in a new BundleClassLoaderDalvik. 

I created a branch that you should be able to checkout/fork here: 
https://github.com/karlpauls/felix/tree/android

and a PR (in case you prefer a diff): https://github.com/karlpauls/felix/pull/2 

Could you test the POC on Android and see if it works (or if not, see if you 
could massage it to work)? 

> Support Android
> ---
>
> Key: FELIX-5913
> URL: https://issues.apache.org/jira/browse/FELIX-5913
> Project: Felix
>  Issue Type: Wish
>  Components: Framework
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Tom Rutchik
>Priority: Major
> Attachments: BundleWiringImpl.java, 
> FelixAndroidSupportImplementationNotes.pdf
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> The lastest 6.0.0 and 6.0.1 release no longer works on Android.
> The code form the 5.6.10 version necessary to make it work was not ported 
> into these versions.
> Some code needs to be added to the class BundleWiringImpl class to allow for 
> android support. All of the code necessary to due that can be found in the 
> 5.6.10 version.
> I've added the code and have tested it and it's working fine again.  I've 
> attached an implementation of BundleWiringImpl that works with android. It's 
> basically the 6.0.1 implementation with the extra code from 5.6.10.  You 
> should be able to do a file diff on the 6.0.1 to see where I had to add the 
> missing code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5913) Support Android

[Karl Pauls (JIRA)]

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

Karl Pauls commented on FELIX-5913:
---

[~tom.phinneyri...@gmail.com], I had a look at our PR and I think it is going 
into the right direction. 

However, I think it is somewhat problematic that we can not be the classloader 
itself. That will make certain things not work like e.g. the BundleReference 
and lazy activation. Furthermore, we are making assumptions about being the 
classloader in some other parts of the framework which might be problematic. 

After thinking about it some more, I might have found a solution to that 
problem. I created a POC based on your work that adds a fake 
dalvik.PathClassLoader class (in order to compile without dependencies on 
android) and use that to extend it in a new BundleClassLoaderDalvik. 

I created a branch that you should be able to checkout/fork here: 
https://github.com/karlpauls/felix/tree/android

and a PR (in case you prefer a diff): https://github.com/karlpauls/felix/pull/2 

Could you test the POC on Android and see if it works (or if not, see if you 
could massage it to work)? 

> Support Android
> ---
>
> Key: FELIX-5913
> URL: https://issues.apache.org/jira/browse/FELIX-5913
> Project: Felix
>  Issue Type: Wish
>  Components: Framework
>Affects Versions: framework-6.0.0, framework-6.0.1
>Reporter: Tom Rutchik
>Priority: Major
> Attachments: BundleWiringImpl.java, 
> FelixAndroidSupportImplementationNotes.pdf
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> The lastest 6.0.0 and 6.0.1 release no longer works on Android.
> The code form the 5.6.10 version necessary to make it work was not ported 
> into these versions.
> Some code needs to be added to the class BundleWiringImpl class to allow for 
> android support. All of the code necessary to due that can be found in the 
> 5.6.10 version.
> I've added the code and have tested it and it's working fine again.  I've 
> attached an implementation of BundleWiringImpl that works with android. It's 
> basically the 6.0.1 implementation with the extra code from 5.6.10.  You 
> should be able to do a file diff on the 6.0.1 to see where I had to add the 
> missing code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5911) [Configurator] Too restrictive permissions.perm file

[Karl Pauls (JIRA)]

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

Karl Pauls commented on FELIX-5911:
---

yup

> [Configurator] Too restrictive permissions.perm file
> 
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (FELIX-5911) [Configurator] Too restrictive permissions.perm file

[JIRA]

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

Christoph Nölle edited comment on FELIX-5911 at 9/26/18 5:42 PM:
-

I was not referring to the permissions of the Java runtime. According to the 
security spec (50.2.1 Local Permissions):
[https://osgi.org/specification/osgi.core/7.0.0/service.condpermadmin.html#i1534520]
 

??Local permissions are defined by a Bundle Permission Resource that is 
contained in the bundle; this resource defines a set of _permissions_. These 
permissions must be enforced by the Framework for the given bundle. That is, a 
bundle can get less permissions than the local permissions but it can never get 
more permissions.??

The remainder of the section is also very clear about it: adding a permission 
to ConditionalPermissionAdmin does not overwrite the local perms.


was (Author: cnoelle):
I was not referring to the permissions of the Java runtime. According to the 
security spec [50.2.1 Local Permissions, 
https://osgi.org/specification/osgi.core/7.0.0/service.condpermadmin.html#i1534520]:

??Local permissions are defined by a Bundle Permission Resource that is 
contained in the bundle; this resource defines a set of _permissions_. These 
permissions must be enforced by the Framework for the given bundle. That is, a 
bundle can get less permissions than the local permissions but it can never get 
more permissions.??

The remainder of the section is also very clear about it: adding a permission 
to ConditionalPermissionAdmin does not overwrite the local perms.

> [Configurator] Too restrictive permissions.perm file
> 
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5911) [Configurator] Too restrictive permissions.perm file

[JIRA]

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

Christoph Nölle commented on FELIX-5911:


I was not referring to the permissions of the Java runtime. According to the 
security spec [50.2.1 Local Permissions, 
https://osgi.org/specification/osgi.core/7.0.0/service.condpermadmin.html#i1534520]:

??Local permissions are defined by a Bundle Permission Resource that is 
contained in the bundle; this resource defines a set of _permissions_. These 
permissions must be enforced by the Framework for the given bundle. That is, a 
bundle can get less permissions than the local permissions but it can never get 
more permissions.??

The remainder of the section is also very clear about it: adding a permission 
to ConditionalPermissionAdmin does not overwrite the local perms.

> [Configurator] Too restrictive permissions.perm file
> 
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-5937) Refactor DM bndtools/gradle project

[Pierre De Rop (JIRA)]

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

Pierre De Rop updated FELIX-5937:
-
Description: 
The DM gradle project structure has been enhanced (see [1]) and I'd like to 
merge the enhancements in the felix trunk.

Mainly:
 * all build time binary dependencies are now downloaded from maven central 
using the bndtools "aQute.bnd.repository.maven.provider.MavenBndRepository".
 * The gradle wrapper is not commited anymore and is downloaded by the 
"gradlew" scripts.
 * Fixed some issues in the release/build.gradle script, which now allows to 
interactively specify the PGP key when calling the "gradlew signStaging" task

The consequence of this is that we don't need anymore to deliver a "-deps.zip" 
bundle which was containing so far build-time binary dependencies.

[1]https://github.com/pderop/dm.enhanced

  was:
The DM gradle project structure has been enhanced (see 
[1][),|https://github.com/pderop/dm.enhanced),] and I'd like to merge the 
enhancements in the felix trunk.

Mainly:
 * all build time binary dependencies are now downloaded from maven central 
using the bndtools "aQute.bnd.repository.maven.provider.MavenBndRepository".
 * The gradle wrapper is not commited anymore and is downloaded by the 
"gradlew" scripts.
 * Fixed some issues in the release/build.gradle script, which now allows to 
interactively specify the PGP key when calling the "gradlew signStaging" task

The consequence of this is that we don't need anymore to deliver a "-deps.zip" 
bundle which was containing so far build-time binary dependencies.

[1]https://github.com/pderop/dm.enhanced


> Refactor DM bndtools/gradle project
> ---
>
> Key: FELIX-5937
> URL: https://issues.apache.org/jira/browse/FELIX-5937
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager, Dependency Manager Shell
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r12
>
>
> The DM gradle project structure has been enhanced (see [1]) and I'd like to 
> merge the enhancements in the felix trunk.
> Mainly:
>  * all build time binary dependencies are now downloaded from maven central 
> using the bndtools "aQute.bnd.repository.maven.provider.MavenBndRepository".
>  * The gradle wrapper is not commited anymore and is downloaded by the 
> "gradlew" scripts.
>  * Fixed some issues in the release/build.gradle script, which now allows to 
> interactively specify the PGP key when calling the "gradlew signStaging" task
> The consequence of this is that we don't need anymore to deliver a 
> "-deps.zip" bundle which was containing so far build-time binary dependencies.
> [1]https://github.com/pderop/dm.enhanced



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FELIX-5937) Refactor DM bndtools/gradle project

[Pierre De Rop (JIRA)]

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

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

> Refactor DM bndtools/gradle project
> ---
>
> Key: FELIX-5937
> URL: https://issues.apache.org/jira/browse/FELIX-5937
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager, Dependency Manager Shell
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r12
>
>
> The DM gradle project structure has been enhanced (see 
> [1][),|https://github.com/pderop/dm.enhanced),] and I'd like to merge the 
> enhancements in the felix trunk.
> Mainly:
>  * all build time binary dependencies are now downloaded from maven central 
> using the bndtools "aQute.bnd.repository.maven.provider.MavenBndRepository".
>  * The gradle wrapper is not commited anymore and is downloaded by the 
> "gradlew" scripts.
>  * Fixed some issues in the release/build.gradle script, which now allows to 
> interactively specify the PGP key when calling the "gradlew signStaging" task
> The consequence of this is that we don't need anymore to deliver a 
> "-deps.zip" bundle which was containing so far build-time binary dependencies.
> [1]https://github.com/pderop/dm.enhanced



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-5937) Refactor DM bndtools/gradle project

[Pierre De Rop (JIRA)]

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

Pierre De Rop updated FELIX-5937:
-
Affects Version/s: (was: org.apache.felix.dependencymanager-r12)

> Refactor DM bndtools/gradle project
> ---
>
> Key: FELIX-5937
> URL: https://issues.apache.org/jira/browse/FELIX-5937
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager, Dependency Manager Shell
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r12
>
>
> The DM gradle project structure has been enhanced (see 
> [1][),|https://github.com/pderop/dm.enhanced),] and I'd like to merge the 
> enhancements in the felix trunk.
> Mainly:
>  * all build time binary dependencies are now downloaded from maven central 
> using the bndtools "aQute.bnd.repository.maven.provider.MavenBndRepository".
>  * The gradle wrapper is not commited anymore and is downloaded by the 
> "gradlew" scripts.
>  * Fixed some issues in the release/build.gradle script, which now allows to 
> interactively specify the PGP key when calling the "gradlew signStaging" task
> The consequence of this is that we don't need anymore to deliver a 
> "-deps.zip" bundle which was containing so far build-time binary dependencies.
> [1]https://github.com/pderop/dm.enhanced



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-5937) Refactor DM bndtools/gradle project

[Pierre De Rop (JIRA)]

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

Pierre De Rop updated FELIX-5937:
-
Fix Version/s: org.apache.felix.dependencymanager-r12

> Refactor DM bndtools/gradle project
> ---
>
> Key: FELIX-5937
> URL: https://issues.apache.org/jira/browse/FELIX-5937
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager, Dependency Manager Shell
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r12
>
>
> The DM gradle project structure has been enhanced (see 
> [1][),|https://github.com/pderop/dm.enhanced),] and I'd like to merge the 
> enhancements in the felix trunk.
> Mainly:
>  * all build time binary dependencies are now downloaded from maven central 
> using the bndtools "aQute.bnd.repository.maven.provider.MavenBndRepository".
>  * The gradle wrapper is not commited anymore and is downloaded by the 
> "gradlew" scripts.
>  * Fixed some issues in the release/build.gradle script, which now allows to 
> interactively specify the PGP key when calling the "gradlew signStaging" task
> The consequence of this is that we don't need anymore to deliver a 
> "-deps.zip" bundle which was containing so far build-time binary dependencies.
> [1]https://github.com/pderop/dm.enhanced



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FELIX-5336) Add support for prototype scope services in DM4

[Pierre De Rop (JIRA)]

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

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

committed in revision 1842034.

> Add support for prototype scope services in DM4
> ---
>
> Key: FELIX-5336
> URL: https://issues.apache.org/jira/browse/FELIX-5336
> Project: Felix
>  Issue Type: New Feature
>  Components: Dependency Manager, Dependency Manager Annotations, 
> Dependency Manager Lambda, Dependency Manager Runtime
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r12
>
> Attachments: FELIX-5336.tgz
>
>
> In the users mailing list, there is a wish to add support in DM4 for OSGi 
> prototype scope services, which allows any service consumer to get its own 
> instance of a given service dependency.
> See http://www.mail-archive.com/users@felix.apache.org/msg17473.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FELIX-5939) DM annotations enhancements

[Pierre De Rop (JIRA)]

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

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

committed in revision 1842034.

> DM annotations enhancements
> ---
>
> Key: FELIX-5939
> URL: https://issues.apache.org/jira/browse/FELIX-5939
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager Annotations, Dependency Manager 
> Runtime
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r12
>
>
> Some DM annotations improvements have been done regarding DM Annotation in 
> this github project: [https://github.com/pderop/dm.enhanced,] and the intent 
> is to merge the improvements to the felix trunk.
> Essentially, the following DM annotations enhancements and modifications have 
> been done:
>  * in OSGi R7, declarative service now provides a @ComponentPropertyType 
> annotation that can be used to defined user defined property type 
> annotations. Now this annotation is used by other R7 libraries, like jaxrs 
> whiteboard R7 API. So the DM annotation scanner has been enhanced for the 
> support of the DS @ComponentPropertyType, allowing you to reuse user defined 
> annotations from other r7 libraries (whiteboad, etc ...). The dm annotation 
> plugin has been enhanced by reusing some part of the ds annotation scanner 
> from bndlib, which is full of reusable useful code which has been applied to 
> dm (scanning of property types, PREFIX_, etc ...). For consistency api 
> reasons, a new @PropertyType annotation has also been added to the DM 
> annotation API: this annotation has the same semantics has the DS 
> @ComponentPropertyType annotations.
>  * allow ServiceDependency to auto detect the service type when the 
> annotation is applied on a collection class field
>  * removed FactoryComponentAdapterService (some attributes have been added in 
> the Component annotation in order to declare factory pid components with the 
> @Component annotation)
>  * removed some old annotations / attributes. The attributes and annotations 
> related to metatype have been removed since you can now use the standard 
> metatype annotations. if users need to use old version, then the previous old 
> 4.2.1 annotations can be used, because the dm runtime is compatible with old 
> and new annotations version.
>  * removed "dereference" attribute in ServiceDependencyAnnotation, because we 
> can now infer if the service dependency callbacks accepts a ServiceReference 
> or a ServiceObjects parameter
> Since some incompatible changes have been made, the major version of the 
> annotation bundle has been bumped to 5.0.0.
> *User defined property types examples:*
> So far, you could define component service properties using DM @Property 
> annotation, and component configuration could be declared as user defined 
> interfaces. You can now declare user-defined annotations which can be used to 
> specify both service properties and component configuration. It means that 
> instead of declaring service properties using @Property annotation, you can 
> now use your own annotations (which must be annotated with the new 
> @PropertyType annotation, or using the standard @ComponentPropertyType 
> annotation.
> For example, let’s assume your write an OSGi r7 jaxrs servlet context which 
> needs the two following service properties:
> {code:java}
> osgi.http.whiteboard.context.name
> osgi.http.whiteboard.context.path
> {code}
> Then you can first define your own annotation (but you could also reuse the 
> default annotations provided by the new jaxrs whiteboard r7 api, from the 
> org.osgi.service.jaxrs.whiteboard.propertytypes package):
>  
> {code:java}
> import org.apache.felix.dependencymanager.annotation.PropertyType;
> @PropertyType
> @interface ServletContext {
> String osgi_http_whiteboard_context_name() default AppServletContext.NAME;
> String osgi_http_whiteboard_context_path();
> }
> {code}
> In the above, the underscore is mapped to ".", and you can apply the above 
> annotation on top of your component like this:
> {code:java}
>  @Component
>  @ServletContext(osgi_http_whiteboard_context_path="/game")
>  public class AppServletContext extends ServletContextHelper {
>  }
> {code}
> You can also use configuration admin service in order to override the default 
> service properties:
> {code:java}
>  @Component
>  @ServletContext(osgi_http_whiteboard_context_path="/game")
>  public class AppServletContext extends ServletContextHelper {
>     @ConfigurationDependency(propagate=true, pid="my.pid")
>     void updated(ServletContext cnf) {
>         // if some properties are not present in the configuration, then the 
> ones used in the
>         // annotation will be used.
>         // The

[jira] [Updated] (FELIX-5336) Add support for prototype scope services in DM4

[Pierre De Rop (JIRA)]

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

Pierre De Rop updated FELIX-5336:
-
Fix Version/s: org.apache.felix.dependencymanager-r12
   org.apache.felix.dependencymanager-r10

> Add support for prototype scope services in DM4
> ---
>
> Key: FELIX-5336
> URL: https://issues.apache.org/jira/browse/FELIX-5336
> Project: Felix
>  Issue Type: New Feature
>  Components: Dependency Manager, Dependency Manager Annotations, 
> Dependency Manager Lambda, Dependency Manager Runtime
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r12
>
> Attachments: FELIX-5336.tgz
>
>
> In the users mailing list, there is a wish to add support in DM4 for OSGi 
> prototype scope services, which allows any service consumer to get its own 
> instance of a given service dependency.
> See http://www.mail-archive.com/users@felix.apache.org/msg17473.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-5336) Add support for prototype scope services in DM4

[Pierre De Rop (JIRA)]

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

Pierre De Rop updated FELIX-5336:
-
Fix Version/s: (was: org.apache.felix.dependencymanager-r10)

> Add support for prototype scope services in DM4
> ---
>
> Key: FELIX-5336
> URL: https://issues.apache.org/jira/browse/FELIX-5336
> Project: Felix
>  Issue Type: New Feature
>  Components: Dependency Manager, Dependency Manager Annotations, 
> Dependency Manager Lambda, Dependency Manager Runtime
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Fix For: org.apache.felix.dependencymanager-r12
>
> Attachments: FELIX-5336.tgz
>
>
> In the users mailing list, there is a wish to add support in DM4 for OSGi 
> prototype scope services, which allows any service consumer to get its own 
> instance of a given service dependency.
> See http://www.mail-archive.com/users@felix.apache.org/msg17473.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[Pierre De Rop (JIRA)]

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

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

committed in revision 1842034.

> 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
> Fix For: org.apache.felix.dependencymanager-r12
>
>
> 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
(v7.6.3#76005)

[jira] [Commented] (FELIX-5937) Refactor DM bndtools/gradle project

[Pierre De Rop (JIRA)]

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

Pierre De Rop commented on FELIX-5937:
--

committed in revision 1842034.

> Refactor DM bndtools/gradle project
> ---
>
> Key: FELIX-5937
> URL: https://issues.apache.org/jira/browse/FELIX-5937
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager, Dependency Manager Shell
>Affects Versions: org.apache.felix.dependencymanager-r12
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
>
> The DM gradle project structure has been enhanced (see 
> [1][),|https://github.com/pderop/dm.enhanced),] and I'd like to merge the 
> enhancements in the felix trunk.
> Mainly:
>  * all build time binary dependencies are now downloaded from maven central 
> using the bndtools "aQute.bnd.repository.maven.provider.MavenBndRepository".
>  * The gradle wrapper is not commited anymore and is downloaded by the 
> "gradlew" scripts.
>  * Fixed some issues in the release/build.gradle script, which now allows to 
> interactively specify the PGP key when calling the "gradlew signStaging" task
> The consequence of this is that we don't need anymore to deliver a 
> "-deps.zip" bundle which was containing so far build-time binary dependencies.
> [1]https://github.com/pderop/dm.enhanced



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-5336) Add support for prototype scope services in DM4

[Pierre De Rop (JIRA)]

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

Pierre De Rop updated FELIX-5336:
-
Affects Version/s: (was: org.apache.felix.dependencymanager-r12)

> Add support for prototype scope services in DM4
> ---
>
> Key: FELIX-5336
> URL: https://issues.apache.org/jira/browse/FELIX-5336
> Project: Felix
>  Issue Type: New Feature
>  Components: Dependency Manager, Dependency Manager Annotations, 
> Dependency Manager Lambda, Dependency Manager Runtime
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
> Attachments: FELIX-5336.tgz
>
>
> In the users mailing list, there is a wish to add support in DM4 for OSGi 
> prototype scope services, which allows any service consumer to get its own 
> instance of a given service dependency.
> See http://www.mail-archive.com/users@felix.apache.org/msg17473.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FELIX-5941) DM APi enhancements

[Pierre De Rop (JIRA)]

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

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

committed in revision 1842034.

> DM APi enhancements
> ---
>
> Key: FELIX-5941
> URL: https://issues.apache.org/jira/browse/FELIX-5941
> Project: Felix
>  Issue Type: Improvement
>  Components: Dependency Manager
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Minor
> Fix For: org.apache.felix.dependencymanager-r12
>
>
> in [https://github.com/pderop/dm.enhanced,] some enhancements have been done 
> regarding the dm API, and the intent of this issue is to merge the 
> improvements into the felix trunk:
>  * the api to define aspects and adapters have been reworked (but dm API 
> remains {{backward compatible}})
>  * you can now declare multiple property type interfaces when using 
> Configuration Dependency or Factory Components (this was needed to implement 
> the enhancements for the annotations)
>  * configuration dependency using metatypes can now declare property types
>  * Allow to specify if propagated configuration dependencies must override 
> service service properties (it was not possible to override service 
> properties with propagated service properties so far)
>  * Added the following signatures in Component interface:
>  ** setInterface(Class serviceName, Dictionary properties)
>  ** setInterface(Class[] serviceNames, Dictionary properties)
> h3. *Aspect/Adapters Api enhancements*
> So far, aspects or adapters were defined using many methods from 
> DependencyManager or DependencyActivatorBase classes:
> For example, in DependencyManager.java, we currently have many signatures
> {code:java}
> public class DependencyManager {
> public Component createAdapterService(Class serviceInterface, String 
> serviceFilter) {...}
> public Component createAdapterService(Class serviceInterface, String 
> serviceFilter, String autoConfig) {...}
> public Component createAdapterService(Class serviceInterface, String 
> serviceFilter, String add, String change, String remove) {...}
> public Component createAdapterService(Class serviceInterface, String 
> serviceFilter, String add, String change, String remove, String swap) {...}
> public Component createAdapterService(Class serviceInterface, String 
> serviceFilter, String autoConfig, Object callbackInstance, String add, String 
> change, String remove, String swap, boolean propagate) {...}
> 
> public Component createFactoryConfigurationAdapterService(String 
> factoryPid, String update, boolean propagate) {...}
> public Component createFactoryConfigurationAdapterService(String 
> factoryPid, String update, boolean propagate, Object callbackInstance) {...}
> public Component createFactoryConfigurationAdapterService(String 
> factoryPid, String update, boolean propagate, Class configType) {...}
> public Component createFactoryConfigurationAdapterService(String 
> factoryPid, String update, boolean propagate, Object callbackInstance, 
> Class configType) {...}
> public Component createAdapterFactoryConfigurationService(String 
> factoryPid, String update, boolean propagate,String heading, String desc, 
> String localization, PropertyMetaData[] propertiesMetaData) {...}
> 
> public Component createBundleAdapterService(int bundleStateMask, String 
> bundleFilter, boolean propagate) {...}
> public Component createBundleAdapterService(int bundleStateMask, String 
> bundleFilter, boolean propagate, Object callbackInstance, String add, String 
> change, String remove) {...}
> 
> public Component createResourceAdapterService(String resourceFilter, 
> boolean propagate, Object callbackInstance, String callbackChanged) {...}
> public Component createResourceAdapterService(String resourceFilter, 
> boolean propagate, Object callbackInstance, String callbackSet, String 
> callbackChanged)
> public Component createResourceAdapterService(String resourceFilter, 
> Object propagateCallbackInstance, String propagateCallbackMethod, Object 
> callbackInstance, String callbackChanged) {...}
> public Component createResourceAdapterService(String resourceFilter, 
> Object propagateCallbackInstance, String propagateCallbackMethod, Object 
> callbackInstance, String callbackSet, String callbackChanged) {...}
> 
> public Component createAspectService(Class serviceInterface, String 
> serviceFilter, int ranking, String autoConfig) {...}
> public Component createAspectService(Class serviceInterface, String 
> serviceFilter, int ranking) {...}
> public Component createAspectService(Class serviceInterface, String 
> serviceFilter, int ranking, String add, String change, String remove) {...}
> public Component createAspectService(Class serv

[jira] [Resolved] (FELIX-5938) DM not working with latest Felix Framework

[Pierre De Rop (JIRA)]

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

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

committed in revision 1842034.

> DM not working with latest Felix Framework
> --
>
> Key: FELIX-5938
> URL: https://issues.apache.org/jira/browse/FELIX-5938
> Project: Felix
>  Issue Type: Bug
>  Components: Dependency Manager
>Reporter: Pierre De Rop
>Assignee: Pierre De Rop
>Priority: Major
>
> When using the latest Felix framework, DM is not resolved:
> {code:java}
> org.osgi.framework.BundleException: Unable to resolve 
> org.apache.felix.dependencymanager [5](R 5.0): missing requirement 
> [org.apache.felix.dependencymanager [5](R 5.0)] osgi.wiring.package; 
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.8.0)(!(version>=1.9.0)))
>  Unresolved requirements: [[org.apache.felix.dependencymanager [5](R 5.0)] 
> osgi.wiring.package; 
> (&(osgi.wiring.package=org.osgi.framework)(version>=1.8.0)(!(version>=1.9.0)))]{code}
> Surprisingly, bnd generates an odd import range and excludes the 1.9 version.
>  Fixing the DM bnd like this resolves the issue:
> {code:java}
> Import-Package: !org.junit,!org.mockito.*,org.osgi.framework;version="[1.8, 
> 2)",*
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5911) [Configurator] Too restrictive permissions.perm file

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5911:
-

{quote}[~timothyjward]: as far as I understand the set of permissions granted 
by the system admin/the person launching the framework can only be a subset of 
the permissions requested in the permissions.perm file. More precisely, the 
effective set of permissions is the intersection of the ones in 
permissions.perm and the ones granted by the admin. It is hence not possible to 
configure additional permissions. Did I get this wrong?
{quote}
 

You can still use PermissionAdmin/ConditionalPermissionAdmin to control the 
permissions of a bundle and grant them wider permissions than they would 
otherwise have. You are correct, however that the permissions for a bundle 
cannot expand beyond those of the Java runtime as a whole.

> [Configurator] Too restrictive permissions.perm file
> 
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5911) [Configurator] Too restrictive permissions.perm file

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on FELIX-5911:
-

I changed the title, I hope it fits better now.
For other things like the use of reflection we should create different issues

> [Configurator] Too restrictive permissions.perm file
> 
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (FELIX-5911) [Configurator] Too restrictive permissions.perm file

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved FELIX-5911.
-
Resolution: Fixed

Removed the file in rev 1842027

> [Configurator] Too restrictive permissions.perm file
> 
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-5911) [Configurator] Too restrictive permissions.perm file

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated FELIX-5911:

Summary: [Configurator] Too restrictive permissions.perm file  (was: 
[Configurator] request FilePermission <>)

> [Configurator] Too restrictive permissions.perm file
> 
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: osgicheck-maven-plugin and checkGreedyReferences()

[Raymond Auge]

I also agree with GREEDY as a general rule for any STATIC unary references.

On top of the reasons proposed by Carsten and David, what a developer often
overlooks is the "plugability" of the system.

Whenever you use OSGi services, the natural assumption is that the "best"
service will be used based on service ranking.

During deployment (and generally long after development) the first thought
is simply to change the default implementation with a service of higher
ranking. However, when code uses the default @Reference this becomes only
possible by applying a specific target filter for the reference.

You might need to replace only one service, but you have 20 @References
spread through the application requiring 20 unique configurations targeting
the custom implementation.

Had all the references been GREEDY, the system would have worked as
expected from the start.

NOTE that the OSGi EGs (Expert Groups) have expressed regret at not having
made @References GREEDY to begin with. To that end when developing the CDI
integration spec, OSGi CDI's @Reference IS GREEDY by default.

Sincerely,
- Ray

On Wed, Sep 26, 2018 at 2:40 AM David Jencks 
wrote:

> If you've bothered to set the service ranking, then in theory it matters
> which one you get :-)
>
> I like the default of preferring greedy in order to get reproducible
> results.  Configurable choices would be ok for experts :-)
>
> David Jencks
>
> > On Sep 25, 2018, at 11:14 PM, Carsten Ziegeler 
> wrote:
> >
> > As a general remark:
> >
> > I guess all current checks in that plugin are debatable. It currently
> > contains checks that we found useful. And I think we'll make them
> > configurable in a future version of the plugin.
> >
> > For this specific check, it's there to ensure a reproducible system
> > regardless of in which order bundles and services are started. Greedy
> > for single cardinality only matters if you have more than one service
> > registered for that reference. With greedy you always get the same (with
> > the highest service ranking). Without greedy you get one of them and
> > that can vary over time. Now in theory it shouldn't matter which one you
> > get, in practice it often does.
> >
> > Regards
> >
> > Carsten
> >
> >
> > David Jencks wrote
> >> I’m not quite sure exactly what you are asking, and I don’t know what
> policy preference this plugin thinks is a good idea but...
> >> If a static reference goes away, of course the component instance will
> get deactivated, and if there’s another suitable service available a new
> instance will get activated. This happens with both static and greedy
> policies.  With a greedy static reference, these will also trigger instance
> cycling:
> >> - single cardinality: a better match (service ranking) appearing.
> >> - multiple cardinality: more matches appearing.
> >>
> >> Unless you’ve set the minimum cardinality using config admin to the
> actual number of services, you probably want the greedy behavior for
> multiple cardinality references. The situation for single cardinality is
> more debatable.
> >>
> >> David Jencks
> >>
> >>
> >> Sent from my iPhone
> >>
> >>> On Sep 25, 2018, at 3:51 PM, Mark Derricutt <
> mark.derric...@smxemail.com> wrote:
> >>>
> >>> Hey all,
> >>>
> >>> A question on checkGreedyReferences() in the new
> osgicheck-maven-plugin, we got a lot of warnings about our static
> @Reference's needing to be greedy.
> >>>
> >>> From the ReferecePolicy.STATIC java doc:
> >>>
> >>> If a target service is available to replace the bound service which
> became unavailable, the component configuration must be reactivated and
> bound to the replacement service.
> >>>
> >>> Would this imply that regardless of the RELUCTANT/GREEDY setting, for
> a static @Reference I should see the new/updated service - and if so,
> should the warning only trigger for non static references?
> >>>
> >>> Mark
> >>>
> >>> "The ease with which a change can be implemented has no relevance at
> all to whether it is the right change for the (Java) Platform for all
> time." — Mark Reinhold.
> >>>
> >>> Mark Derricutt | Senior Developer
> >>> Phone: +64 9 302 0515 Fax: +64 9 302 0518
> >>> Mobile: +64 21 562 533 Freephone: 0800 SMX SMX (769 769)
> >>> Twitter: @talios
> >>> SMX Limited: Level 10, 19 Victoria Street West, Auckland, New Zealand
> >>> Web: http://smxemail.com
> >>>
> >>
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org 
>


-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

[jira] [Commented] (FELIX-5911) [Configurator] request FilePermission <>

[JIRA]

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

Christoph Nölle commented on FELIX-5911:


[~timothyjward]: you are right regarding the bundle storage location, it does 
not require a permission request. The original issue description is wrong, but 
the issues mentioned in the first two comments probably remain.

> [Configurator] request FilePermission <>
> ---
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5911) [Configurator] request FilePermission <>

[JIRA]

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

Christoph Nölle commented on FELIX-5911:


[~timothyjward]: as far as I understand the set of permissions granted by the 
system admin/the person launching the framework can only be a subset of the 
permissions requested in the permissions.perm file. More precisely, the 
effective set of permissions is the intersection of the ones in 
permissions.perm and the ones granted by the admin. It is hence not possible to 
configure additional permissions. Did I get this wrong?

> [Configurator] request FilePermission <>
> ---
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5911) [Configurator] request FilePermission <>

[Timothy Ward (JIRA)]

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

Timothy Ward commented on FELIX-5911:
-

This permission request seems wrong. By default the OSGi framework should grant 
access to the bundle storage area ([see the security section in the core 
specification 
title|[https://osgi.org/specification/osgi.core/7.0.0/framework.security.html#framework.security.impliedpermissions]).]
 I'm not sure why the bundle should need to request other file permissions at 
all.

 

I would also really like to see reflection removed as it really shouldn't be 
necessary. The bundle is in complete control of the serialization, so I'm not 
sure why it hasn't been written purely using DataInput/DataOutput. There aren't 
any cycles, and none of the default serialisation behaviour is in use. To my 
mind this could (and should) all be re-implemented without any need for 
reflection, even while maintaining backward compatibility with existing saved 
data.

 

Finally, the additional permissions needed when the "configurator.initial" 
property is set need to be granted by the person launching the framework. They 
know that they have set security on, and what they have sent the 
configurator.initial property to. The Configurator bundle shouldn't be opening 
up the base options for this.

> [Configurator] request FilePermission <>
> ---
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5911) [Configurator] request FilePermission <>

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on FELIX-5911:
-

[~cnoelle] Thanks for reporting, somehow I missed this one for the 1.0.6 
release :(
I agree, the best option is to remove the permissions.perm file as we really 
don't know what permissons are required

> [Configurator] request FilePermission <>
> ---
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-5911) [Configurator] request FilePermission <>

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated FELIX-5911:

Fix Version/s: configurator-1.0.8

> [Configurator] request FilePermission <>
> ---
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (FELIX-5911) [Configurator] request FilePermission <>

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned FELIX-5911:
---

Assignee: Carsten Ziegeler

> [Configurator] request FilePermission <>
> ---
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: configurator-1.0.8
>
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5911) [Configurator] request FilePermission <>

[JIRA]

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

Christoph Nölle commented on FELIX-5911:


What do you think, [~cziegeler]?

> [Configurator] request FilePermission <>
> ---
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Priority: Major
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-5911) [Configurator] request FilePermission <>

[JIRA]

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

Christoph Nölle updated FELIX-5911:
---
Affects Version/s: configurator-1.0.6

> [Configurator] request FilePermission <>
> ---
>
> Key: FELIX-5911
> URL: https://issues.apache.org/jira/browse/FELIX-5911
> Project: Felix
>  Issue Type: Bug
>  Components: Configurator
>Affects Versions: configurator-1.0.4, configurator-1.0.6
>Reporter: Christoph Nölle
>Priority: Major
>
> Configurator currently requests
> (java.io.FilePermission "-" "read,write,execute,delete")
> in its permissions.perm file (the "-" means all files and subfolders within 
> and below the current working dir). However, the bundle tries to access files 
> in the bundle storage area as well, whose location we cannot anticipate here. 
> It can be configured by means of a framework property, for instance. The 
> correct permission would be
> (java.io.FilePermission "<>" "read,write,execute,delete") 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (FELIX-5936) Metatype XML Namespace 1.4 not supported

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed FELIX-5936.
---

> Metatype XML Namespace 1.4 not supported
> 
>
> Key: FELIX-5936
> URL: https://issues.apache.org/jira/browse/FELIX-5936
> Project: Felix
>  Issue Type: Bug
>  Components: Metatype Service
>Affects Versions: metatype-1.2.0
>Reporter: Rakesh Kumar
>Assignee: Carsten Ziegeler
>Priority: Critical
> Fix For: metatype-1.2.2
>
>
> *org.apache.felix.metatype.MetaDataReader* throws exception if the namespace 
> in metatype xml is [http://www.osgi.org/xmlns/scr/v1.4.0]
> and corresponding metatype is not being generated in Felix Web console when I 
> deploy the bundle.
> Following code only checks namespaces till v1.3
> {code:java}
> private void checkMetatypeNamespace() throws IOException
> {
> final String namespace = this.parser.getNamespace();
> if (namespace != null && !"".equals(namespace.trim()))
> {
> if (!NAMESPACE_1_0.equals(namespace) && 
> !NAMESPACE_1_1.equals(namespace) && !NAMESPACE_1_2.equals(namespace) && 
> !NAMESPACE_1_3.equals(namespace))
> {
> throw new IOException("Unsupported Namespace: '" + namespace + 
> "'");
> }
> this.namespace = namespace;
> }
> }{code}
> this is the metatype generated by bnd-maven-plugin v4.0.0
> {code:java}
> 
> http://www.osgi.org/xmlns/metatype/v1.4.0"; 
> localization="OSGI-INF/l10n/com.adeptj.modules.jaxrs.resteasy.ResteasyConfig">
> 
>  description="Whether to show exception message in error response" 
> default="true"/>
> 
> 
> 
> 
>   
>  {code}
> IMHO, *Felix Metatype Service 1.2.0* is implementing the *OSGi Metatype 
> Service Specification Version 1.4* and therefore should not fail for 
> namespace v1.4.0
> Please look into this.
> Thanks,
> Rakesh



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[VOTE RESULT] Release Apache Felix Metatype 1.2.2

[Carsten Ziegeler]

The vote passes with five binding +1 votes from David Bosschaert,
Jean-Baptiste Onofré, Pierre De Rop, Raymond Auge, Carsten Ziegeler and
two non binding +1 votes from Tim Ward, Francois Papon.

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