Before talking about profile (that could be used there), you can also
create env specific feature just containing the config.
For the profile, you can take a look on the example:
https://github.com/apache/karaf/tree/master/examples/karaf-profile-example
I'm planning to blog and update the
feature works with any file and provisioning.
For instance, you can do:
mvn:groupId/artifactId/1.0-SNAPSHOT/uat/cfg
mvn:groupId/artifactId-foo/1.0-SNAPSHOT/uat/xml
mvn:groupId/artifactId/1.0-SNAPSHOT/qa/cfg
mvn:groupId/artifactId-foo/1.0-SNAPSHOT/qa/xml
Regards
JB
On 01/02/2019
I'm building a 4.2.2 custom distribution which is to be deployed to multiple
environments. Each env should have it's own config, but shouldn't know about
other env's configs. I wanted to use Karaf profiles but there isn't any
documentation on it, and I'm not sure if itll abide by the "no env
I'm building a 4.2.2 custom distribution which is to be deployed to multiple
environments. Each env should have it's own config, but shouldn't know about
other env's configs. I wanted to use Karaf profiles but there isn't any
documentation on it, and I'm not sure if itll abide by the "no env
It would be the same, you will be able to apply a profile setting the
properties, but you would have to restart anyway.
As the system.properties is equivalent of doing java -Dfoo=bar, you have
to restart the JVM (that's not Karaf specific, it's the way it works in
Java).
If your application uses
Thanks for the update. I'm busy with Karaf 4.2.3 preparation right now,
I will take a look tomorrow.
Regards
JB
On 01/02/2019 17:26, Oleksii Mohylin wrote:
> Hi,
>
> I tried this setup with Karaf 4.2.2 as well and had the same error.
> Looking forward to hearing from you.
>
> Best regards,
>
I'm trying to add system properties via
file:${env.config.path}/custom.system.properties
This file gets updated but I have to restart karat for the properties to
actually get picked up. I have this as a startup feature - I guess even at
this stage it's too late for the properties to get
That's normal: the system.properties are loaded by Karaf Main, before
any other service (including ConfigAdmin).
Do you really need system properties there ?
Regards
JB
On 01/02/2019 17:11, Cantbebotheredtothinkofauserna wrote:
> I'm trying to add system properties via
>
>
>
Hi,
I tried this setup with Karaf 4.2.2 as well and had the same error.
Looking forward to hearing from you.
Best regards,
Oleksii
-Original Message-
From: Jean-Baptiste Onofré
Sent: Tuesday, January 29, 2019 6:50 PM
To: user@karaf.apache.org
Subject: Re: Ignite won't start in Karaf
Hello,
I am experiencing a problem where pax-jdbc-config (version 1.3.0) is creating
duplicate Derby Data Sources. I copy the data source configuration file to
Karaf's etc/ directory, after a while I can see it created two identical Data
Sources.
The configuration file:
Hi,
I just did a blog where I'm using a derby datasource (on Karaf
4.2.3-SNAPSHOT): http://blog.nanthrax.net/?p=874
If you install an unique provider (only derby or derbyclient, but not
both), then, it should work.
I did:
feature:install pax-jdbc-derbyclient
then:
jdbc:ds-create -dn
Oh, thanks!
Can you suggest a work around?
What s the ETA for a fix?
I have a release deadline looming and I am afraid I can't wait too long.
Thank you for the prompt response.
Best regards,
Alex soto
> On Feb 1, 2019, at 1:05 PM, Jean-Baptiste Onofré wrote:
>
> Indeed, I can
> How to do you provision the datasource cfg file ?
> Using a feature or by dropping the file in the etc folder ?
Dropping file in the etc/ directory
Best regards,
Alex soto
> On Feb 1, 2019, at 12:57 PM, Jean-Baptiste Onofré wrote:
>
> Hi,
>
> I just did a blog where I'm using a derby
Indeed, I can reproduce the issue embedded:
Name│ Service Id │ Product │ Version │ URL
│ Status
┼┼──┼───┼───┼───
querier │ 91 │ Apache Derby │ 10.13.1.1 -
If derby now provides a DataSourceFactory then we should remove
pax-jdbc-derby from the feature.
I guess at some point derby started providing the DSF and we just forgot to
remove the adapter bundle.
Christian
Am Sa., 2. Feb. 2019 um 07:19 Uhr schrieb Jean-Baptiste Onofré <
j...@nanthrax.net>:
It would certainly require a new pax-jdbc release.
Anyway, it's not a blocker IMHO (having two service is not a big deal).
I hope to fix that today in order to include in Karaf 4.2.3 release.
Regards
JB
On 01/02/2019 19:10, Alex Soto wrote:
> Oh, thanks!
>
> Can you suggest a work around?
>
By the way, a simple workaround is to stop or even remove the
pax-jdbc-derby bundle, and use only the derby bundle (or the opposite).
Regards
JB
On 02/02/2019 06:55, Jean-Baptiste Onofré wrote:
> OK, I think I found the problem: installing the pax-jdbc-derby feature
> actually registers two
OK, I think I found the problem: installing the pax-jdbc-derby feature
actually registers two DataSourceFactory services:
1. a DataSourceFactory service coming from pax-jdbc-derby bundle (which
is normal) (org.apache.derby.jdbc.EmbeddedDriver)
2. a DataSourceFactory service coming from directly
That's what I'm testing: still keeping pax-jdbc-derby feature but just
installing the derby bundle (not the pax-jdbc wrapper bundle).
Regards
JB
On 02/02/2019 07:35, Christian Schneider wrote:
> If derby now provides a DataSourceFactory then we should remove
> pax-jdbc-derby from the feature.
>
19 matches
Mail list logo
