Yeah, I don't remember why pax-logging-log4j2 has this import. Let me check where the package could be used.
Regards JB On 17/01/2019 18:42, Fabian Lange wrote: > Well, that does look like a wrong dependency in pax-logging-log4j2, doesnt it? > or can a logic for that be found ;) > > Fabian > > On Thu, Jan 17, 2019 at 6:34 PM Grzegorz Grzybek <[email protected]> wrote: >> >> You don't have to find the source of WTF :) >> >> pax-logging-log4j2 has: Import-Package: >> org.apache.commons.csv;resolution:=optional >> >> regards >> Grzegorz Grzybek >> >> czw., 17 sty 2019 o 17:07 Fabian Lange <[email protected]> napisał(a): >> >>> Hi, >>> see its not a karaf problem. >>> Grzegorz gave me really good hints off-list, and it turns out I do >>> load a feature which contains this apache commons bundle: >>> >>> mvn:org.apache.commons/commons-csv/1.5 >>> >>> after I remove this bundle, the logging classes are no longer loaded twice. >>> Now the next step is to find out WTF, but I leave that for another day >>> >>> Fabian >>> >>> On Thu, Jan 17, 2019 at 3:49 PM Grzegorz Grzybek <[email protected]> >>> wrote: >>>> >>>> Hello >>>> >>>> I suggest checking jansi - you have SL=8 for jansi bundle and SL=7 for >>>> pax-logging-log4j2. >>>> >>>> pax-logging-log4j has optional import for org.fusesource.jansi - and this >>>> may be the cause of refresh. >>>> >>>> In my custom distro, my etc/startup.properties has: >>>> >>>> mvn\:org.fusesource.jansi/jansi/1.17 = 8 >>>> mvn\:org.ops4j.pax.logging/pax-logging-api/1.10.1 = 8 >>>> mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.10.1 = 8 >>>> >>>> So I've already ensured that jansi starts/resolves before >>>> pax-logging-log4j2. >>>> >>>> I hope this helps. >>>> >>>> regards >>>> Grzegorz Grzybek >>>> >>>> czw., 17 sty 2019 o 15:15 Jean-Baptiste Onofré <[email protected]> >>> napisał(a): >>>> >>>>> Not a problem, Jira should be used when we "suspect" something. I think >>>>> it's good for the tracking and also for the history of faced problems. >>>>> >>>>> Just my €0.01 ;) >>>>> >>>>> Regards >>>>> JB >>>>> >>>>> On 17/01/2019 15:12, Fabian Lange wrote: >>>>>> I already feel bad for asking such wide questions here. I usually >>> only >>>>>> file tickets once I kind-of know whats going on. >>>>>> Could be a Felix or SCR issue as well ;) >>>>>> >>>>>> Fabian >>>>>> >>>>>> On Thu, Jan 17, 2019 at 3:10 PM Jean-Baptiste Onofré < >>> [email protected]> >>>>> wrote: >>>>>>> >>>>>>> Hi Fabian, >>>>>>> >>>>>>> did you create a Jira about that ? It's for the tracking as I'm >>>>>>> preparing Karaf 4.2.3 ;) >>>>>>> >>>>>>> Thanks ! >>>>>>> Regards >>>>>>> JB >>>>>>> >>>>>>> On 17/01/2019 15:08, Fabian Lange wrote: >>>>>>>> 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 < >>> [email protected]> >>>>> 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 >>>>>>> >>>>>>> -- >>>>>>> Jean-Baptiste Onofré >>>>>>> [email protected] >>>>>>> http://blog.nanthrax.net >>>>>>> Talend - http://www.talend.com >>>>> >>>>> -- >>>>> Jean-Baptiste Onofré >>>>> [email protected] >>>>> http://blog.nanthrax.net >>>>> Talend - http://www.talend.com >>>>> >>> -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
