Quick update, this apparently is still the case with Karaf 4.2.2
Would appreciate if somebody knows a workaround. I am able to play
around with startlevels, but I cant seem to avoid this.
Fabian
On Mon, Nov 26, 2018 at 1:21 AM Fabian Lange <lange.fabian@gmail.com> wrote:
>
> Hi,
> currently debugging an issue. Maybe the bits I came up so far are
> already sufficient for you guys to fix it, or you help me how to debug
> this better.
> In our distribution, we have these features
>
> 0 │ Active │ 0 │ 5.6.10 │ System Bundle, Fragments: 1
> 1 │ Resolved │ 1 │ 4.2.1 │ Apache Karaf :: Features ::
> Extension, Hosts: 0
> 2 │ Active │ 5 │ 2.5.4 │ OPS4J Pax Url - aether:
> 3 │ Active │ 7 │ 1.10.1 │ OPS4J Pax Logging - Log4j v2
> 4 │ Active │ 7 │ 1.10.1 │ OPS4J Pax Logging - API
> 5 │ Active │ 8 │ 1.17.1 │ jansi
> 6 │ Active │ 9 │ 1.0.2 │ Apache Felix Coordinator Service
> 7 │ Active │ 10 │ 1.9.4 │ Apache Felix Configuration Admin Service
> 8 │ Active │ 11 │ 3.6.4 │ Apache Felix File Install
> 9 │ Active │ 15 │ 4.2.1 │ Apache Karaf :: Features :: Core
> 10 │ Active │ 20 │ 2.2.11.1 │ Apache ServiceMix :: Bundles :: jaxb-impl
> 11 │ Active │ 30 │ 1.2.0 │ Apache Felix Metatype Service
> 12 │ Active │ 30 │ 2.1.2 │ Apache Felix Declarative Services
> 13 │ Active │ 30 │ 4.2.1 │ Apache Karaf :: Bundle :: Core
> 14 │ Active │ 30 │ 4.2.1 │ Apache Karaf :: ConfigAdmin :: Core
> 15 │ Active │ 30 │ 4.2.1 │ Apache Karaf :: Features :: Command
> 16 │ Active │ 30 │ 4.2.1 │ Apache Karaf :: Log :: Core
> 17 │ Active │ 30 │ 4.2.1 │ Apache Karaf :: SCR :: Bundle State
> 18 │ Active │ 30 │ 4.2.1 │ Apache Karaf :: Service :: Core
> 19 │ Active │ 30 │ 4.2.1 │ Apache Karaf :: Shell :: Various Commands
> 20 │ Active │ 30 │ 4.2.1 │ Apache Karaf :: Shell :: Core
> 21 │ Active │ 30 │ 4.2.1 │ Apache Karaf :: System :: Core
> 22 │ Active │ 30 │ 3.9.0 │ JLine Builtins
> 23 │ Active │ 30 │ 3.9.0 │ JLine Reader
> 24 │ Active │ 30 │ 3.9.0 │ JLine Terminal, Fragments: 25
> 25 │ Resolved │ 30 │ 3.9.0 │ JLine JANSI Terminal, Hosts: 24
>
> What I noticed is that A LOT of apache LOG4J classes are loaded twice
> in the JVM.
> I turned on -verbose:class and saw this snippet:
>
> [5.580s][info][class,load]
> org.apache.felix.scr.impl.logger.StdOutLogger source:
> jar:bundle://12.0:0/!/
> [5.626s][info][class,load]
> org.apache.felix.framework.util.ImmutableMap$1 source:
> file:/Users/fabian/work/karaf-dist/system/org/apache/felix/org.apache.felix.framework/5.6.10/org.apache.felix.framework-5.6.10.jar
> [5.834s][info][class,load]
> org.apache.karaf.features.internal.service.BundleInstallSupportImpl$$Lambda$412/0x00000007fecd0c40
> source: org.apache.karaf.features.internal.service.BundleInstallSupportImpl
> [5.834s][info][class,load]
> org.apache.felix.framework.Felix$RefreshHelper source:
> file:/Users/fabian/work/karaf-dist/system/org/apache/felix/org.apache.felix.framework/5.6.10/org.apache.felix.framework-5.6.10.jar
> [5.970s][info][class,load]
> org.ops4j.pax.logging.log4j2.internal.Activator source:
> jar:bundle://3.0:0/!/
>
> So here is my suspicion: Whatever SCR does, it causes the Log4j2
> bundle to reload all classes and activate again. This leads to all
> bundles before the SCR to reference the first loaded log4j classes,
> and all afterwards the refreshed bundle.
>
> Can we prevent this somehow? Also curiously SCR uses its StdOutLogger,
> which it shouldnt do.
> Is this reload caused by the Service Tracker
> org.apache.felix.scr.impl.logger.LogServiceEnabledLogger uses?
>
> Ideas, suggestions how to prevent this refresh? I played with the load
> order but it does not seem possible to get it right
>
> Fabian
|