Re: Karaf - how to see details re 'Refreshing bundles ...'

Which version of karaf ? In karaf >= 4, the reason should be printed if you use the --verbose flag on the command. 2016-10-06 18:13 GMT+02:00 Martin Lichtin : > Hi > > I sometimes see this "Refreshing bundles ... " output when installing a > feature. E.g.: > > Refreshing

Re: Karaf - how to see details re 'Refreshing bundles ...'

Hi Martin, Analyzing the log you will be able to find the first bundles causing the refresh (probably due to optional import or to satisfy another kind of requirement). Can you share your log ? I will take a look. Thanks, Regards JB On 10/06/2016 06:13 PM, Martin Lichtin wrote: Hi I

Karaf - how to see details re 'Refreshing bundles ...'

Hi I sometimes see this "Refreshing bundles ... " output when installing a feature. E.g.: Refreshing bundles org.apache.servicemix.bundles.jaxb-impl (80) Can you help me figure out what is causing the refresh? There must a logic somewhere. Ideally, is there a debug log that I can turn on to

Re: Question regarding feature resolution

Definitely not ;-) https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/service/Overrides.java#L97 2016-10-06 16:56 GMT+02:00 Benjamin Graf : > Hi Guillaume, > > btw. is override generic enough to work on symbolic name

Re: Question regarding feature resolution

Hi Guillaume, blacklisting was a good and cheap idea. But I think this feature leaks documentation I only found the commits in git to look how to use it. :-) Thx Benjamin Am 06.10.2016 um 16:14 schrieb Guillaume Nodet: > I suppose one easy way is to simply blacklist the jms api 1.1 bundles, >

Re: Question regarding feature resolution

I suppose one easy way is to simply blacklist the jms api 1.1 bundles, so that they will not be included in any resolution, or use an override to automatically use jms 2.0 instead. 2016-10-06 16:09 GMT+02:00 Benjamin Graf : > Hello, > > I'm actually playing with

Re: Question regarding feature resolution

Hi Benjamin, The feature resolver will try to find the feature matching the requirements, so it's not necessary the "highest" one in the range. For instance, if you have another feature installing spring-jms 3.2.18, and then you install your feature containing sring-jms feature with version

Question regarding feature resolution

Hello, I'm actually playing with integrating ActiveMQ Artemis (1.5-SNAPSHOT) with Camel (2.17.3) on Karaf (4.0.8-SNAPSHOT). To get some conflicts workarounded I'm deleting jms 1.1 API bundle from camel-jms feature (2.17.3) and also from latest spring-jms feature (4.2.5.RELEASE_1). But the jms

RE: Strange issue on strange use case

Yes it's a kind of split package but I didn't define a merge policy (I don't know what a merge policy is). Is it possible to do so with the maven-bundle-plugin? Regards, JP -Message d'origine- De : Jean-Baptiste Onofré [mailto:j...@nanthrax.net] Envoyé : jeudi 6 octobre 2016 15:42 À :

Re: Strange issue on strange use case

I think we are in the case of a split package. Did you define any merge policy ? Regards JB On 10/06/2016 03:40 PM, CLEMENT Jean-Philippe wrote: I renamed the package of b.jar to something like "other.package". All is back to normal even with BF. So it seems there is a bug somewhere. In

RE: Strange issue on strange use case

I renamed the package of b.jar to something like "other.package". All is back to normal even with BF. So it seems there is a bug somewhere. In OSGi, are several packages with the same name (but with different content) allowed? JP -Message d'origine- De : CLEMENT Jean-Philippe

A way to extend/parent "assembly-property-edits.xml"

Hi, I am currently building several Apache Karaf distributions and would like to use a modular Maven build for that. It is possible with Maven to inherit and extend configuration element so that for example a child module can enhance the list of "bootFeatures" from its parent. However I haven't

Strange issue on strange use case

Hello, I experience a strange issue on a strange use case using Karaf 4.0.7. I have: * a bundle A which wraps a jar "a.jar" and exposes a package "some.package" (which is inside the "a.jar") * a bundle B which contains and use a jar "b.jar" which contains a package "some.package" (same package

Re: Karaf Datasource Passwords

Hi Vince, you are mixing up stuff. You're encryptor in this case works as an extension to the defined property placeholder. Your're trying to decrypt the properties to initialize the encryptor. Split up the encryptor stuff and the datasource stuff. Register a osgi service for StringEncryptor as