Re: [osgi-dev] Best practices for providing configs in cloud setups?

[Mark Hoffmann via osgi-dev]

We use the Zookeeper together with the ConfigAdmin, to share 
configurations. With the configuration plugin of the config admin, you 
can substitute the configuration or extend it with information from an 
alternative source.


In Zookeeper you can have global, configurations or create 
configuration-nodes just for your OSGi-node.


Mark


Am 13.09.2018 um 14:30 schrieb Christian Schneider via osgi-dev:
I am looking into good ways to provide configuration to OSGi bundles 
for cloud setups.


So my prototypical application would be a self running jar created by 
bndtools. This is then packaged into a docker image that simply runs 
the jar. The docker image is then deployed using kubernetes. I got an 
example of such an application from my adaptto talk about felix 
systemready. See https://github.com/cschneider/osgi-example-systemready


This is all well as long as all your config is inside the application 
already or can be read using existing means like the hostnames 
provided by kubernetes. For many cases this is not enough though.


I can imagine to use env variables to override key/values of configs 
like provided by the old configurer by Peter. I just created an issue 
to look into this: https://issues.apache.org/jira/browse/FELIX-5924


There are other possible ways though. For example kubernetes allows to 
map configMaps to files which then could be fed into config admin. Did 
anyone try this and ideally maybe has an example?


Some interesting possible requirements:
- The config should be applied in a way that avoids oscillation of 
services. So ideally config should be applied in one step

- Secrets should be protected in some way
- Kubernetes seems to be able to reflect updates to configMaps in a 
live system. So this might be a case where we want to update config 
inside a running app even in the cloud.


So what are your ideas and approaches with applying configs to OSGi 
cloud applications?


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

Computer Scientist
http://www.adobe.com



___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev


--
Mark Hoffmann
M.A. Dipl.-Betriebswirt (FH)
Geschäftsführer

Tel:+49 3641 384 910 0
Mobil:  +49 175 701 2201
E-Mail: m.hoffm...@data-in-motion.biz
Web: www.datainmotion.de

Data In Motion Consulting GmbH
Kahlaische Straße 4
07745 Jena

Geschäftsführer
Mark Hoffmann
Jürgen Albert

Jena HRB 513025
Steuernummer 162/107/05779
USt-Id DE310002614


___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Best practices for providing configs in cloud setups?

[Raymond Auge via osgi-dev]

I thought this is exactly what the new Configurator Specification [1] is
all about.

- Ray

[1] https://osgi.org/specification/osgi.cmpn/7.0.0/service.configurator.html


On Thu, Sep 13, 2018 at 8:30 AM, Christian Schneider <
ch...@die-schneider.net> wrote:

> I am looking into good ways to provide configuration to OSGi bundles for
> cloud setups.
>
> So my prototypical application would be a self running jar created by
> bndtools. This is then packaged into a docker image that simply runs the
> jar. The docker image is then deployed using kubernetes. I got an example
> of such an application from my adaptto talk about felix systemready. See
> https://github.com/cschneider/osgi-example-systemready
>
> This is all well as long as all your config is inside the application
> already or can be read using existing means like the hostnames provided by
> kubernetes. For many cases this is not enough though.
>
> I can imagine to use env variables to override key/values of configs like
> provided by the old configurer by Peter. I just created an issue to look
> into this: https://issues.apache.org/jira/browse/FELIX-5924
>
> There are other possible ways though. For example kubernetes allows to map
> configMaps to files which then could be fed into config admin. Did anyone
> try this and ideally maybe has an example?
>
> Some interesting possible requirements:
> - The config should be applied in a way that avoids oscillation of
> services. So ideally config should be applied in one step
> - Secrets should be protected in some way
> - Kubernetes seems to be able to reflect updates to configMaps in a live
> system. So this might be a case where we want to update config inside a
> running app even in the cloud.
>
> So what are your ideas and approaches with applying configs to OSGi cloud
> applications?
>
> Christian
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

[osgi-dev] Best practices for providing configs in cloud setups?

[Christian Schneider via osgi-dev]

I am looking into good ways to provide configuration to OSGi bundles for
cloud setups.

So my prototypical application would be a self running jar created by
bndtools. This is then packaged into a docker image that simply runs the
jar. The docker image is then deployed using kubernetes. I got an example
of such an application from my adaptto talk about felix systemready. See
https://github.com/cschneider/osgi-example-systemready

This is all well as long as all your config is inside the application
already or can be read using existing means like the hostnames provided by
kubernetes. For many cases this is not enough though.

I can imagine to use env variables to override key/values of configs like
provided by the old configurer by Peter. I just created an issue to look
into this: https://issues.apache.org/jira/browse/FELIX-5924

There are other possible ways though. For example kubernetes allows to map
configMaps to files which then could be fed into config admin. Did anyone
try this and ideally maybe has an example?

Some interesting possible requirements:
- The config should be applied in a way that avoids oscillation of
services. So ideally config should be applied in one step
- Secrets should be protected in some way
- Kubernetes seems to be able to reflect updates to configMaps in a live
system. So this might be a case where we want to update config inside a
running app even in the cloud.

So what are your ideas and approaches with applying configs to OSGi cloud
applications?

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

Computer Scientist
http://www.adobe.com
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] How can I reuse servlet filter across bundles

[Raymond Auge via osgi-dev]

Thai, what you described sounds like a bug in the http whiteboard
implementation. Which do you use and could you file a bug against it?

- Ray

On Wed, Sep 12, 2018, 17:38 Nhut Thai Le,  wrote:

> Thank you Raymond,
>
> I called the  HttpServiceRuntim.calculateRequestInfoDTO("/token") inside
> my servlet and i see my filter listed as filterDTOs:
> {"path":"/token", "servletContextId":125,
> "filterDTOs":[{"name":"AuthenticationFilter", "patterns":["/*"],
> "servletNames":null, "regexs":null, "asyncSupported":false,
> "dispatcher":[], "initParams":{"component.id":"33", 
> "component.name":"com.casto...ionFilter",
> "service.id":"117", "objectClass":"[Ljava.la...@5891e480",
> "filterRank":"10", "service.scope":"prototype",
> "osgi.http.whiteboard.filter.pattern":"/*", "
> osgi.http.whiteboard.filter.name":"AuthenticationFilter",
> "osgi.http.whiteboard.context.select":"(osgi.htt...xtHelper)",
> "service.ranking":"10", "service.bundleid":"136"}, "serviceId":117,
> "servletContextId":125}], "servletDTO":{"patterns":["/token"], "name":null,
> "servletInfo":"", "asyncSupported":false, "initParams":{},
> "servletContextId":125, "serviceId":127}, "resourceDTO":null}
>
> However, the filter is still not triggered. If i manually create a
> ServletContextHelper and add "osgi.http.whiteboard.context.select=(
> osgi.http.whiteboard.context.name=SharedServletContextHelper)" to both
> the filter and the servlet then i can see the filter kick in before the
> request hit the servlet. So I think shared servlet context is required to
> have the filters works across bundles. My concern is that i cannot use the
> SharedServletContextHelper on the resource service because it will not see
> the icons folder in my bundle. Here is the debug log if i use the
> SharedServletContextHelper with the resource service:
>
> [qtp345379538-59] DEBUG org.eclipse.jetty.servlet.ServletHandler - servlet
> |/static/icons|/bundle1.png -> /static/icons/*:/icons@d606ba18
> ==org.ops4j.pax.web.service.jetty.internal.ResourceServlet,jsp=null,order=-1,inst=true
> [qtp345379538-59] DEBUG
> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext - Handling
> request for [/static/icons/bundle1.png] using http context
> [org.ops4j.pax.web.extender.whiteboard.internal.WebApplication$1@1b9ac962]
> [qtp345379538-59] DEBUG
> org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler -
> handling request
> org.ops4j.pax.web.service.jetty.internal.HttpServiceRequestWrapper@5b1bfc6,
> org.ops4j.pax.web.service.jetty.internal.HttpServiceResponseWrapper@b765100
> [qtp345379538-59] DEBUG org.eclipse.jetty.servlet.ServletHandler -
> chain=org.ops4j.pax.web.service.spi.model.FilterModel-13->/static/icons/*:/icons@d606ba18
> ==org.ops4j.pax.web.service.jetty.internal.ResourceServlet,jsp=null,order=-1,inst=true
> [qtp345379538-59] DEBUG org.eclipse.jetty.servlet.ServletHandler - call
> filter org.ops4j.pax.web.service.spi.model.FilterModel-13
> [qtp345379538-59] DEBUG org.eclipse.jetty.servlet.ServletHandler - call
> servlet 
> /static/icons/*:/icons@d606ba18==org.ops4j.pax.web.service.jetty.internal.ResourceServlet,jsp=null,order=-1,inst=true
>  [qtp345379538-59] DEBUG org.eclipse.jetty.servlet.ErrorPageErrorHandler -
> getErrorPage(GET /static/icons/bundle1.png) => error_page=null (from global
> default)
>
> So now the question really is how to hook my servlet filter to a resource
> service.
>
> Thai
>
> On Wed, Sep 12, 2018 at 3:01 PM, Raymond Auge 
> wrote:
>
>> Hello Thai,
>>
>> I don't see anything wrong.
>>
>> It looks like they all "target" the default "ServletContextHelper" (i.e.
>> the same context) and so the filter should apply to each.
>>
>> You should be able to check by getting the HttpServiceRuntime [1] service
>> and calling the method `calculateRequestInfoDTO(String path)` to see what
>> the runtime thinks is wired up for that path.
>>
>> Sincerely,
>> - Ray
>>
>> [1]
>> https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#org.osgi.service.http.runtime.HttpServiceRuntime
>>
>> On Wed, Sep 12, 2018 at 2:39 PM, Nhut Thai Le via osgi-dev <
>> osgi-dev@mail.osgi.org> wrote:
>>
>>> Hello,
>>>
>>> I want to have a filter at the root of my application where all http
>>> requests must pass through, so I make a Servlet filter:
>>> @Component(
>>> service=Filter.class,
>>> scope=ServiceScope.PROTOTYPE,
>>> property= {
>>> "osgi.http.whiteboard.filter.name=AuthenticationFilter",
>>> "osgi.http.whiteboard.filter.pattern=/*",
>>> "service.ranking:Integer=10"
>>> }
>>> )
>>> public final class AuthenticationFilter implements Filter {...}
>>> -
>>> Then I have some servlets (in other bundles) defined like this:
>>> @Component(
>>> service = Servlet.class,
>>> property= {
>>> "osgi.http.whiteboard.servlet.pattern=/token"
>>> }
>>> )
>>> public class AccessTokenServlet extends HttpServlet{...}
>>> ---
>>> I also have some resource services in other bundles:
>>>