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 > >
