How to file service in org.apache.karaf.shell.api.action.lifecycle.Reference

Hi All, "@Reference" annotation can be used to inject a service in to a custom karaf command but apparently it doesn't provide any option to filter the services. Should you the old style (blueprint) or that is not supported in karaf 4.0.x anymore? Cheers,

Repeated resource lookups?

I have a web bundle that does a forward to a jsp after performing a query. I turned on DEBUG while putting this together and noticed that the following group of 5 log statements were repeated a total of 6 times over a period of about 30 milliseconds. If it's accurate, it would seem that somethi

CXF feature question

Hi Karaf types, I’m using Karaf 3.0.1 and the cxf-jaxrs feature for this project where I need a very simple endpoint. Trying to configure with according to http://cxf.apache.org/docs/jaxrs-services-configuration.html#JAXRSServicesConfiguration-Spring

Customize Generated `startup.properties`

Hi everyone, third–and hopefully last–question for today is about the startup.properties. When reviewing the patch that introduces Karaf in our project, I noticed that it was not using the latest 3.x version of Karaf. When I tried to upgrade that, it failed because it was shipping a custom startup.

Configure Karaf Maven Plugin

Hi everyone, I found in the (deprecated old style) Maven assembly docs [1] that is is possible to define things like the output archive format and what to package as start scripts. At least it seems like that. Is there any kind of documentation for configuring the Karaf Maven Plugin? I am especial

Karaf Default Features Question

Hi everyone, I am from Opencast. We are currently in the process of switching to Apache Karaf and I am tasked with reviewing the patches which do that transition. The problem: They currently leave me with some open questions I now bring to you ;) The first question is that we are using the Karaf M

Re: Best practices : Configuration shared between bundles

Indeed I didn't read well your lastname ;-). You are right I actually use OSGi service to expose that service but in my implementation I use camel (with ProducerTemplate and some route if needed). It allows me to easily change the technology stack if needed (for example netty, jetty, restlet, spar

Re: Best practices : Configuration shared between bundles

Hi Arnaud, I guess your mean Christian Müller who I know worked at Worldline some time ago. That is not me .. though we both are active in the Camel project which already led to some confusions :-) I think I would skip sharing the common prefix and simply have one config per service you call

Re: Best practices : Configuration shared between bundles

Arnaud, I have a sample of how to do it in an earlier post. On Fri, Sep 25, 2015, 8:26 AM Arnaud Deprez 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 d

Re: Best practices : Configuration shared between bundles

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 f

Re: Best practices : Configuration shared between bundles

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

Re: Best practices : Configuration shared between bundles

I have created a quick (Really quick wrote it in about 30 minutes, so be gentle. ;-) CentralConfig bundle that should do what you need. I haven't had a chance to test too heavily. https://github.com/kscarr73/CentralConfig Let me know if you have any questions. On Fri, Sep 25, 2015 at 5:45 AM K

Re: Best practices : Configuration shared between bundles

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 wrote: > You should also look into

Re: Best practices : Configuration shared between bundles

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

Re: Best practices : Configuration shared between bundles

Something similar would be create a bundle that reads a config file, with getProperty as a interface function, and then expose the class as a service that can be used by other bundles in reference. This would be a quick way to accomplish this functionality . On Fri, Sep 25, 2015, 5:38 AM Kevin Ca

Re: Best practices : Configuration shared between bundles

I have created a configuration that pulls from a db every 5 minutes. The bundle creates a isgconfig service for each entry in the configuration file. The config service is a regular osgi bundle that can be referenced by any bundle in the system. This works really well for centralized configurati

Re: Best practices : Configuration shared between bundles

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

Re: Karaf 4.0.1 - Unable to locate Spring NamespaceHandler for XML schema namespace [http://camel.apache.org/schema/spring]

If you take a look at the camel-spring feature in detail: start-level="50"> dependency="true">mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1 spring spring-dm spring-tx version="2.15.2">camel-coremvn:org.apache.camel/camel-spring/2.15.2 It limits the spring dependency to <=4. So you

Re: Best practices : Configuration shared between bundles

You can use the 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 cont

RE: Best practices : Configuration shared between bundles

Hi Arnaud, I’m not too sure what you need. Wouldn’t two property placeholders be ok? Regards, JP [@@ OPEN @@] De : Arnaud Deprez [mailto:arnaudep...@gmail.com] Envoyé : vendredi 25 septembre 2015 10:05 À : user@karaf.apache.org Objet : Best practices : Configuration shared between bundles H

Re: Best practices : Configuration shared between bundles

Yeah ok, That's what I though when I had read some documentation about that. The thing is that the OSGi service is not useable directly in my blueprint configuration. Is there to achieve that (OSGi service with common configuration) by using DS or something at a higher level than using the OSGi A

Re: Best practices : Configuration shared between bundles

Hi Arnaud, sorry no icing here ;) The principal way of configuration is one configuration for one service, or a couple of configuration for a couple of services of the same interface (Managed Service Factory). So there is no way of sharing configuration between services. But you can have a servic

Best practices : Configuration shared between bundles

Hi folks, I would like to have your opinion about my needs. I've several bundles which all need their custom configuration (own PID) but all of them depends on some common configuration depending on which environment (ie: test, production) my karaf instance is running. I'm currently using apache