Re: [PROPOSAL] Karaf release cycle

That's why we have an extend of 2 weeks to deal with other projects. Regards JB On 10/08/2014 08:16 AM, Christian Schneider wrote: Generally I agree that we should aim for such a cycle. I only hope it is possible as we depend a lot on other projects that we bundle. So a lot of the time a releas

Re: Pooling with PostgreSQL and Karaf

If you are using Karaf 3.0.1, you can use the jdbc commands to create the data source. There is a generic data source type and I think it uses Apache Common DBCP. Thanks, Raj On Wednesday 08 October 2014 11:42 AM, jkraushaar wrote: Hi there, I like to set up a PostgreSQL data source in Kara

Re: [PROPOSAL] Karaf release cycle

Generally I agree that we should aim for such a cycle. I only hope it is possible as we depend a lot on other projects that we bundle. So a lot of the time a release waits on fixes or releases in upstream projects. Christian Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré: Hi all, Users c

Re: Pooling with PostgreSQL and Karaf

Hi Jochen, you now have the jdbc:* commands to create datasource. Especially the generic datasource use jdbc: https://git-wip-us.apache.org/repos/asf?p=karaf.git;a=blob_plain;f=jdbc/src/main/resources/org/apache/karaf/jdbc/internal/datasource-generic.xml;hb=HEAD Regards JB On 10/08/2014 08:1

Pooling with PostgreSQL and Karaf

Hi there, I like to set up a PostgreSQL data source in Karaf. In the Karaf-Tutorial a org.postgresql.ds.PGPoolingDataSource is used (see https://github.com/cschneider/Karaf-Tutorial/blob/master/db/datasource/datasource-postgres.xml). On the other hand PostgreSQL recommends to not use the pooled da

[PROPOSAL] Karaf release cycle

Hi all, Users complained about the variable and long delays between Karaf releases. It's a fair comment and it's something that we have to improve. I propose the following new policy about the releases cycle: - for "active" branches (3.0.x and 2.4.x), I propose a release every 6 weeks, with m

Re: Problems With Factory Configurations In Karaf 3.0.1

Done and checked on all branches. Regards JB On 10/08/2014 05:35 AM, Gareth wrote: Hello John, It looks like it is fixed on the 3.0.x branch: https://github.com/apache/karaf/blob/karaf-3.0.x/features/core/src/main/java/org/apache/karaf/features/internal/FeatureConfigInstaller.java Guillaume

Re: Problems With Factory Configurations In Karaf 3.0.1

By the way, the revert on master has been reverted as well (same patch as on karaf-3.0.x). I'm fixing there as well. Regards JB On 10/08/2014 05:35 AM, Gareth wrote: Hello John, It looks like it is fixed on the 3.0.x branch: https://github.com/apache/karaf/blob/karaf-3.0.x/features/core/src/

Re: Problems With Factory Configurations In Karaf 3.0.1

Hi Gareth, I think Achim missed this part in his patch. I'm fixing it. Regarding you , I agree for the delays between versions. It's something that we are improving. After the 3.0.2 and 4.0.0.M1 out, we will force ourself to release on a regular cycle (I propose one release every 6/8 weeks).

Re: Problems With Factory Configurations In Karaf 3.0.1

I agree with nearly everything you (Gareth) have said on this thread. I see you also suggested returning 3 strings from the parse method for the same reason I did :-) I was objecting to: - calling the generated karat-specific id - , where one of foo and bar is the factoryPid and the other is a

Re: Problems With Factory Configurations In Karaf 3.0.1

Hello John, It looks like it is fixed on the 3.0.x branch: https://github.com/apache/karaf/blob/karaf-3.0.x/features/core/src/main/java/org/apache/karaf/features/internal/FeatureConfigInstaller.java Guillaume reverted the offending change on July 11: https://github.com/apache/karaf/commit/c31ed

Java working directory, relative file paths, and Karaf...

Hi, We have a project (Cytoscape) that uses Karaf as its shell for launching OSGi bundles. Anyway, when Karaf is started using the provided script (framework/bin/karaf and karaf.bat) we've noticed the working directory is changed to karaf.base before the JVM is invoked. This is done using the foll

Re: Problems With Factory Configurations In Karaf 3.0.1

From my point of view there is a bunch of misinformation in some of the comments on this thread. Here's what I think: 0) The config admin spec has a meaning for factory pid and pid. If you create a factory configuration, you use a factory pid, but you cannot control the pid for the configurat

Re: Problems With Factory Configurations In Karaf 3.0.1

So did the original error end up getting fixed? I couldn't tell from the commits, jira, or this thread whether you reverted back to the original behavior or not. Gareth was correct in the original post for this thread, 3.0.1 is broken. We just upgraded from Karaf 3.0.0 to Karaf 3.0.1 and all of

Re: java.lang.NoClassDefFoundError for javax.security.auth* packages

Sorry, I realized that removing javax.security.auth.* will not auto export those packages. The workaround to my problem is to add the javax.security.auth.* to org.osgi.framework.bootdelegation thought this is strongly discouraged [1] [1] http://wiki.osgi.org/wiki/Why_does_Eclipse_find_javax.

Re: karaf programmatic restart

Unfortunatly not. But the behaviour is a bit different. This time it gives an 'Unable to start blueprint container for bundle org.apache.aries.blueprint.cm' error (see log karaf2.log ) -- View this message in context: http://karaf.9

Re: karaf programmatic restart

Hi Giacomo, does it work with Karaf 2.3.5 for instance ? Regards JB On 10/07/2014 05:16 PM, Giacomo Coletta wrote: Hi Karaf users, i'm in the need to have my Karaf based application to restart karaf programmatically. Searching the mailing list I found the following thread indicating me the wa

karaf programmatic restart

Hi Karaf users, i'm in the need to have my Karaf based application to restart karaf programmatically. Searching the mailing list I found the following thread indicating me the way: http://karaf.922171.n3.nabble.com/Programmatically-restarting-Karaf-while-using-the-service-wrapper-td4031516.html#a

Re: Custom install cannot resolve wrapped dependency

Hi Marcus, To move a feature from startup to featuresBoot: - the features repo has to be in compile scope - the features should not be in but in in the install-kar goal configuration. Regards JB On 10/07/2014 03:44 PM, Marcus Bond wrote: Ok so as I'm using the maven-bundle-plugin it should

Re: Access API's within internal network.

Srikanth, please take a look at the cxf documenation at [1]. Just put the required address in the according field. As you can see in [2], the address field might contain a different port. regards, Achim [1] - http://cxf.apache.org/docs/jaxrs-services-configuration.html#JAXRSServicesConfiguration

Re: Access API's within internal network.

On 10/7/2014 2:24 AM, Srikanth Hugar wrote: Hello, I have multiple REST API's developed using karaf, jetty, cxf. I want to provide access to some API's only within internal office network and some API's to everyone. I suggest using OSGI Remote Services (chapter 100 in enterprise specif

RE: Custom install cannot resolve wrapped dependency

Hi Marcus, I have no idea about the repos, but as an addition to the startup: Instead of specifying the bundles in the startup.properties, the org.apache.karaf.features.cfg can contain startup features, and features can contain wrap: URLs. So if you don’t need to start up your lib bundles at a

Re: Custom install cannot resolve wrapped dependency

Ok so as I'm using the maven-bundle-plugin it should be ok? Another issue I am having is with getting artifacts from repositories. The dependencies my custom install uses are as follows.. org.apache.karaf.features framework 3.0.1 kar org.apache.karaf.features standard 3.0.1 features xml org.

Re: Custom install cannot resolve wrapped dependency

Hi Marcus, the startup.properties can contain only bundles. So, you can create uber bundles (embedded other bundles) using the maven-shade-plugin, or directly the maven-bundle-plugin. Regards JB On 10/07/2014 02:17 PM, Marcus Bond wrote: Hi, yes that would be great. I'm worried now though

Re: Custom install cannot resolve wrapped dependency

Hi Marcus, if those "embedded" libs are embedded inside your bundle, this isn't an issue. If you have the as external bundles, make sure you wrap those either, before deployment by shading those (as servicemix does it) Or by changing the maven coordinate slightly by adding the wrap: url-handler b

Re: Custom install cannot resolve wrapped dependency

Hi, yes that would be great. I'm worried now though that we have other OSGi bundles of our own that have embedded dependency libs that are not OSGi bundles and therefore will also require "wrap", is this going to be a problem with startup? Regards, Marcus. On Tue, Oct 7, 2014 at 12:57 PM, Jean-B

Re: java.lang.NoClassDefFoundError for javax.security.auth* packages

Thanks JB. I think some thing has changes in the current version of Eclipse and it does not export these packages and they are not available for import in the PDE. Is there a workaround? What happens if I remove the javax.security.auth* from system packages? Regards, Raj On Tuesday 07 Octo

Re: java.lang.NoClassDefFoundError for javax.security.auth* packages

Hi Raj, even if the packages are provided by the JRE (and defined in etc/jre.properties), you have to import it in your bundle: it's what we name the system packages. Regards JB On 10/07/2014 01:07 PM, Rajbir Saini wrote: Hi, I am using Apache Karaf with JAAS login module. My application t

Re: Custom install cannot resolve wrapped dependency

Hi, it's due to the fact that jandex is not an OSGi bundle, that's why it's prefixed with wrap. I guess that you don't need jandex in the startup.properties (but more as a featuresBoot). You can tweak the install-kar goal. Do you want some help around that ? Regards JB On 10/07/2014 12:46

java.lang.NoClassDefFoundError for javax.security.auth* packages

Hi, I am using Apache Karaf with JAAS login module. My application throws java.lang.NoClassDefFoundError exception. If I import that javax.security.auth* packages in my bundle this problem is resolved. As these packages are provided by JRE, do I need to import them? I am using Karaf 3.0.1.

Custom install cannot resolve wrapped dependency

I am receiving the following error but the system folder includes the jandex1.1.0.Final jar file Is there a way to get around this bug? SEVERE: Could not launch framework java.lang.RuntimeException: Error installing bundle listed in startup.properties with url: wrap:mvn:org.jboss/jandex/1.1.0.Fin

Access API's within internal network.

Hello, I have multiple REST API's developed using karaf, jetty, cxf. I want to provide access to some API's only within internal office network and some API's to everyone. Do we have any possibility of achieving by configuration in karaf(jetty) ? Best Regards, Srikanth.

Re: Custom distribution with features

So I'm using the karaf-maven-plugin and version 3.0.1 of Karaf. I think I understand how the plugin works but the issue is knowing the dependencies. In the documentation for a custom distribution ( http://karaf.apache.org/manual/latest/developers-guide/custom-distribution.html) it shows a pom file