Arnaud, I have a sample of how to do it in an earlier post. On Fri, Sep 25, 2015, 8:26 AM Arnaud Deprez <[email protected]> wrote:
> Thanks for your answers guys and glad to have some news of your Christian > (It's been a while since Worldline). > > So for example, what I'd like to share is endpoint url. For the database > it's very easy to expose a datasource as a service. > > So to give you the picture, I'm designing an API gateway in front of > multiple backends (I can't say Micro Services right now because it's not as > micro as it's supposed to be right now). > The goal of this API is to be the gateway for third party application. > My design choices was to split my APIs and my Implementations by business > context. > The thing is that for different context, I've to reach the same backend > right now. > > So let's say this backend as the following context-path url : > http://example.com/api > In one bundle I need to call http://example.com/api/customers and in > another one http://example.com/api/contracts > <http://example.com/api/contacts>. > My first idea was to have a environment PID configuration which contains > "backend.base.url = http://example.com/api"; and in each bundles > "customers.url = ${backend.base.url}/customers" and "contracts.url = > ${backend.base.url}/contracts". > I know that it's possible to merge properties like that but only in the > same configuration PID. > The advantage with this solution is that if they decided to split their > backend into one for customer and one for backend (and if they keep the > same API), I can just update my properties customers.url and contracts.url. > > As it doesn't seem to be possible, I think creating proxies for those > service is the best design choice right now but it's a bit over work when I > can simply the http4 camel component. > > Regards, > > Arnaud > > On Fri, Sep 25, 2015 at 1:20 PM Christian Schneider < > [email protected]> wrote: > >> I have seen a similar thing at a customer. They also used a db as config >> backend. >> Typically the config is then represented inside the service as either >> service.getProperty(key) or service.getConfig as a java bean class. >> The problem is that such a solution typically does not provide a way to >> push the config to the blueprint beans. You have to actively get it from >> the service. >> >> One way to solve this is to create a custom blueprint namespace and >> create your own property placeholder support there. This is pretty advanced >> stuff though, so I would not recommend it for every case. >> >> What I found is that there are typically two kinds of configs you want to >> share: >> 1. Database properties >> 2. Service endpoint URLs so you know what URL to use in a client per >> Environment >> >> These can also be solved differently though. >> 1. Use pax-jdbc-config to configure the DataSource in one config. Then >> share the DataSource service between bundles instead of the config >> 2. You can create client proxies that offer an OSGi service to the inside >> and do the e.g. Rest call in one central place per service. So there is >> again just one place to configure. Alternatively OSGi Remote Services can >> provide this in a general way >> >> There are also some similar things like e.g. mail server configs if you >> need to send mails. Again the solution is to create a central mail service >> that abstracts from the details and is configured in one place. Such >> services do not only solve the config problem but also make your modules >> more loosely coupled to the technologies used. >> >> >> Christian >> >> >> >> >> On 25.09.2015 12:45, Kevin Carr wrote: >> >> Christian we use a shared config for each "environment". So bundles know >> certain entries will be available in dev qa and prod. >> >> We also have a gui over the db to make it easier for us to update said >> properties. >> >> On Fri, Sep 25, 2015, 5:43 AM Christian Schneider < >> [email protected]> wrote: >> >>> You should also look into your architecture to see why you need to share >>> some config. In some cases you >>> can extract the commonalities into a service that can then be regularly >>> configured by config admin. >>> >>> Can you explain a bit what kind of configuration you need to share >>> between bundles? >>> >>> Christian >>> >>> >>> On 25.09.2015 12:33, Arnaud Deprez wrote: >>> >>> Hi, >>> >>> @JP: The problem is not using 2 property placeholder, but sharing one >>> property placeholder across multiple bundles. And in that case, it seems >>> that we have to avoid it because it can cause trouble to the Config Admin >>> due to concurrency issues (it's actually what I read, I didn't take a look >>> to the code). >>> >>> @Christian: Thanks for your answer. I actually had the same idea but I'm >>> a guy who is looking for icing by using Config Admin with its dynamical >>> behavior :-). But if there is no other solution, I'll go to that direction. >>> >>> On Fri, Sep 25, 2015 at 11:34 AM Christian Schneider < >>> [email protected]> wrote: >>> >>>> You can use the <ext:property-placeholder placeholder-prefix="$[" >>>> placeholder-suffix="]"/> >>>> It allows access to the System.properties and use it for shared config. >>>> See: >>>> https://github.com/apache/karaf/blob/karaf-3.0.x/bundle/core/src/main/resources/OSGI-INF/blueprint/blueprint.xml >>>> >>>> It can be used together with a cm:property-placeholder that contains >>>> bundle specific config from config admin. >>>> >>>> One problem is that the System properties do not support updates in >>>> case of changes. So you can only use it for relatively fixed configs. >>>> >>>> >>>> Christian >>>> >>>> >>> -- >>> Christian Schneiderhttp://www.liquid-reality.de >>> >>> Open Source Architecthttp://www.talend.com >>> >>> >> >> -- >> Christian Schneiderhttp://www.liquid-reality.de >> >> Open Source Architecthttp://www.talend.com >> >>
