[jira] [Resolved] (FELIX-5262) Broken link for FAQ page on maven-bundle-plugin doc page

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved FELIX-5262.
-
Resolution: Fixed

> Broken link for FAQ page on maven-bundle-plugin doc page
> 
>
> Key: FELIX-5262
> URL: https://issues.apache.org/jira/browse/FELIX-5262
> Project: Felix
>  Issue Type: Bug
>Reporter: David M. Karr
>
> The URL with the bad link is 
> http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html
>  .
> The text containing the bad link is here:
> 
> If you have questions about the maven-bundle-plugin please read the FAQ 
> first. If you still have questions you can ask them on the Felix user list.
> -
> The link is on "FAQ", and it currently goes to 
> "http://felix.apache.org/site/apache-felix-bundle-plugin-faq.html;, which 
> gets the 404.



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

[jira] [Created] (FELIX-5275) Felix & Equinox handling of OSGI-INF/permissions.perm differs

[Derek Baum (JIRA)]

Derek Baum created FELIX-5275:
-

 Summary: Felix & Equinox handling of OSGI-INF/permissions.perm 
differs
 Key: FELIX-5275
 URL: https://issues.apache.org/jira/browse/FELIX-5275
 Project: Felix
  Issue Type: Bug
  Components: Configuration Admin, Framework Security
Affects Versions: configadmin-1.8.8
 Environment: Felix config-admin 1.8.8 running on Equinox with 
SecurityManager
Reporter: Derek Baum


Using Felix config-admin 1.8.8 in Equinox, with a SecurityManager active, 
causes the ManagedService.updated() method to get AccessControlExceptions when, 
for example, accessing System properties.

This is caused by:

#1 OSGI-INF/permissions.perm added to config-admin in FELIX-4039

#2 Different handling of OSGI-INF/permissions.perm between Felix and Equinox.

I have previously raised this problem against Equinox (see External Issue URL), 
and this is the gist of their analysis:

---
The felix CM implementation is scoping their own permissions down to a strict 
subset of permissions and Equinox is correctly enforcing that subset of 
permissions.

So your bundle tries to read a system property, but the CM impl is not 
authorized to read that property.

One complication may be that Felix is allowing its bundle protection domains to 
be configured with the java policy file (because their ProtectionDomains are 
constructed with that 4 arg constructor).

This would seem to break the specified behavior though, because clearly the CM 
implementation should never be allowed to have permission to do things outside 
of what is specified by the permissions.perm file or that are "implied" 
permissions auto-granted by the framework for each bundle.
---




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

Re: Extender for default configs as felix project?

[Carsten Ziegeler]

Christian Schneider wrote
> Hi Carsten,
> 
> Peter also told me your are working on the spec. Sounds great. I am willing
> to help with it.
> In the mean time Peter releases the enroute bundles to maven central so I
> can use these for the time being.
> 
> Btw. Peter and I had the idea to have a small meeting on the 28th of june
> while the expert groups are in Darmstadt. I will try to organize this.
> 
Sounds great!

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

Re: Extender for default configs as felix project?

[Christian Schneider]

Hi Carsten,

Peter also told me your are working on the spec. Sounds great. I am willing
to help with it.
In the mean time Peter releases the enroute bundles to maven central so I
can use these for the time being.

Btw. Peter and I had the idea to have a small meeting on the 28th of june
while the expert groups are in Darmstadt. I will try to organize this.

Christian


2016-06-03 13:17 GMT+02:00 Carsten Ziegeler :

> Jean-baptiste Onofré wrote
> > Hi Carsten,
> >
> > thanks for the update. Maybe Christian and I can help there ?
> >
>
> Thanks! Sure, any help is welcome. We have an expert group F2F meeting
> by the end of the month. I plan to add my code soon after that, does
> that work for you?
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>



-- 
-- 
Christian Schneider
http://www.liquid-reality.de


Open Source Architect
http://www.talend.com

Re: Extender for default configs as felix project?

[Carsten Ziegeler]

Jean-baptiste Onofré wrote
> Hi Carsten,
> 
> thanks for the update. Maybe Christian and I can help there ?
> 

Thanks! Sure, any help is welcome. We have an expert group F2F meeting
by the end of the month. I plan to add my code soon after that, does
that work for you?

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

Re: Extender for default configs as felix project?

[Jean-Baptiste Onofré]

Hi Carsten,

thanks for the update. Maybe Christian and I can help there ?

Regards
JB

On 06/03/2016 12:59 PM, Carsten Ziegeler wrote:

Christian Schneider wrote

I would also like to propose a way to provide default configs.

Like described below enroute provides a way to define default configs as
files in a bundle. This is implemented using an extender.
See
https://github.com/osgi/osgi.enroute.bundles/tree/master/osgi.enroute.configurer.simple.provider


I think such an extender would also make sense as a felix project. If
there generally is interest in it I will provide a prototype.
We could also implement the override behaviour in this extender.

I will also contact Peter if he is interested to move the enroute code
for the extender into a felix project. I think it could make sense to
have helper bundles like this
maintained by a community.



We have picked up Peter's idee and are working on an official spec for
this (I think it's RFC 218, named Configurator). I'm currently working
on an implementation and as soon as the RFC is stable (which it should
be in some weeks), I plan to contribute my implementation to Apache Felix.

Regards
Carsten




--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Extender for default configs as felix project?

[Carsten Ziegeler]

Christian Schneider wrote
> I would also like to propose a way to provide default configs.
> 
> Like described below enroute provides a way to define default configs as
> files in a bundle. This is implemented using an extender.
> See
> https://github.com/osgi/osgi.enroute.bundles/tree/master/osgi.enroute.configurer.simple.provider
> 
> 
> I think such an extender would also make sense as a felix project. If
> there generally is interest in it I will provide a prototype.
> We could also implement the override behaviour in this extender.
> 
> I will also contact Peter if he is interested to move the enroute code
> for the extender into a felix project. I think it could make sense to
> have helper bundles like this
> maintained by a community.
> 

We have picked up Peter's idee and are working on an official spec for
this (I think it's RFC 218, named Configurator). I'm currently working
on an implementation and as soon as the RFC is stable (which it should
be in some weeks), I plan to contribute my implementation to Apache Felix.

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

[jira] [Closed] (FELIX-4941) Configuration Properties not defined in Metatype are lost after update

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed FELIX-4941.
---

> Configuration Properties not defined in Metatype are lost after update
> --
>
> Key: FELIX-4941
> URL: https://issues.apache.org/jira/browse/FELIX-4941
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-4.2.8, webconsole-4.2.14
>Reporter: Cliff Collins
>Assignee: Carsten Ziegeler
> Fix For: webconsole-4.2.16
>
>
> Web console when updating items that have metadata will only update the 
> properties defines in metadata.
> This means, the fileinstall file location is removed from the property 
> update. This makes so fileinstall will no longer update the configuration
> file with the change. A simple workaround is to always post back the 
> fileinstall property if present. 
> In the ConfigAdminSupport.java file added these lines. In the method 
> applyConfiguration at line 312, insert these lines:
> // Add Fileinstall key or the property will not get written back 
> to the configuration
> if (props.get("felix.fileinstall.filename") != null)
> {
> updateProps.put("felix.fileinstall.filename", 
> props.get("felix.fileinstall.filename"));
> }
> If you return the fileinstall filename then fileinstall will save any 
> property changes.



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

[jira] [Closed] (FELIX-4795) Servlet API 3.x not supported

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed FELIX-4795.
---

> Servlet API 3.x not supported
> -
>
> Key: FELIX-4795
> URL: https://issues.apache.org/jira/browse/FELIX-4795
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-4.2.6
>Reporter: Tuomas Kiviaho
>Assignee: Carsten Ziegeler
>Priority: Blocker
> Fix For: webconsole-4.2.16
>
>
> It seems that webconsole along it's plugins import  
> javax.servlet.*;version=2.4 version only. Newest Pax Web for instance uses 
> 3.x and thus these bundles do not resolve.
> As a solution I propose opening up the version range as per
> [http://blog.osgi.org/2014/09/portable-java-contracts-for-javax.html] 
> {code}
> Require-Capability: osgi.contract; 
> filter:="(&(osgi.contract=JavaServlet)(version>=2.4))",
> Import-Package: javax.servlet, javax.servlet.http 
> {code}
> PS. 
> [webconsole-4.2.6-all.jar|http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.felix%22%20AND%20a%3A%22org.apache.felix.webconsole%22]
>  isn't available in the maven repo, but I assume it would have still this 
> same "defect" as the previous ones.



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

[jira] [Closed] (FELIX-5223) [IE11][Edge]: Fields in OSGI Configuration Manager are not editable

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler closed FELIX-5223.
---

> [IE11][Edge]: Fields in OSGI Configuration Manager are not editable
> ---
>
> Key: FELIX-5223
> URL: https://issues.apache.org/jira/browse/FELIX-5223
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-4.2.8, webconsole-4.2.14
>Reporter: Ana Vinatoru
>Assignee: Carsten Ziegeler
> Fix For: webconsole-4.2.16
>
> Attachments: FELIX-5223_2.diff, Screen Shot 2016-03-23 at 
> 17.30.21.png, Screen Shot 2016-03-24 at 17.34.51_with_paddings.png
>
>
> Access the configuration manager (/system/console/configMgr) using IE11 or 
> Microsoft Edge.
> Find a configuration that allows the user to input text inside a textfield. 
> The content of these fields is not visible or editable because the height of 
> the field is set to 0px. 
> Investigation seems to point to a malfunction of the autosize JS library, as 
> this line in config.js set the height to 0:
> +$(textareaEl).autosize(); 
> A possible solution would be to set a min-height on the textfields, if the 
> issue in the library isn't fixed.



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

Re: Config admin for apps deployed using docker

[Paul Bakker]

Hi Christian,

Environment variables are indeed the way to go. Using for example Amdatu 
Configurator (http://amdatu.org/components/configurator.html 
) you can create property files 
(or metatype xml) that contain variables. For example:

mykey=${some_env_var}

Variables are replaced by environment variables. So with the example above you 
could pass in an override "docker run -e some_env_var=somevalue ..." 

Cheers,

Paul


> On 03 Jun 2016, at 10:33, Christian Schneider  wrote:
> 
> I am currently looking into making OSGi projects deployable as docker images.
> 
> For the plain deployment I already found some good solutions:
> - bndtools allows to package an application as a self contained jar. This can 
> then be put into a docker image
> - A karaf custom distro can also be packaged as a docker image nicely. The 
> static profile allows to even omit the feature service
> 
> In both solutions though configuration is not nicely supported in a style 
> suitable for docker.
> 
> It is of course easy to supply config for karaf by putting configs into the 
> etc dir when doing the custom distro. The problem is only how to allow 
> overrides from the docker side.
> Bndtools or more precisely enroute allows to define default configs as magic 
> property files in a bundle and can use an extender to apply these.
> 
> The typical approach in docker and docker compose seems to be to use env 
> variables and system properties.
> I wonder if we could support that better by allowing to override any config 
> admin config.
> 
> For an env var or system property something like this might do:
> cm::=value
> 
> So the files could contain the defaults and env and system properties could 
> override them. Does that make sense? Do we already have other options that I 
> am missing?
> 
> Christian
> 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Open Source Architect
> http://www.talend.com
> 

Config admin for apps deployed using docker

[Christian Schneider]

I am currently looking into making OSGi projects deployable as docker 
images.


For the plain deployment I already found some good solutions:
- bndtools allows to package an application as a self contained jar. 
This can then be put into a docker image
- A karaf custom distro can also be packaged as a docker image nicely. 
The static profile allows to even omit the feature service


In both solutions though configuration is not nicely supported in a 
style suitable for docker.


It is of course easy to supply config for karaf by putting configs into 
the etc dir when doing the custom distro. The problem is only how to 
allow overrides from the docker side.
Bndtools or more precisely enroute allows to define default configs as 
magic property files in a bundle and can use an extender to apply these.


The typical approach in docker and docker compose seems to be to use env 
variables and system properties.
I wonder if we could support that better by allowing to override any 
config admin config.


For an env var or system property something like this might do:
cm::=value

So the files could contain the defaults and env and system properties 
could override them. Does that make sense? Do we already have other 
options that I am missing?


Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[VOTE RESULT] Release Apache Felix WebConsole 4.2.16

[Carsten Ziegeler]

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

Extender for default configs as felix project?

[Christian Schneider]

I would also like to propose a way to provide default configs.

Like described below enroute provides a way to define default configs as 
files in a bundle. This is implemented using an extender.
See 
https://github.com/osgi/osgi.enroute.bundles/tree/master/osgi.enroute.configurer.simple.provider


I think such an extender would also make sense as a felix project. If 
there generally is interest in it I will provide a prototype.

We could also implement the override behaviour in this extender.

I will also contact Peter if he is interested to move the enroute code 
for the extender into a felix project. I think it could make sense to 
have helper bundles like this

maintained by a community.

Christian

On 03.06.2016 10:33, Christian Schneider wrote:
I am currently looking into making OSGi projects deployable as docker 
images.


For the plain deployment I already found some good solutions:
- bndtools allows to package an application as a self contained jar. 
This can then be put into a docker image
- A karaf custom distro can also be packaged as a docker image nicely. 
The static profile allows to even omit the feature service


In both solutions though configuration is not nicely supported in a 
style suitable for docker.


It is of course easy to supply config for karaf by putting configs 
into the etc dir when doing the custom distro. The problem is only how 
to allow overrides from the docker side.
Bndtools or more precisely enroute allows to define default configs as 
magic property files in a bundle and can use an extender to apply these.


The typical approach in docker and docker compose seems to be to use 
env variables and system properties.
I wonder if we could support that better by allowing to override any 
config admin config.


For an env var or system property something like this might do:
cm::=value

So the files could contain the defaults and env and system properties 
could override them. Does that make sense? Do we already have other 
options that I am missing?


Christian




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Release Apache Felix WebConsole 4.2.16

[Pierre De Rop]

+1

regards
/Pierre

On Fri, Jun 3, 2016 at 10:04 AM, Clement Escoffier <
clement.escoff...@gmail.com> wrote:

> +1,
>
> Regards,
>
> Clement
>
> > On 3 juin 2016, at 10:03, Carsten Ziegeler  wrote:
> >
> > We still need one binding vote, anyone?
> >
> > Thanks
> >
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
>
>

Re: [VOTE] Release Apache Felix WebConsole 4.2.16

[Clement Escoffier]

+1,

Regards,

Clement 

> On 3 juin 2016, at 10:03, Carsten Ziegeler  wrote:
> 
> We still need one binding vote, anyone?
> 
> Thanks
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix WebConsole 4.2.16

[Carsten Ziegeler]

We still need one binding vote, anyone?

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