Re: Features install options...

[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 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 similar
> functionality when doing it via repo-add or a features command line. Just
> some way to make the features autoload but retain their identity so I can
> uninstall them if I wish.
>
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: Features install options...

[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, Ranx wrote:
> 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 similar
> functionality when doing it via repo-add or a features command line. Just
> some way to make the features autoload but retain their identity so I can
> uninstall them if I wish.
> 
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Features install options...

[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, Ranx wrote:
> 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 potentially keep
> the connection alive.  
> 
> That's a quibble really. I guess I was just after some mechanism with the
> features that was more akin to manually typing feature:install foo that I
> was able to call from another feature.
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Features install options...

[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 similar
functionality when doing it via repo-add or a features command line. Just
some way to make the features autoload but retain their identity so I can
uninstall them if I wish.




--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Features install options...

[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 potentially keep
the connection alive.  

That's a quibble really. I guess I was just after some mechanism with the
features that was more akin to manually typing feature:install foo that I
was able to call from another feature.



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Features...

[ranx]

Sorry about sending this on a separate reply but I have issues with Gmail
and my reply address bouncing when I reply to any of the Camel and Karaf
forums. I've virtually given up trying to post replies to folks issues on
the Camel forum anymore. 

 

I commonly separate them out for database setup, transaction services, etc.
I might be working on the functionality of a bundle or group of bundles and
during development I just want to install/uninstall a single feature and not
the whole ball of wax. But for initial deployment or deployment on a server
I want the single target. 

 

Occasionally I blow away the cache and delete any cfg files and reinstall
the entire application. I do that as much to make sure I'm not fooling
myself as when I'm modifying cfg files or configuration or features and I
want to make sure that my changes are really working and not picking up old
artifacts. Perhaps there's a better way to do this. I'll just make up a
simple case though to illustrate.

 

When I'm setting up and debugging, I can install the features one at a time
and make sure that everything is found and working. If any errors pop up, I
can fix the feature and re-run it. When they are all running, I'm good.  In
the below example, I might be working on the foo-transaction-services and
adding new SCR connectors. I'd like to be able to unzip a new copy of Karaf
or blow away the cache and my cfg files, run the foo-test-all and have
everything up and running.  Then as I monkey wrench the transaction services
I'd like to uinstall/reinstall the foo-transaction-services feature and have
the bundles removed along with configuration and then have them reinstalled.
Obviously, it sounds as if that would be too different. It might look more
like a fork directive or script than the collection of features. 

 



  foo-core

  foo-datasource

  foo-transaction-services

  foo-netty-server

  foo-rest-services

   

 

   

  foo-all

  foo-test-dbloader

   

 

More akin to:

 



  foo-core

Or more like.where there isn't an implied parallelism. 

  foo-datasource

  foo-transaction-services

  foo-netty-server

  foo-rest-services

   

 

The atoms would retain their individuality that way. It might be that a
different kind of feature like feature-container would be a possible
mechanism. Dunno. Just thought I'd ask because it fits my works style with a
lot of unit tests and then iterations into both a clean and dirty container.

 

From: jbonofre [via Karaf] mailto:ml+s922171n4055049...@n3.nabble.com> > 
Sent: Monday, February 4, 2019 2:44 PM
To: Ranx mailto:r...@enjekt.org> >
Subject: Re: Features install options...

 

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 any directive to tell Karaf to delete/remove any 
> configuration files it has installed when it uninstalls the feature 
> associate it with it? 

Not currently (for "security" reason on the config). You can override 
the cfg files at install time. 
I can create a Jira to add an option to cleanup file based on 
 finalName. 

>  3. In the past I've used the plugin to install .cfg files from my 
> bundles and there is a directive override=true/false. Does anything 
> like that exist for the config done directly from the feature? 

I guess you mean  element. No,  element is for 
ConfigAdmin, it's created at feature install time. 

Regards 
JB 

  _  

If you reply to this email, your message will be added to the discussion
below:

http://karaf.922171.n3.nabble.com/Features-install-options-tp4055048p4055049
.html 

To start a new topic under Karaf - User, email
ml+s922171n930749...@n3.nabble.com
  
To unsubscribe from Karaf - User, click here
 .
 
 NAML 

 

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[Benjamin Graf]

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 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:
>>
>> 
>>  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
>>
>> Benjamin
>>
>> Am 04.02.2019 um 21:29 schrieb 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 mean time, I'm creating a Jira at Pax JDBC to
>>> add the org.osgi.service.jdbc bundle in pax-jdbc-derby feature.
>>>
>>> OK ?
>>>
>>> Regards
>>> JB
>>>
>>> On 04/02/2019 21:24, Benjamin Graf wrote:
 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,
>
> 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, you also
> need
> pax-jdbc to get the adapter working.
>
> What are you suggesting ?
>
> Regards
> JB
>
> On 04/02/2019 21:08, Benjamin Graf wrote:
>> 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
>> won't get
>> the DataSourceFactory for Derby anymore. That IMHO is a break to
>> previous versions using the pax-jdbc-derby adaptor.
>>
>> Regards
>>
>> Benjamin
>>
>> Am 04.02.2019 um 21:03 schrieb 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. 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 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 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 schrieb 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
> / and
> adding only the derby feature.
>
>
> Best regards,
> Alex soto
>
>
>
>
>> On Feb 2, 2019, at 1:48 AM, Jean-Baptiste Onofré
>> > 

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

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


  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

Benjamin

Am 04.02.2019 um 21:29 schrieb Jean-Baptiste Onofré:

Hi,

Actually, this is because pax-jdbc-spec feature should have:

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 mean time, I'm creating a Jira at Pax JDBC to
add the org.osgi.service.jdbc bundle in pax-jdbc-derby feature.

OK ?

Regards
JB

On 04/02/2019 21:24, Benjamin Graf wrote:

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,

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, you also
need
pax-jdbc to get the adapter working.

What are you suggesting ?

Regards
JB

On 04/02/2019 21:08, Benjamin Graf wrote:

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
won't get
the DataSourceFactory for Derby anymore. That IMHO is a break to
previous versions using the pax-jdbc-derby adaptor.

Regards

Benjamin

Am 04.02.2019 um 21:03 schrieb 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. 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 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 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 schrieb 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
/ and
adding only the derby feature.


Best regards,
Alex soto





On Feb 2, 2019, at 1:48 AM, Jean-Baptiste Onofré
mailto:j...@nanthrax.net>> wrote:

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.

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é
mailto:j...@nanthrax.net>
>:

  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 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 Derby
bundle
(org.apache.derby.jdbc.AutoloadedDriver).

Both using the same derby value 

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

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


     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

Benjamin

Am 04.02.2019 um 21:29 schrieb Jean-Baptiste Onofré:

Hi,

Actually, this is because pax-jdbc-spec feature should have:

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 mean time, I'm creating a Jira at Pax JDBC to
add the org.osgi.service.jdbc bundle in pax-jdbc-derby feature.

OK ?

Regards
JB

On 04/02/2019 21:24, Benjamin Graf wrote:

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,

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, you also need
pax-jdbc to get the adapter working.

What are you suggesting ?

Regards
JB

On 04/02/2019 21:08, Benjamin Graf wrote:

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 won't get
the DataSourceFactory for Derby anymore. That IMHO is a break to
previous versions using the pax-jdbc-derby adaptor.

Regards

Benjamin

Am 04.02.2019 um 21:03 schrieb 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. 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 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 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 schrieb 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
/ and
adding only the derby feature.


Best regards,
Alex soto





On Feb 2, 2019, at 1:48 AM, Jean-Baptiste Onofré
mailto:j...@nanthrax.net>> wrote:

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.

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é
mailto:j...@nanthrax.net>
>:

 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 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 Derby
bundle
(org.apache.derby.jdbc.AutoloadedDriver).

Both using the same derby value for osgi.jdbc.driver.name

  service property.

So pax-jdbc-config sees two factory and so it creates one

 datasource per

factory.

That's why it's only when you use derby and actu

Re: Features install options...

[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 any directive to tell Karaf to delete/remove any
configuration files it has installed when it uninstalls the feature
associate it with it?


Not currently (for "security" reason on the config). You can override 
the cfg files at install time.
I can create a Jira to add an option to cleanup file based on 
 finalName.



 3. In the past I’ve used the plugin to install .cfg files from my
bundles and there is a directive override=true/false. Does anything
like that exist for the config done directly from the feature?


I guess you mean  element. No,  element is for 
ConfigAdmin, it's created at feature install time.


Regards
JB

Features install options...

[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 "all". In other words, when I do an uninstall it does not show the other
sub-targets as having been installed. I actually have 3 questions.

 

1.  Is there a directive to tell Karaf to run the features installs
individually and not to lump them together?
2.  Is there any directive to tell Karaf to delete/remove any
configuration files it has installed when it uninstalls the feature
associate it with it?
3.  In the past I've used the plugin to install .cfg files from my
bundles and there is a directive override=true/false. Does anything like
that exist for the config done directly from the feature?

 

I certainly like the use of the config directive right from the feature as
it makes configuration from Maven a snap and thus lets Jenkins manage that.

 

Thanks,

Brad

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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

Benjamin

Am 04.02.2019 um 21:29 schrieb 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 mean time, I'm creating a Jira at Pax JDBC to
> add the org.osgi.service.jdbc bundle in pax-jdbc-derby feature.
>
> OK ?
>
> Regards
> JB
>
> On 04/02/2019 21:24, Benjamin Graf wrote:
>> 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,
>>>
>>> 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, you also need
>>> pax-jdbc to get the adapter working.
>>>
>>> What are you suggesting ?
>>>
>>> Regards
>>> JB
>>>
>>> On 04/02/2019 21:08, Benjamin Graf wrote:
 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 won't get
 the DataSourceFactory for Derby anymore. That IMHO is a break to
 previous versions using the pax-jdbc-derby adaptor.

 Regards

 Benjamin

 Am 04.02.2019 um 21:03 schrieb 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. 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 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 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 schrieb 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
>>> / 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 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.
>
> 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-Baptist

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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 mean time, I'm creating a Jira at Pax JDBC to add 
the org.osgi.service.jdbc bundle in pax-jdbc-derby feature.


OK ?

Regards
JB

On 04/02/2019 21:24, Benjamin Graf wrote:

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,

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, you also need
pax-jdbc to get the adapter working.

What are you suggesting ?

Regards
JB

On 04/02/2019 21:08, Benjamin Graf wrote:

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 won't get
the DataSourceFactory for Derby anymore. That IMHO is a break to
previous versions using the pax-jdbc-derby adaptor.

Regards

Benjamin

Am 04.02.2019 um 21:03 schrieb 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. 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 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 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 schrieb 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 / and
adding only the derby feature.


Best regards,
Alex soto





On Feb 2, 2019, at 1:48 AM, Jean-Baptiste Onofré mailto:j...@nanthrax.net>> wrote:

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.

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é
mailto:j...@nanthrax.net> >:

    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 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 Derby bundle
(org.apache.derby.jdbc.AutoloadedDriver).

Both using the same derby value for osgi.jdbc.driver.name

     service property.

So pax-jdbc-config sees two factory and so it creates one

    datasource per

factory.

That's why it's only when you use derby and actually, the two

    datasource

services come from the two factories.

I'm fixing that.

Regards
JB

On 01/02/2019 19:10, Alex Soto wrote:

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é

    mailto:j...@nanthrax.net> 

>> wrote:

Indeed, I can reproduce the issue embedded:

Name    

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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,
>
> 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, you also need
> pax-jdbc to get the adapter working.
>
> What are you suggesting ?
>
> Regards
> JB
>
> On 04/02/2019 21:08, Benjamin Graf wrote:
>> 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 won't get
>> the DataSourceFactory for Derby anymore. That IMHO is a break to
>> previous versions using the pax-jdbc-derby adaptor.
>>
>> Regards
>>
>> Benjamin
>>
>> Am 04.02.2019 um 21:03 schrieb 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. 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 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 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 schrieb 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 / 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 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.
>>>
>>> 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é
>>> mailto:j...@nanthrax.net> 
>>> >:
>>>
>>>    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 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 Derby bundle
 (org.apache.derby.jdbc.AutoloadedDriver).

 Both using the same derby value for osgi.jdbc.driver.name
>>>     service property.
 So pax-jdbc-config sees two factory and so it creates one
>>>    datasource per
 factory.

 That's why it's only when you us

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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, you also need
pax-jdbc to get the adapter working.

What are you suggesting ?

Regards
JB

On 04/02/2019 21:08, Benjamin Graf wrote:
> 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 won't get
> the DataSourceFactory for Derby anymore. That IMHO is a break to
> previous versions using the pax-jdbc-derby adaptor.
> 
> Regards
> 
> Benjamin
> 
> Am 04.02.2019 um 21:03 schrieb 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. 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 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 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 schrieb 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 / 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 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.
>>
>> 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é
>> mailto:j...@nanthrax.net> 
>> >:
>>
>>    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 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 Derby bundle
>>> (org.apache.derby.jdbc.AutoloadedDriver).
>>>
>>> Both using the same derby value for osgi.jdbc.driver.name
>>     service property.
>>> So pax-jdbc-config sees two factory and so it creates one
>>    datasource per
>>> factory.
>>>
>>> That's why it's only when you use derby and actually, the two
>>    datasource
>>> services come from the two factories.
>>>
>>> I'm fixing that.
>>>
>>> Regards
>>> JB
>>>
>>> On 01/02/2019 19:10, Alex Soto wrote:
 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

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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 won't get
the DataSourceFactory for Derby anymore. That IMHO is a break to
previous versions using the pax-jdbc-derby adaptor.

Regards

Benjamin

Am 04.02.2019 um 21:03 schrieb 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. 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 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 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 schrieb 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 / 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 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.
>
> 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é
> mailto:j...@nanthrax.net> 
> >:
>
>    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 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 Derby bundle
>> (org.apache.derby.jdbc.AutoloadedDriver).
>>
>> Both using the same derby value for osgi.jdbc.driver.name
>     service property.
>> So pax-jdbc-config sees two factory and so it creates one
>    datasource per
>> factory.
>>
>> That's why it's only when you use derby and actually, the two
>    datasource
>> services come from the two factories.
>>
>> I'm fixing that.
>>
>> Regards
>> JB
>>
>> On 01/02/2019 19:10, Alex Soto wrote:
>>> 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é
>    mailto:j...@nanthrax.net> 
> 
 >> wrote:

 Indeed, I can reproduce the issue embedded:

 Name    │ Service Id │ Product  │ Version   │ URL
  

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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. 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 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 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 schrieb 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 / 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 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.

 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é
 mailto:j...@nanthrax.net> 
 >:

    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 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 Derby bundle
> (org.apache.derby.jdbc.AutoloadedDriver).
>
> Both using the same derby value for osgi.jdbc.driver.name
     service property.
> So pax-jdbc-config sees two factory and so it creates one
    datasource per
> factory.
>
> That's why it's only when you use derby and actually, the two
    datasource
> services come from the two factories.
>
> I'm fixing that.
>
> Regards
> JB
>
> On 01/02/2019 19:10, Alex Soto wrote:
>> 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é
    mailto:j...@nanthrax.net> 
 
>>> >> wrote:
>>>
>>> Indeed, I can reproduce the issue embedded:
>>>
>>> Name    │ Service Id │ Product  │ Version   │ URL
>>>    │ Status
>>>
    
 ┼┼──┼───┼───┼───
>>> querier │ 91 │ Apache Derby │ 10.13.1.1 - (1765088) │
>>> jdbc:derby:derby-data/querier │ OK
>>> querier │ 92 │ Apache Derby │ 10.13.1.1 - (1765088) │
>>> jdbc:derby:derby-data/querier │ OK
>>>
>>> I will fix that.
>>>
>>> Regards
>>> JB
>>>
>>> On 01/02/2019 19:01, Alex Soto wrote:
> How to do you provision the datasource cfg file ?
> Using a feature or by dropping

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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 seems to not work either.
>
> Regards
>
> Benjamin
>
> Am 04.02.2019 um 20:44 schrieb 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 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 schrieb 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 / 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 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.
>>>
>>> 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é
>>> mailto:j...@nanthrax.net> 
>>> >:
>>>
>>>    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 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 Derby bundle
 (org.apache.derby.jdbc.AutoloadedDriver).

 Both using the same derby value for osgi.jdbc.driver.name
>>>     service property.
 So pax-jdbc-config sees two factory and so it creates one
>>>    datasource per
 factory.

 That's why it's only when you use derby and actually, the two
>>>    datasource
 services come from the two factories.

 I'm fixing that.

 Regards
 JB

 On 01/02/2019 19:10, Alex Soto wrote:
> 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é
>>>    mailto:j...@nanthrax.net> 
>>> 
>> >> wrote:
>>
>> Indeed, I can reproduce the issue embedded:
>>
>> Name    │ Service Id │ Product  │ Version   │ URL
>>    │ Status
>>
>>>    
>>> ┼┼──┼───┼───┼───
>> querier │ 91 │ Apache Derby │ 10.13.1.1 - (1765088) │
>> jdbc:derby:derby-data/querier │ OK
>> querier │ 92 │ Apache Derby │ 10.13.1.1 - (1765088) │
>> jdbc:derby:derby-data/querier │ OK
>>
>> I will fix that.
>>
>> Regards
>> JB
>>
>> On 01/02/2019 19:01, Alex Soto wrote:
 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é
>>>    mailto:j..

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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 wrote:
> 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 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 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 schrieb 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 / 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 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.
>>>
>>> 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é
>>> mailto:j...@nanthrax.net> 
>>> >:
>>>
>>>    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 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 Derby bundle
 (org.apache.derby.jdbc.AutoloadedDriver).

 Both using the same derby value for osgi.jdbc.driver.name
>>>     service property.
 So pax-jdbc-config sees two factory and so it creates one
>>>    datasource per
 factory.

 That's why it's only when you use derby and actually, the two
>>>    datasource
 services come from the two factories.

 I'm fixing that.

 Regards
 JB

 On 01/02/2019 19:10, Alex Soto wrote:
> 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é
>>>    mailto:j...@nanthrax.net> 
>>> 
>> >> wrote:
>>
>> Indeed, I can reproduce the issue embedded:
>>
>> Name    │ Service Id │ Product  │ Version   │ URL
>>    │ Status
>>
>>>    
>>> ┼┼──┼───┼───┼───
>> querier │ 91 │ Apache Derby │ 10.13.1.1 - (1765088) │
>> jdbc:derby:derby-data/querier │ OK
>> querier │ 92 │ Apache Derby │ 10.13.1.1 - (1765088) │
>> jdbc:derby:derby-data/querier │ OK
>>
>> I will fix that.
>>
>> Regards
>> JB
>>
>> On 01/02/2019 19:01, Alex Soto wrote:
 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

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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) provides:
-
objectClass = [org.osgi.service.jdbc.DataSourceFactory]
osgi.jdbc.driver.class = org.apache.derby.jdbc.AutoloadedDriver
osgi.jdbc.driver.name = derby
osgi.jdbc.driver.version = 10.14.200.1828579
service.bundleid = 52
service.id = 89
service.scope = singleton
karaf@root()> jdbc:ds-create -dn derby -url "jdbc:derby:foo;create=true" foo
karaf@root()> jdbc:ds-list
Name │ Service Id │ Product  │ Version   │ URL
  │ Status
─┼┼──┼───┼┼───
foo  │ 90 │ Apache Derby │ 10.14.2.0 - (1828579) │
jdbc:derby:foo │ OK
karaf@root()> jdbc:ds-info foo
Property   │ Value
───┼──
driver.version │ 10.14.2.0 - (1828579)
service.id │ 90
db.version │ 10.14.2.0 - (1828579)
name   │ foo
db.product │ Apache Derby
url│ jdbc:derby:foo
driver.name│ Apache Derby Embedded JDBC Driver
username   │ APP

It looks good to me ;)

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 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 schrieb 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 / 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 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.
>
> 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é
> mailto:j...@nanthrax.net> >:
>
>    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 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 Derby bundle
>> (org.apache.derby.jdbc.AutoloadedDriver).
>>
>> Both using the same derby value for osgi.jdbc.driver.name
>     service property.
>> So pax-jdbc-config sees two factory and so it creates one
>    datasource per
>> factory.
>>
>> That's why it's only when you use derby and actually, the two
>    datasource
>> services come from the two factories.
>>
>> I'm fixing that.
>>
>> Regards
>> JB
>>
>> On 01/02/2019 19:10, Alex Soto wrote:
>>> 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é
>    mailto:j...@nanthrax.net> 
> 
 >> wrote:

 Indeed, I can reproduce the issue embedded:

 Name    │ Service Id │ Product  │ Version   │ URL
    │ Status

>    
> ┼┼──┼───┼───┼───
 querier │ 91 │ Apache Derby │ 10.13.1.1 - (1765088) │
 jdbc:derby:derby-data/querier │ OK
 querier │ 92 │ Apache De

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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 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 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 schrieb 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 / 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 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.
>>
>> 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é
>> mailto:j...@nanthrax.net> 
>> >:
>>
>>    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 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 Derby bundle
>>> (org.apache.derby.jdbc.AutoloadedDriver).
>>>
>>> Both using the same derby value for osgi.jdbc.driver.name
>>     service property.
>>> So pax-jdbc-config sees two factory and so it creates one
>>    datasource per
>>> factory.
>>>
>>> That's why it's only when you use derby and actually, the two
>>    datasource
>>> services come from the two factories.
>>>
>>> I'm fixing that.
>>>
>>> Regards
>>> JB
>>>
>>> On 01/02/2019 19:10, Alex Soto wrote:
 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é
>>    mailto:j...@nanthrax.net> 
>> 
> >> wrote:
>
> Indeed, I can reproduce the issue embedded:
>
> Name    │ Service Id │ Product  │ Version   │ URL
>    │ Status
>
>>    
>> ┼┼──┼───┼───┼───
> querier │ 91 │ Apache Derby │ 10.13.1.1 - (1765088) │
> jdbc:derby:derby-data/querier │ OK
> querier │ 92 │ Apache Derby │ 10.13.1.1 - (1765088) │
> jdbc:derby:derby-data/querier │ OK
>
> I will fix that.
>
> Regards
> JB
>
> On 01/02/2019 19:01, Alex Soto wrote:
>>> 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é
>>    mailto:j...@nanthrax.net> 
>> 
>>> >
>>> >> wrote:
>>>
>>> Hi,
>>>
>>> I just did a blog where I'm using

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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 pax-jdbc-derby

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 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 schrieb 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 / 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 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.
>
> 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é
> mailto:j...@nanthrax.net> >:
>
>    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 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 Derby bundle
>> (org.apache.derby.jdbc.AutoloadedDriver).
>>
>> Both using the same derby value for osgi.jdbc.driver.name
>     service property.
>> So pax-jdbc-config sees two factory and so it creates one
>    datasource per
>> factory.
>>
>> That's why it's only when you use derby and actually, the two
>    datasource
>> services come from the two factories.
>>
>> I'm fixing that.
>>
>> Regards
>> JB
>>
>> On 01/02/2019 19:10, Alex Soto wrote:
>>> 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é
>    mailto:j...@nanthrax.net> 
> 
 >> wrote:

 Indeed, I can reproduce the issue embedded:

 Name    │ Service Id │ Product  │ Version   │ URL
    │ Status

>    
> ┼┼──┼───┼───┼───
 querier │ 91 │ Apache Derby │ 10.13.1.1 - (1765088) │
 jdbc:derby:derby-data/querier │ OK
 querier │ 92 │ Apache Derby │ 10.13.1.1 - (1765088) │
 jdbc:derby:derby-data/querier │ OK

 I will fix that.

 Regards
 JB

 On 01/02/2019 19:01, Alex Soto wrote:
>> 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é
>    mailto:j...@nanthrax.net> 
> 
>> >
>> >> wrote:
>>
>> 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,
>  

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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 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 schrieb 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 / 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 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.
>
> 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é
> mailto:j...@nanthrax.net> >:
>
>    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 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 Derby bundle
>> (org.apache.derby.jdbc.AutoloadedDriver).
>>
>> Both using the same derby value for osgi.jdbc.driver.name
>     service property.
>> So pax-jdbc-config sees two factory and so it creates one
>    datasource per
>> factory.
>>
>> That's why it's only when you use derby and actually, the two
>    datasource
>> services come from the two factories.
>>
>> I'm fixing that.
>>
>> Regards
>> JB
>>
>> On 01/02/2019 19:10, Alex Soto wrote:
>>> 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é
>    mailto:j...@nanthrax.net> 
> 
 >> wrote:

 Indeed, I can reproduce the issue embedded:

 Name    │ Service Id │ Product  │ Version   │ URL
    │ Status

>    
> ┼┼──┼───┼───┼───
 querier │ 91 │ Apache Derby │ 10.13.1.1 - (1765088) │
 jdbc:derby:derby-data/querier │ OK
 querier │ 92 │ Apache Derby │ 10.13.1.1 - (1765088) │
 jdbc:derby:derby-data/querier │ OK

 I will fix that.

 Regards
 JB

 On 01/02/2019 19:01, Alex Soto wrote:
>> 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é
>    mailto:j...@nanthrax.net> 
> 
>> >
>> >> wrote:
>>
>> 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 derbyclient -url
>    

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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 schrieb 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 / 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 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.

 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é
 mailto:j...@nanthrax.net> >:

    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 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 Derby bundle
> (org.apache.derby.jdbc.AutoloadedDriver).
>
> Both using the same derby value for osgi.jdbc.driver.name
     service property.
> So pax-jdbc-config sees two factory and so it creates one
    datasource per
> factory.
>
> That's why it's only when you use derby and actually, the two
    datasource
> services come from the two factories.
>
> I'm fixing that.
>
> Regards
> JB
>
> On 01/02/2019 19:10, Alex Soto wrote:
>> 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é
    mailto:j...@nanthrax.net> 
>>> >> wrote:
>>>
>>> Indeed, I can reproduce the issue embedded:
>>>
>>> Name    │ Service Id │ Product  │ Version   │ URL
>>>    │ Status
>>>
    
 ┼┼──┼───┼───┼───
>>> querier │ 91 │ Apache Derby │ 10.13.1.1 - (1765088) │
>>> jdbc:derby:derby-data/querier │ OK
>>> querier │ 92 │ Apache Derby │ 10.13.1.1 - (1765088) │
>>> jdbc:derby:derby-data/querier │ OK
>>>
>>> I will fix that.
>>>
>>> Regards
>>> JB
>>>
>>> On 01/02/2019 19:01, Alex Soto wrote:
> 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é
    mailto:j...@nanthrax.net> 
> >
> >> wrote:
>
> 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 derbyclient -url
    jdbc:derby://localhost:1527/foo foo
> And I see only one datasource service:
>
> karaf@root()> jdbc:ds-list
> Name  │ Service Id │ Product  │ Version
  │ URL
>  │ Status
>
    
 ┼┼──

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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 / 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 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.
>>>
>>> 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é
>>> mailto:j...@nanthrax.net> >:
>>>
>>>    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 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 Derby bundle
 (org.apache.derby.jdbc.AutoloadedDriver).

 Both using the same derby value for osgi.jdbc.driver.name
>>>     service property.

 So pax-jdbc-config sees two factory and so it creates one
>>>    datasource per
 factory.

 That's why it's only when you use derby and actually, the two
>>>    datasource
 services come from the two factories.

 I'm fixing that.

 Regards
 JB

 On 01/02/2019 19:10, Alex Soto wrote:
> 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é
>>>    mailto:j...@nanthrax.net> 
>> >> wrote:
>>
>> Indeed, I can reproduce the issue embedded:
>>
>> Name    │ Service Id │ Product  │ Version   │ URL
>>    │ Status
>>
>>>    
>>> ┼┼──┼───┼───┼───
>> querier │ 91 │ Apache Derby │ 10.13.1.1 - (1765088) │
>> jdbc:derby:derby-data/querier │ OK
>> querier │ 92 │ Apache Derby │ 10.13.1.1 - (1765088) │
>> jdbc:derby:derby-data/querier │ OK
>>
>> I will fix that.
>>
>> Regards
>> JB
>>
>> On 01/02/2019 19:01, Alex Soto wrote:
 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é
>>>    mailto:j...@nanthrax.net> 
 >
 >> wrote:

 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 derbyclient -url
>>>    jdbc:derby://localhost:1527/foo foo

 And I see only one datasource service:

 karaf@root()> jdbc:ds-list
 Name  │ Service Id │ Product  │ Version
>>>  │ URL
  │ Status

>>>    
>>> ┼┼──┼───┼───┼───
 foo │ 91 │ Apache Derby │ 10.14.2.0 - (1828579) │
 jdbc:derby://localhost:1527/scheduler │ OK

 In your case, it seems that pax-jdbc-config is in cause, like it
 bootstrap two db.  How to do you provision the datasource cfg
>>>    file ?
 Using a feature or by dropping the file in the etc folder ?

Re: OPS4J Pax JDBC + Derby = Duplicate DataSource

[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 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.
>> 
>> 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é
>> mailto:j...@nanthrax.net>>:
>> 
>>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 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 Derby bundle
>>> (org.apache.derby.jdbc.AutoloadedDriver).
>>> 
>>> Both using the same derby value for osgi.jdbc.driver.name
>> service property.
>>> 
>>> So pax-jdbc-config sees two factory and so it creates one
>>datasource per
>>> factory.
>>> 
>>> That's why it's only when you use derby and actually, the two
>>datasource
>>> services come from the two factories.
>>> 
>>> I'm fixing that.
>>> 
>>> Regards
>>> JB
>>> 
>>> On 01/02/2019 19:10, Alex Soto wrote:
 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é
>>mailto:j...@nanthrax.net>
> >> wrote:
> 
> Indeed, I can reproduce the issue embedded:
> 
> Name│ Service Id │ Product  │ Version   │ URL
>│ Status
> 
>>
>> ┼┼──┼───┼───┼───
> querier │ 91 │ Apache Derby │ 10.13.1.1 - (1765088) │
> jdbc:derby:derby-data/querier │ OK
> querier │ 92 │ Apache Derby │ 10.13.1.1 - (1765088) │
> jdbc:derby:derby-data/querier │ OK
> 
> I will fix that.
> 
> Regards
> JB
> 
> On 01/02/2019 19:01, Alex Soto wrote:
>>> 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é
>>mailto:j...@nanthrax.net>
>>> >
>>> >> wrote:
>>> 
>>> 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 derbyclient -url
>>jdbc:derby://localhost:1527/foo foo
>>> 
>>> And I see only one datasource service:
>>> 
>>> karaf@root()> jdbc:ds-list
>>> Name  │ Service Id │ Product  │ Version
>>  │ URL
>>>  │ Status
>>> 
>>
>> ┼┼──┼───┼───┼───
>>> foo │ 91 │ Apache Derby │ 10.14.2.0 - (1828579) │
>>> jdbc:derby://localhost:1527/scheduler │ OK
>>> 
>>> In your case, it seems that pax-jdbc-config is in cause, like it
>>> bootstrap two db.  How to do you provision the datasource cfg
>>file ?
>>> Using a feature or by dropping the file in the etc folder ?
>>> 
>>> I will check when my build is complete.
>>> 
>>> Regards
>>> JB
>>> 
>>> On 01/02/2019 18:48, Alex Soto wrote:
 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 i

Re: Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

[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
4.2.3-SNAPSHOT:
[INFO]
[INFO] Apache Karaf :: Examples :: Profile  SUCCESS [
1.184 s]
[INFO] Apache Karaf :: Examples :: Profile :: Registry  SUCCESS [
0.511 s]
[INFO] Apache Karaf :: Examples :: Profile :: Dynamic Assembly SUCCESS [
 8.058 s]
[INFO] Apache Karaf :: Examples :: Profile :: Static Assembly SUCCESS [
10.768 s]
[INFO]

[INFO] BUILD SUCCESS
[INFO]


Then, I started the static profile based distribution:

./karaf-profile-example-static-4.2.3-SNAPSHOT/bin/karaf

I have an issue with ActiveMQ (I gonna fix that), but no problem with
SCR/ConfigAdmin.

Regards
JB

On 04/02/2019 15:32, Michal Dabrowski wrote:
> 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
> (https://github.com/apache/karaf/tree/karaf-4.2.2/examples/karaf-profile-example/karaf-profile-example-static)
> 
> During startup it prints in logs:
> 
> 2019-02-04T15:17:35,403 | ERROR | FelixDispatchQueue | metatype   
>  
> | 35 - org.apache.felix.metatype - 1.2.2 | FrameworkEvent ERROR -
> org.apache.felix.metatype
> org.osgi.framework.ServiceException: Service factory exception:
> org/osgi/service/cm/ManagedService
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:352)
> ~[?:?]
> at
> org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247)
> ~[?:?]
> at
> org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:350)
> ~[?:?]
> at org.apache.felix.framework.Felix.getService(Felix.java:3737)
> ~[?:?]
> at
> org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470)
> ~[?:?]
> at
> org.apache.felix.metatype.internal.ManagedServiceTracker.addingService(ManagedServiceTracker.java:52)
> ~[?:?]
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
> ~[?:?]
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
> ~[?:?]
> at
> org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
> ~[?:?]
> at
> org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) ~[?:?]
> at
> org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
> ~[?:?]
> at
> org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
> ~[?:?]
> at
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
> ~[?:?]
> at
> org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
> ~[?:?]
> at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4595) ~[?:?]
> at org.apache.felix.framework.Felix.registerService(Felix.java:3587)
> ~[?:?]
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
> ~[?:?]
> at
> org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:322)
> ~[?:?]
> at
> org.apache.felix.scr.impl.config.ScrConfigurationImpl.start(ScrConfigurationImpl.java:122)
> ~[?:?]
> at org.apache.felix.scr.impl.Activator.start(Activator.java:100)
> ~[?:?]
> at
> org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
> ~[?:?]
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
> ~[?:?]
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
> ~[?:?]
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) ~[?:?]
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
> ~[?:?]
> at java.lang.Thread.run(Thread.java:748) [?:?]
> Caused by: java.lang.NoClassDefFoundError:
> org/osgi/service/cm/ManagedService
> at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2410)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2194)
> ~[?:?]
> at
> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDel

Re: Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

[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
(https://github.com/apache/karaf/tree/karaf-4.2.2/examples/karaf-profile-example/karaf-profile-example-static)

During startup it prints in logs:

2019-02-04T15:17:35,403 | ERROR | FelixDispatchQueue | metatype 
   
| 35 - org.apache.felix.metatype - 1.2.2 | FrameworkEvent ERROR -
org.apache.felix.metatype
org.osgi.framework.ServiceException: Service factory exception:
org/osgi/service/cm/ManagedService
at
org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:352)
~[?:?]
at
org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247)
~[?:?]
at
org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:350)
~[?:?]
at org.apache.felix.framework.Felix.getService(Felix.java:3737)
~[?:?]
at
org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470)
~[?:?]
at
org.apache.felix.metatype.internal.ManagedServiceTracker.addingService(ManagedServiceTracker.java:52)
~[?:?]
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
~[?:?]
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
~[?:?]
at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
~[?:?]
at
org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) ~[?:?]
at
org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
~[?:?]
at
org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
~[?:?]
at
org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
~[?:?]
at
org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
~[?:?]
at
org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4595) ~[?:?]
at org.apache.felix.framework.Felix.registerService(Felix.java:3587)
~[?:?]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
~[?:?]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:322)
~[?:?]
at
org.apache.felix.scr.impl.config.ScrConfigurationImpl.start(ScrConfigurationImpl.java:122)
~[?:?]
at org.apache.felix.scr.impl.Activator.start(Activator.java:100)
~[?:?]
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
~[?:?]
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
~[?:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
~[?:?]
at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) ~[?:?]
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
~[?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.lang.NoClassDefFoundError:
org/osgi/service/cm/ManagedService
at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2410)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2194)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
at
org.apache.felix.scr.impl.config.ScrManagedServiceServiceFactory.getService(ScrManagedServiceServiceFactory.java:47)
~[?:?]
at
org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347)
~[?:?]
... 25 more
Caused by: java.lang.ClassNotFoundException:
org.osgi.service.cm.ManagedService not found by org.apache.felix.scr [36]


I think it is because:

Apache Felix Declarative Services (36) bundle imports: 

Import-Package = 
org.osgi.service.cm;resolution:=optional;version="[1.6,2)", 
(...) 

and Static ConfigAdmin headers: 

Apache Karaf :: OSGi Services :: Static ConfigAdmin (5) 
--- 
Build-Jdk = 1.8.0_144 
Manifest-Version = 1.0 

Bundle-Activator = org.apache.karaf.services.staticcm.Activator 
Bundle-Description = Static ConfigAdmin Service 
Bundle-DocURL = http://karaf.apache.org/
Bundle-License 

Re: Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

[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
(https://github.com/apache/karaf/tree/karaf-4.2.2/examples/karaf-profile-example/karaf-profile-example-static)
- mvn clean install + bin/karaf.

During startup it prints in karaf.log:

2019-02-04T15:17:35,403 | ERROR | FelixDispatchQueue | metatype 
   
| 35 - org.apache.felix.metatype - 1.2.2 | FrameworkEvent ERROR -
org.apache.felix.metatype
org.osgi.framework.ServiceException: Service factory exception:
org/osgi/service/cm/ManagedService
at
org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:352)
~[?:?]
at
org.apache.felix.framework.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:247)
~[?:?]
at
org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:350)
~[?:?]
at org.apache.felix.framework.Felix.getService(Felix.java:3737)
~[?:?]
at
org.apache.felix.framework.BundleContextImpl.getService(BundleContextImpl.java:470)
~[?:?]
at
org.apache.felix.metatype.internal.ManagedServiceTracker.addingService(ManagedServiceTracker.java:52)
~[?:?]
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:941)
~[?:?]
at
org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:870)
~[?:?]
at
org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)
~[?:?]
at
org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229) ~[?:?]
at
org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:901)
~[?:?]
at
org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990)
~[?:?]
at
org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838)
~[?:?]
at
org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545)
~[?:?]
at
org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4595) ~[?:?]
at org.apache.felix.framework.Felix.registerService(Felix.java:3587)
~[?:?]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348)
~[?:?]
at
org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:322)
~[?:?]
at
org.apache.felix.scr.impl.config.ScrConfigurationImpl.start(ScrConfigurationImpl.java:122)
~[?:?]
at org.apache.felix.scr.impl.Activator.start(Activator.java:100)
~[?:?]
at
org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:697)
~[?:?]
at org.apache.felix.framework.Felix.activateBundle(Felix.java:2240)
~[?:?]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2146)
~[?:?]
at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) ~[?:?]
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
~[?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.lang.NoClassDefFoundError:
org/osgi/service/cm/ManagedService
at java.lang.ClassLoader.defineClass1(Native Method) ~[?:?]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.defineClass(BundleWiringImpl.java:2410)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2194)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1607)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl.access$200(BundleWiringImpl.java:80)
~[?:?]
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2053)
~[?:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:?]
at
org.apache.felix.scr.impl.config.ScrManagedServiceServiceFactory.getService(ScrManagedServiceServiceFactory.java:47)
~[?:?]
at
org.apache.felix.framework.ServiceRegistrationImpl.getFactoryUnchecked(ServiceRegistrationImpl.java:347)
~[?:?]
... 25 more
Caused by: java.lang.ClassNotFoundException:
org.osgi.service.cm.ManagedService not found by org.apache.felix.scr [36]

I think it is because:

Apache Felix Declarative Services (36) bundle: 
Import-Package = 
org.osgi.service.cm;resolution:=optional;version="[1.6,2)", 
(...) 

and Static ConfigAdmin headers: 

Apache Karaf :: OSGi Services :: Static ConfigAdmin (5) 
--- 
(...)
Export-Service = 
org.osgi.service.cm.ConfigurationAdmin 
Require-Capability = 
osgi.ee;filter:=(&(osgi.ee=JavaSE)(version=1.8)) 

DynamicImport-Package = 
org.

Re: Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

[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 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 versions incompatibility for package org.osgi.service.cm
> since Karaf 4.2.1. At least using a static mode. I have the same issue when
> I try provided example (karaf-profile-example-static). I used Karaf 4.0.4
> before and it worked fine with SCR.
> Is it a bug or am I missing something?
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

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

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



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

[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 exceptions: 
> 
> 
> 
> I've checked the Apache Felix Declarative Services (36) bundle imports:
> 
> 
> 
> and Static ConfigAdmin headers:
> 
> 
> 
> It seems there is versions incompatibility for package org.osgi.service.cm
> since Karaf 4.2.1. At least using a static mode. I have the same issue when
> I try provided example (karaf-profile-example-static). I used Karaf 4.0.4
> before and it worked fine with SCR.
> Is it a bug or am I missing something?
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

[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: 
> 
> 
> 
> I've checked the Apache Felix Declarative Services (36) bundle imports:
> 
> 
> 
> and Static ConfigAdmin headers:
> 
> 
> 
> It seems there is versions incompatibility for package org.osgi.service.cm
> since Karaf 4.2.1. At least using a static mode. I have the same issue when
> I try provided example (karaf-profile-example-static). I used Karaf 4.0.4
> before and it worked fine with SCR.
> Is it a bug or am I missing something?
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

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

[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 example, I use karaf-maven-plugin to build karaf
> assembly and I have an Ignite profile listed in my startupProfiles:
> 
>   
> my-ignite-profile
>   
> 
> my-ignite-profile contains ignite-core dependency that uses some low level
> stuff from com.sun.management. Building of the assembly fails during startup
> stage (Startup stage -> Resolving startup features and bundles):
> 
> (...)
> [INFO] Startup stage
> [INFO]Loading startup repositories
> [INFO]Resolving startup features and bundles
> (...)
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  6.930 s
> [INFO] Finished at: 2019-02-04T14:19:24+01:00
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.karaf.tooling:karaf-maven-plugin:4.2.2:assembly
> (process-resources) on project karaf4: Unable to build assembly: Unable to
> resolve root: missing requirement 
> (...)
> caused by: Unable to resolve org.apache.ignite.ignite-core/2.7.0: missing
> requirement [org.apache.ignite.ignite-core/2.7.0] osgi.wiring.package;
> filter:="(osgi.wiring.package=com.sun.management)"
> 
> The problem is that overriding of jre.properties file happens after the
> startup stage.
> 
> I tried:
> * assembly-property-edits.xml file
> * jre.properties file in resources folder
> 
> all of these methods changes jre.properties file after startup stage. I
> found connected jira https://issues.apache.org/jira/browse/KARAF-5781 that
> changed order of applying assembly-property-edits.xml file. The earlier way
> worked in my scenario.
> 
> Is there any way to set jre.properties before startup stage?
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Karaf 4.2.2 Set jre.properties before assembly building startup stage

[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
  

my-ignite-profile contains ignite-core dependency that uses some low level
stuff from com.sun.management. Building of the assembly fails during startup
stage (Startup stage -> Resolving startup features and bundles):

(...)
[INFO] Startup stage
[INFO]Loading startup repositories
[INFO]Resolving startup features and bundles
(...)
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time:  6.930 s
[INFO] Finished at: 2019-02-04T14:19:24+01:00
[INFO]

[ERROR] Failed to execute goal
org.apache.karaf.tooling:karaf-maven-plugin:4.2.2:assembly
(process-resources) on project karaf4: Unable to build assembly: Unable to
resolve root: missing requirement 
(...)
caused by: Unable to resolve org.apache.ignite.ignite-core/2.7.0: missing
requirement [org.apache.ignite.ignite-core/2.7.0] osgi.wiring.package;
filter:="(osgi.wiring.package=com.sun.management)"

The problem is that overriding of jre.properties file happens after the
startup stage.

I tried:
* assembly-property-edits.xml file
* jre.properties file in resources folder

all of these methods changes jre.properties file after startup stage. I
found connected jira https://issues.apache.org/jira/browse/KARAF-5781 that
changed order of applying assembly-property-edits.xml file. The earlier way
worked in my scenario.

Is there any way to set jre.properties before startup stage?



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Karaf 4.2.2 Felix Declarative Services + Static ConfigAdmin

[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 versions incompatibility for package org.osgi.service.cm
since Karaf 4.2.1. At least using a static mode. I have the same issue when
I try provided example (karaf-profile-example-static). I used Karaf 4.0.4
before and it worked fine with SCR.
Is it a bug or am I missing something?



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html