Hi indeed, maybe commons-csv headers are not fully correct.
By the way, feature:install -v -t gives good details about the reasons of a refresh. Regards JB On 17/01/2019 17:06, Fabian Lange wrote: > 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 <gr.grzy...@gmail.com> 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é <j...@nanthrax.net> >> 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é <j...@nanthrax.net> >>> 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 <lange.fab...@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 >>>>> >>>>> -- >>>>> Jean-Baptiste Onofré >>>>> jbono...@apache.org >>>>> http://blog.nanthrax.net >>>>> Talend - http://www.talend.com >>> >>> -- >>> Jean-Baptiste Onofré >>> jbono...@apache.org >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com >>> -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com