Re: Features install options...

2019-02-04 Thread Ranx
One item about uninstalling configuration files is when using PAX JDBC as an example. When I'm not using the database connection because I've uninstalled the feature(s) that use it, I would like the connection and OSGi service to go away. The configuration file shouldn't remain behind and

Re: Features install options...

2019-02-04 Thread Ranx
One thing I realized as I was looking over the docs is that what I'm looking for is something like how the install="auto" works when you hot deploy a features file by dropping it in the deploy folder. I'm not really wanting to install anything that way but it would be nice if I could have some

Re: Karaf 4.2.2 Set jre.properties before assembly building startup stage

2019-02-04 Thread Jean-Baptiste Onofré
Hi, You mean at runtime or build time ? jre.properties is supposed to be provided at build time (or before starting). Regards JB On 04/02/2019 14:44, Michal Dabrowski wrote: > Hi, > > I know there are few ways to set the jre.properties file content but none of > them works in my case. For

Re: Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

2019-02-04 Thread Jean-Baptiste Onofré
By the way, screenshots are not allowed directly on mailing list. Regards JB On 04/02/2019 14:03, Michal Dabrowski wrote: > Hi, > > I've tried to build static karaf 4.2.2 assembly using karaf-maven-plugin but > I could not get it fully working. During karaf startup there are exceptions: > >

Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

2019-02-04 Thread Michal Dabrowski
Hi, I've tried to build static karaf 4.2.2 assembly using karaf-maven-plugin but I could not get it fully working. During karaf startup there are exceptions: I've checked the Apache Felix Declarative Services (36) bundle imports: and Static ConfigAdmin headers: It seems there is

Karaf 4.2.2 Set jre.properties before assembly building startup stage

2019-02-04 Thread Michal Dabrowski
Hi, I know there are few ways to set the jre.properties file content but none of them works in my case. For example, I use karaf-maven-plugin to build karaf assembly and I have an Ignite profile listed in my startupProfiles: my-ignite-profile

Re: Features install options...

2019-02-04 Thread Jean-Baptiste Onofré
Fair enough, I agree to add an option to cleanup the config/configfile provisioned by the feature. It's a little bit hazardous, but if the user provide the option, he knows what he does ;) Mind if I create the Jira ? These improvements can go in Karaf 4.3.x. Regards JB On 04/02/2019 23:26,

Re: Features install options...

2019-02-04 Thread Jean-Baptiste Onofré
Hi, You have an option to install all feature containing in a features repo when you do repo-add. At that step, we could use the "install" attribute on the feature to install it or not. Do you mind if I create the Jira (I think it's already partially done) ? Regards JB On 05/02/2019 00:26,

Re: Features install options...

2019-02-04 Thread Christian Schneider
Be aware that the configs in features are normally only meant for default configs. You do not want your DB password to be in a feature xml that is deployed to maven repo. Christian Am Di., 5. Feb. 2019 um 00:26 Uhr schrieb Ranx : > One thing I realized as I was looking over the docs is that

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Jean-Baptiste Onofré
FYI: I did Pax JDBC 1.3.3 release yesterday, and Karaf 4.2.3-SNAPSHOT is already updated. So it will be included in 4.2.3 release that will be on vote tonight. Regards JB On 04/02/2019 16:27, Alex Soto wrote: > Thank you all, > > The workaround worked, i.e., removed feature /pax-jdbc-derby / 

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Alex Soto
Thank you all, The workaround worked, i.e., removed feature pax-jdbc-derby and adding only the derby feature. Best regards, Alex soto > On Feb 2, 2019, at 1:48 AM, Jean-Baptiste Onofré wrote: > > That's what I'm testing: still keeping pax-jdbc-derby feature but just > installing the

Re: Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

2019-02-04 Thread Michal Dabrowski
I used wysiwyg "raw text" formatter and unfortunately all quotes went blank. I have edited my post but probably you have not seen it in mail. You can reproduce it by running Karaf 4.2.2 karaf-profile-example-static

Re: Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

2019-02-04 Thread Jean-Baptiste Onofré
Hi, I updated the profile registry to add scr Karaf feature in the karaf profile. Then I used this profile in the static assembly. It seems to work fine. Can you provide some detail to reproduce ? Regards JB On 04/02/2019 14:03, Michal Dabrowski wrote: > Hi, > > I've tried to build static

Re: Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

2019-02-04 Thread Michal Dabrowski
I used wysiwyg "raw text" formatter and unfortunately all quotes went blank. I have edited my post but probably you have not seen it in mail. You can reproduce it by running Karaf 4.2.2 karaf-profile-example-static

Re: Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

2019-02-04 Thread Jean-Baptiste Onofré
It's what I did on master: I built the registry (adding scr feature in karaf profile) and the static profile based distribution (using the karaf profile): [INFO] [INFO] Reactor Summary for Apache Karaf :: Examples :: Profile

Re: Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

2019-02-04 Thread Jean-Baptiste Onofré
Hi, do you use the scr feature provided by Karaf ? Let me check the profile. Regards JB On 04/02/2019 14:03, Michal Dabrowski wrote: > Hi, > > I've tried to build static karaf 4.2.2 assembly using karaf-maven-plugin but > I could not get it fully working. During karaf startup there are

Re: Karaf 4.2.2 Set jre.properties before assembly building startup stage

2019-02-04 Thread Michal Dabrowski
It fails at build time as stated in provided log. I think it is because jre.properties file is updated/overridden after the stage where startup profile requirements resolvement happens. One of these bundles needs com.sun.management which at this moment is not listed in jre.properties file. --

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Benjamin Graf
Hi, I'm a little bit confused:     mvn:org.osgi/org.osgi.service.jdbc/1.0.0     pax-jdbc-spec     mvn:org.apache.derby/derby/${derby.version} pax-jdbc-derby still does install mvn:org.osgi/org.osgi.service.jdbc/x.x.x but not mvn:org.ops4j.pax.jdbc/pax-jdbc/x.x.x Regards

Features install options...

2019-02-04 Thread ranx
I just created a features file with multiple feature targets in it for database setup, netty server, rest services, etc. Then there's an "all" feature that calls the others. It all works fine but it acts like it collates or includes all the other features elements when I call the install of

Re: Features install options...

2019-02-04 Thread Jean-Baptiste Onofré
Hi Brad, see my comments inline: 1. Is there a directive to tell Karaf to run the features installs individually and not to lump them together? Why not splitting your feature in features, and then you can do feature:install ? I'm not sure I understand what you mean ;) 2. Is there

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Jean-Baptiste Onofré
Indeed, It should work without the jdbc feature (Karaf one). I'm releasing Karaf 4.2.3 now (we are already late for this release). I'm gonna investigate the Derby case ;) Regards JB On 04/02/2019 21:36, Benjamin Graf wrote: Hi, I'm a little bit confused:    

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Jean-Baptiste Onofré
Thanks Benjamin, much appreciated ;) Regards JB On 04/02/2019 21:50, Benjamin Graf wrote: Hi JB, OK, go for it and good night. :-) Regards Benjamin Am 04.02.2019 um 21:47 schrieb Jean-Baptiste Onofré: Indeed, It should work without the jdbc feature (Karaf one). I'm releasing Karaf

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Benjamin Graf
Hi JB, if I install pax-jdbc-derby on a fresh Karaf 4.2.3-SNAPSHOT I do not get a DataSourceFactory registered. I also do not found any code in derby sources that does anything about that if do not install pax-jdbc  to get the Driver instrumented. Regards Benjamin Am 04.02.2019 um 16:30

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Jean-Baptiste Onofré
By the way, Karaf example itest (jdbc example) use Derby without problem. Regards JB On 04/02/2019 20:23, Benjamin Graf wrote: > Hi JB, > > if I install pax-jdbc-derby on a fresh Karaf 4.2.3-SNAPSHOT I do not get > a DataSourceFactory registered. I also do not found any code in derby > sources

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Jean-Baptiste Onofré
Just to illustrate, on a freshly built 4.2.3-SNAPSHOT: karaf@root()> feature:install jdbc karaf@root()> feature:install pax-jdbc-derby karaf@root()> la|grep -i derby 52 │ Active │ 80 │ 10.14.200.1828579 │ Apache Derby 10.14 karaf@root()> bundle:services -p 52 Apache Derby 10.14 (52)

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Benjamin Graf
Hi JB, I install pax-jdbc-config and pax-jdbc-derby. After installing pax-jdbc I got the derby DataSourceFactory. IMHO pax-jdbc is not mandatory to install and pooling seems to not work either. Regards Benjamin Am 04.02.2019 um 20:44 schrieb Jean-Baptiste Onofré: > By the way, Karaf example

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Jean-Baptiste Onofré
pax-jdbc installs the pax-jdbc-spec bundle, that's why. Regards JB On 04/02/2019 20:59, Benjamin Graf wrote: > This way pax-jdbc-derby also need pax-jdbc feature to get installed! > > Am 04.02.2019 um 20:57 schrieb Benjamin Graf: >> Hi JB, >> >> I install pax-jdbc-config and pax-jdbc-derby.

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Benjamin Graf
Hi JB, I would suggest to add pax-jdbc feature as dependency to pax-jdbc-derby feature as it would work without. Just keep pax features independent from possible installed karaf feature. What do you think? Regards Benjamin Am 04.02.2019 um 21:20 schrieb Jean-Baptiste Onofré: > Hi Benjamin, >

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Jean-Baptiste Onofré
Hi Benjamin, With Pax JDBC 1.3.3 ? I tested in Karaf and it's covered by Pax JDBC itest. I checked in Derby code, and there's the Activator that register the AutoloaderDriver with the factory. Let me double check but I'm surprised. What did you do ? feature:install jdbc feature:install

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Benjamin Graf
This way pax-jdbc-derby also need pax-jdbc feature to get installed! Am 04.02.2019 um 20:57 schrieb Benjamin Graf: > Hi JB, > > I install pax-jdbc-config and pax-jdbc-derby. After installing pax-jdbc > I got the derby DataSourceFactory. IMHO pax-jdbc is not mandatory to > install and pooling

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Jean-Baptiste Onofré
Hi, pax-jdbc-config already comes with jdbc feature. I know pooling doesn't work: that's an issue in the Derby bundle. So, I took the decision to fix the dual DataSourceFactory issue, and I created a Jira at Derby to fix the XA/Pooling issue. Regards JB On 04/02/2019 20:57, Benjamin Graf

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Benjamin Graf
Hu JB, Just to summarize: Karaf jdbc installs pax-jdbc and pax-jdbc-config sub features. pax-jdbc is needed to get a DataSourceFactory instance for Driver only installations like Derby. Derby does not register a DataSourceFactory  directly. But if you do not install jdbc and/or pax-jdbc you

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Jean-Baptiste Onofré
Hi Benjamin, Previously, pax-jdbc-derby feature also needed pax-jdbc feature. I directly installed the derby bundle, it uses dynamic import, that's why it works with pax-jdbc-spec IMHO (with the package with DataSourceFactory is there). So, I'm not sure to see your point: in previous version,

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

2019-02-04 Thread Jean-Baptiste Onofré
Hi, Actually, this is because pax-jdbc-spec feature should have: dependency="true">mvn:org.osgi/org.osgi.service.jdbc/${org.osgi.service.jdbc.version} That's why jdbc feature make things working. If you don't mind, I would like to release Karaf 4.2.3 like this (as it works fine). In the