Bundle refresh when installing/uninstalling kar

2020-10-29 Thread DUTERTRY Nicolas
Hi,

When I install a new kar, Karaf refreshes bundles and it causes some issues for 
me because too many bundles are restarted.
There is an option in org.apache.karaf.kar.cfg to disable bundle refresh : 
noAutoRefreshBundles=true

It works fine, but unfortunately when I uninstall a kar, Karaf still refreshes 
bundles no matter what the option value is.
Is it possible to disable bundle refresh when uninstalling a kar ?

Regards,
--
Nicolas Dutertry
Sopra HR Software - http://www.soprahr.com/



Karaf 4.1.4 race condition with javax.annotation and guava

2020-10-29 Thread Igor Raizin
Hello all,

Can you, please, advise how to resolve this kind of reca conditions during
the startup of the karaf?
We're using cxf 3.1.9 and guava 19.0, karaf 4.1.4, jdk8
CXF is installing the 
mvn:javax.annotation/javax.annotation-api/1.2
And guava 19.0 bundle headers are:

Export-Package =

com.google.common.net
;uses:="javax.annotation,com.google.common.base,com.google.common.hash,
com.google.common.io
,com.google.common.primitives,com.google.common.collect,com.google.common.escape";version=19.0.0,

com.google.common.html;uses:="com.google.common.escape,javax.annotation";version=19.0.0,

com.google.common.collect;uses:="com.google.common.base,javax.annotation,com.google.common.primitives,com.google.common.math";version=19.0.0,

com.google.common.primitives;uses:="javax.annotation,com.google.common.base,sun.misc";version=19.0.0,

com.google.common.base;uses:=javax.annotation;version=19.0.0,

com.google.common.escape;uses:="com.google.common.base,javax.annotation";version=19.0.0,

com.google.common.cache;uses:="com.google.common.collect,com.google.common.util.concurrent,javax.annotation,com.google.common.base,com.google.common.primitives,sun.misc";version=19.0.0,

com.google.common.eventbus;uses:="com.google.common.base,com.google.common.collect,com.google.common.util.concurrent,javax.annotation,com.google.common.cache,com.google.common.reflect";version=19.0.0,

com.google.common.util.concurrent;uses:="com.google.common.base,javax.annotation,sun.misc,com.google.common.collect,com.google.common.math,com.google.common.primitives";version=19.0.0,

com.google.common.hash;uses:="com.google.common.primitives,com.google.common.base,javax.annotation,com.google.common.math";version=19.0.0,

com.google.common.io
;uses:="javax.annotation,com.google.common.base,com.google.common.math,com.google.common.hash,com.google.common.collect,com.google.common.primitives";version=19.0.0,

com.google.common.xml;uses:="com.google.common.escape,javax.annotation";version=19.0.0,

com.google.common.reflect;uses:="javax.annotation,com.google.common.base,com.google.common.collect,com.google.common.primitives";version=19.0.0,

com.google.common.math;uses:="com.google.common.base,com.google.common.primitives,javax.annotation";version=19.0.0,

com.google.common.annotations;version=19.0.0

Import-Package =

javax.annotation;resolution:=optional,

sun.misc;resolution:=optional

*The error on feature install: *


*Chain 1:*  com.test.example.rest.core [com.test.example.rest.core [446](R
446.0)]
import:
(&(osgi.wiring.package=javax.annotation)(version>=1.2.0)(!(version>=2.0.0)))
 |
export: osgi.wiring.package: javax.annotation
  javax.annotation-api [javax.annotation-api [168](R 168.0)]

*Chain 2:*  com.test.example.rest.core [com.test.example.rest.core [446](R
446.0)]
import:
(&(osgi.wiring.package=com.test.example.exec.api)(version>=7.0.0)(!(version>=8.0.0)))
 |
export: osgi.wiring.package=com.test.example.exec.api;
uses:=com.test.example.context.api
  com.test.example.exec.api [com.test.example.exec.api [443](R 443.0)]
import:
(&(osgi.wiring.package=com.test.example.context.api)(version>=7.0.0)(!(version>=8.0.0)))
 |
export: osgi.wiring.package=com.test.example.context.api;
uses:=com.test.example.common.entity
  com.test.example.context.api [com.test.example.context.api [441](R 441.0)]
import:
(&(osgi.wiring.package=com.test.example.common.entity)(version>=6.0.0)(!(version>=7.0.0)))
 |
export: osgi.wiring.package=com.test.example.common.entity;
uses:=com.google.common.base
  com.test.example.common [com.test.example.common [398](R 398.0)]
import:
(&(osgi.wiring.package=com.google.common.base)(version>=19.0.0)(!(version>=20.0.0)))
 |
export: osgi.wiring.package=com.google.common.base;
uses:=javax.annotation
  com.google.guava [com.google.guava [157](R 157.0)]
import: (osgi.wiring.package=javax.annotation)


Thanks for the help!

Regards,
Igor


Re: Issue running v4.2.10 with JDK 14.0.2 (Unsupported class file major version 58)

2020-10-29 Thread Oleg Cohen
Thank you, JB!

I compiled my code with 11.0.7 and Karaf ran with 14.0.2

Best,
Oleg


> On Oct 29, 2020, at 1:49 AM, Jean-Baptiste Onofre  wrote:
> 
> Hi,
> 
> I have to check the JDK used to compile spifly. Not sure it’s compatible with 
> JDK14.
> 
> When you say you compile with JDK 14, is it Karaf or your application ?
> 
> Regards
> JB
> 
>> Le 29 oct. 2020 à 02:37, Oleg Cohen > > a écrit :
>> 
>> 
>> Greetings,
>> 
>> I was wondering if anyone else ran into the same issue. All runs well for me 
>> on JDK 11.0.7
>> 
>> When I do a new clean install on JDK 14.0.2, I get the following error when 
>> installing bundles:
>> 
>> java.lang.IllegalArgumentException: Unsupported class file major version 58
>> 
>> A rather long stack trace is below. I am trying to figure how to identify 
>> the culprit is and resolve the issue.
>> 
>> ASM version I have is 8.0.1
>> 
>> Thank you!
>> Oleg
>> 
>> 
>> 
>> 2020-10-28T21:26:17,875 | ERROR | FelixDispatchQueue | FrameworkEvent
>>| 123 - org.apache.aries.spifly.dynamic.bundle - 1.2.0 | 
>> FrameworkEvent ERROR
>> java.lang.IllegalArgumentException: Unsupported class file major version 58
>>  at org.objectweb.asm.ClassReader.(ClassReader.java:184) ~[?:?]
>>  at org.objectweb.asm.ClassReader.(ClassReader.java:166) ~[?:?]
>>  at org.objectweb.asm.ClassReader.(ClassReader.java:152) ~[?:?]
>>  at org.objectweb.asm.ClassReader.(ClassReader.java:273) ~[?:?]
>>  at 
>> org.apache.aries.spifly.dynamic.OSGiFriendlyClassWriter.getCommonSuperClass(OSGiFriendlyClassWriter.java:81)
>>  ~[?:?]
>>  at org.objectweb.asm.SymbolTable.addMergedType(SymbolTable.java:1198) 
>> ~[?:?]
>>  at org.objectweb.asm.Frame.merge(Frame.java:1294) ~[?:?]
>>  at org.objectweb.asm.Frame.merge(Frame.java:1175) ~[?:?]
>>  at 
>> org.objectweb.asm.MethodWriter.computeAllFrames(MethodWriter.java:1617) 
>> ~[?:?]
>>  at org.objectweb.asm.MethodWriter.visitMaxs(MethodWriter.java:1553) 
>> ~[?:?]
>>  at org.objectweb.asm.MethodVisitor.visitMaxs(MethodVisitor.java:768) 
>> ~[?:?]
>>  at 
>> org.objectweb.asm.commons.LocalVariablesSorter.visitMaxs(LocalVariablesSorter.java:147)
>>  ~[?:?]
>>  at org.objectweb.asm.ClassReader.readCode(ClassReader.java:2426) ~[?:?]
>>  at org.objectweb.asm.ClassReader.readMethod(ClassReader.java:1275) 
>> ~[?:?]
>>  at org.objectweb.asm.ClassReader.accept(ClassReader.java:679) ~[?:?]
>>  at org.objectweb.asm.ClassReader.accept(ClassReader.java:391) ~[?:?]
>>  at 
>> org.apache.aries.spifly.dynamic.ClientWeavingHook.weave(ClientWeavingHook.java:60)
>>  ~[?:?]
>>  at 
>> org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)
>>  ~[?:?]
>>  at 
>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2465)
>>  ~[?:?]
>>  at 
>> org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2152)
>>  ~[?:?]
>>  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:522) ~[?:?]
>>  at 
>> org.apache.felix.framework.BundleWiringImpl.getClassByDelegation(BundleWiringImpl.java:1414)
>>  ~[?:?]
>>  at 
>> org.apache.felix.framework.BundleWiringImpl.searchImports(BundleWiringImpl.java:1660)
>>  ~[?:?]
>>  at 
>> org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1590)
>>  ~[?:?]
>>  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:522) ~[?:?]
>>  at java.lang.Class.getDeclaredConstructors0(Native Method) ~[?:?]
>>  at java.lang.Class.privateGetDeclaredConstructors(Class.java:3215) 
>> ~[?:?]
>>  at java.lang.Class.getConstructor0(Class.java:3420) ~[?:?]
>>  at java.lang.Class.getConstructor(Class.java:2165) ~[?:?]
>>  at java.util.ServiceLoader$1.run(ServiceLoader.java:662) ~[?:?]
>>  at java.util.ServiceLoader$1.run(ServiceLoader.java:659) ~[?:?]
>>  at 
>> java.security.AccessController.doPrivileged(AccessController.java:554) ~[?:?]
>>  at java.util.ServiceLoader.getConstructor(ServiceLoader.java:670) ~[?:?]
>>  at 
>> java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1234)
>>  ~[?:?]
>>  at 
>> java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1266)
>>  ~[?:?]
>>  at 

Re: No component with id 'blueprintBundle' could be found when stopping/restarting a bundle with Camel

2020-10-29 Thread Oleg Cohen
Thank you, JB!

> On Oct 29, 2020, at 1:51 AM, Jean-Baptiste Onofre  wrote:
> 
> Hi,
> 
> blueprintBundle is a implicite blueprint bean containing the bundle context.
> 
> This bean is used in the camel blueprint. It seems that the bean is destroyed 
> before camel context, causing this issue.
> It’s an improvement to do on camel blueprint to manage the cycle.
> I will create a Jira and fix that at Camel.
> 
> Regards
> JB
> 
>> Le 29 oct. 2020 à 03:45, Oleg Cohen > > a écrit :
>> 
>> Greetings,
>> 
>> Looking for help with this error. I have a bundle that has a camel route. 
>> Every time I stop/restart the bundle I see the following error:
>> 
>> org.osgi.service.blueprint.container.NoSuchComponentException: No component 
>> with id 'blueprintBundle' could be found
>> 
>> This route is very small and it is initialized via a custom builder like 
>> this:
>> 
>> 
>> 
>> A full stack trace is below.
>> 
>> Would appreciate any help/insight on this!
>> 
>> Thank you,
>> Oleg
>> 
>> 
>> 2020-10-28T22:40:14,531 | INFO  | pipe-restart infocus.core.demo | 
>> DefaultShutdownStrategy  | 126 - org.apache.camel.camel-base - 3.6.0 
>> | Graceful shutdown of 1 routes completed in 0 seconds
>> 2020-10-28T22:40:14,536 | INFO  | pipe-restart infocus.core.demo | 
>> CoreTypeConverterRegistry| 126 - org.apache.camel.camel-base - 3.6.0 
>> | TypeConverterRegistry utilization[noop=0, attempts=2, hits=2, misses=0, 
>> failures=0] mappings[total=216, misses=0]
>> 2020-10-28T22:40:14,536 | WARN  | pipe-restart infocus.core.demo | 
>> AbstractCamelContext | 126 - org.apache.camel.camel-base - 3.6.0 
>> | Error occurred while stopping lifecycle strategies. This exception will be 
>> ignored.
>> org.osgi.service.blueprint.container.NoSuchComponentException: No component 
>> with id 'blueprintBundle' could be found
>>  at 
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.getComponentInstance(BlueprintContainerImpl.java:805)
>>  ~[?:?]
>>  at 
>> org.apache.camel.blueprint.BlueprintContainerBeanRepository.lookupByType(BlueprintContainerBeanRepository.java:104)
>>  ~[?:?]
>>  at 
>> org.apache.camel.blueprint.BlueprintContainerBeanRepository.lookupByType(BlueprintContainerBeanRepository.java:100)
>>  ~[?:?]
>>  at 
>> org.apache.camel.blueprint.BlueprintContainerBeanRepository.findByType(BlueprintContainerBeanRepository.java:94)
>>  ~[?:?]
>>  at 
>> org.apache.camel.support.DefaultRegistry.findByType(DefaultRegistry.java:203)
>>  ~[!/:3.6.0]
>>  at 
>> org.apache.camel.impl.engine.OnCamelContextLifecycleStrategy.onContextStopped(OnCamelContextLifecycleStrategy.java:125)
>>  ~[!/:3.6.0]
>>  at 
>> org.apache.camel.impl.engine.AbstractCamelContext.doStop(AbstractCamelContext.java:2941)
>>  [!/:3.6.0]
>>  at 
>> org.apache.camel.support.service.BaseService.stop(BaseService.java:156) 
>> [!/:3.6.0]
>>  at 
>> org.apache.camel.impl.engine.AbstractCamelContext.stop(AbstractCamelContext.java:2453)
>>  [!/:3.6.0]
>>  at 
>> org.apache.camel.blueprint.BlueprintCamelContext.destroy(BlueprintCamelContext.java:145)
>>  [!/:3.6.0]
>>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
>> ~[?:?]
>>  at 
>> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>  ~[?:?]
>>  at 
>> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>  ~[?:?]
>>  at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
>>  at 
>> org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:337)
>>  [!/:1.10.2]
>>  at 
>> org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:835) 
>> [!/:1.10.2]
>>  at 
>> org.apache.aries.blueprint.container.BeanRecipe.destroy(BeanRecipe.java:742) 
>> [!/:1.10.2]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintRepository.destroy(BlueprintRepository.java:434)
>>  [!/:1.10.2]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.destroyComponents(BlueprintContainerImpl.java:778)
>>  [!/:1.10.2]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.tidyupComponents(BlueprintContainerImpl.java:987)
>>  [!/:1.10.2]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:923)
>>  [!/:1.10.2]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintExtender$3.run(BlueprintExtender.java:336)
>>  [!/:1.10.2]
>>  at 
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
>>  at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintExtender.destroyContainer(BlueprintExtender.java:357)
>>  [!/:1.10.2]
>>  at 
>> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:249)
>>  [!/:1.10.2]
>>  at 
>> 

Re: Strange 4.2.9/4.2.10 mixup when adding camel repos

2020-10-29 Thread Oleg Cohen
I fixed it by blacklisting repos in etc/org.apache.karaf.features.xml


mvn:org.ops4j.pax.cdi/pax-cdi-features/1.0.0/xml/features

mvn:org.ops4j.pax.web/pax-web-features/7.2.16/xml/features

mvn:org.apache.karaf.features/spring-legacy/4.2.9/xml/features

mvn:org.apache.karaf.features/standard/4.2.9/xml/features


mvn:org.apache.karaf.features/standard/[4,5)/xml/features

This removed the issues.

> On Oct 29, 2020, at 5:47 AM, John Taylor  wrote:
> 
> Hi,
> I also see this with camel 3.4.4.
> 
> Both camel 3.6.0 and 3.4.4 features.xml [1] have spring-legacy/4.2.9 
> 
>
>mvn:org.apache.karaf.features/spring-legacy/4.2.9/xml/features
>
> 
> So I guess that would be why?
> -John
> 
> [1] 
> https://repo1.maven.org/maven2/org/apache/camel/karaf/apache-camel/3.4.4/apache-camel-3.4.4-features.xml
>  
> 
> On Thu, Oct 29, 2020 at 5:47 AM Jean-Baptiste Onofre  > wrote:
> Hi,
> 
> Let me try. AFAIR, Camel uses a range, so it should be fine.
> 
> Regards
> JB
> 
>> Le 28 oct. 2020 à 12:04, Oleg Cohen > > a écrit :
>> 
>> Greetings,
>> 
>> I am migrating to Karaf v4.2.10. Starting from a clean container.
>> 
>> If I install feature war all works fine.
>> 
>> After I add two camel repos:
>> 
>>  feature:repo-add 
>> mvn:org.apache.camel.karaf/apache-camel/RELEASE/xml/features   
>>  feature:repo-add 
>> mvn:org.apache-extras.camel-extra.karaf/camel-extra/RELEASE/xml/features
>> 
>> I see a number of errors when installing war (or any other feature). I 
>> noticed that there are commands to install 
>> org.apache.karaf.scr.management/4.2.9 along with 4.2.10
>> 
>> 2020-10-28T06:59:33,762 | INFO  | features-3-thread-1 | CommandExtension 
>> | 37 - org.apache.karaf.shell.core - 4.2.10 | Registering 
>> commands for bundle org.apache.karaf.scr.state/4.2.10
>> 2020-10-28T06:59:33,762 | INFO  | features-3-thread-1 | FeaturesServiceImpl  
>> | 11 - org.apache.karaf.features.core - 4.2.10 |   
>> org.apache.karaf.scr.management/4.2.9
>> 2020-10-28T06:59:33,772 | INFO  | features-3-thread-1 | 
>> ServiceComponentRuntimeMBeanImpl | 59 - org.apache.karaf.scr.management - 
>> 4.2.9 | Activating the Apache Karaf ServiceComponentRuntime MBean
>> 2020-10-28T06:59:33,773 | INFO  | features-3-thread-1 | FeaturesServiceImpl  
>> | 11 - org.apache.karaf.features.core - 4.2.10 |   
>> org.apache.karaf.scr.management/4.2.10
>> 
>> The errors are JMX based:
>> 
>> 2020-10-28T06:59:33,779 | INFO  | features-3-thread-1 | 
>> ServiceComponentRuntimeMBeanImpl | 60 - org.apache.karaf.scr.management - 
>> 4.2.10 | Activating the Apache Karaf ServiceComponentRuntime MBean
>> 2020-10-28T06:59:33,780 | ERROR | features-3-thread-1 | 
>> ServiceComponentRuntimeMBeanImpl | 60 - org.apache.karaf.scr.management - 
>> 4.2.10 | Exception registering the SCR Management MBean: 
>> org.apache.karaf:type=scr,name=root
>> javax.management.InstanceAlreadyExistsException: 
>> org.apache.karaf:type=scr,name=root
>> 
>> Would appreciate help on resolving this!
>> 
>> Best,
>> Oleg
> 



Re: Strange 4.2.9/4.2.10 mixup when adding camel repos

2020-10-29 Thread John Taylor
Hi,
I also see this with camel 3.4.4.

Both camel 3.6.0 and 3.4.4 features.xml [1] have spring-legacy/4.2.9

   
   mvn:org.apache.karaf.features/spring-legacy/4.2.9/xml/features
   

So I guess that would be why?
-John

[1]
https://repo1.maven.org/maven2/org/apache/camel/karaf/apache-camel/3.4.4/apache-camel-3.4.4-features.xml

On Thu, Oct 29, 2020 at 5:47 AM Jean-Baptiste Onofre 
wrote:

> Hi,
>
> Let me try. AFAIR, Camel uses a range, so it should be fine.
>
> Regards
> JB
>
> Le 28 oct. 2020 à 12:04, Oleg Cohen  a écrit
> :
>
> Greetings,
>
> I am migrating to Karaf v4.2.10. Starting from a clean container.
>
> If I install feature war all works fine.
>
> After I add two camel repos:
>
> feature:repo-add mvn:org.apache.camel.karaf/apache-camel/RELEASE/xml
> /features
> feature:repo-add
> mvn:org.apache-extras.camel-extra.karaf/camel-extra/RELEASE/xml/features
>
> I see a number of errors when installing war (or any other feature). I
> noticed that there are commands to
> install org.apache.karaf.scr.management/4.2.9 along with 4.2.10
>
> 2020-10-28T06:59:33,762 | INFO  | features-3-thread-1 | CommandExtension
>   | 37 - org.apache.karaf.shell.core - 4.2.10 | Registering
> commands for bundle org.apache.karaf.scr.state/4.2.10
> 2020-10-28T06:59:33,762 | INFO  | features-3-thread-1 |
> FeaturesServiceImpl  | 11 - org.apache.karaf.features.core -
> 4.2.10 |   *org.apache.karaf.scr.management/4.2.9*
> 2020-10-28T06:59:33,772 | INFO  | features-3-thread-1 |
> ServiceComponentRuntimeMBeanImpl | 59 - org.apache.karaf.scr.management -
> 4.2.9 | Activating the Apache Karaf ServiceComponentRuntime MBean
> 2020-10-28T06:59:33,773 | INFO  | features-3-thread-1 |
> FeaturesServiceImpl  | 11 - org.apache.karaf.features.core -
> 4.2.10 |   *org.apache.karaf.scr.management/4.2.10*
>
> The errors are JMX based:
>
> 2020-10-28T06:59:33,779 | INFO  | features-3-thread-1 |
> ServiceComponentRuntimeMBeanImpl | 60 - org.apache.karaf.scr.management -
> 4.2.10 | Activating the Apache Karaf ServiceComponentRuntime MBean
> 2020-10-28T06:59:33,780 | ERROR | features-3-thread-1 |
> ServiceComponentRuntimeMBeanImpl | 60 - org.apache.karaf.scr.management -
> 4.2.10 | Exception registering the SCR Management MBean:
> org.apache.karaf:type=scr,name=root
> javax.management.InstanceAlreadyExistsException:
> org.apache.karaf:type=scr,name=root
>
> Would appreciate help on resolving this!
>
> Best,
> Oleg
>
>
>