Yes, the purpose was to support extra appenders easily. An alternative to optional import would be to use fragment but it's less flexible. A discover/locator service would be easier indeed.
Regards JB On 17/01/2019 19:46, Grzegorz Grzybek wrote: > I understand. I don't remember (wasn't there when pax-logging was founded), > but it's about those exotic appenders you can use. > But in OSGi, it'd be probably better to rewrite/adjust the > discover/extensibility part in pax-logging-log4j2, to use our beloved TCCL > instead or kind of service discovery / locator. > > regards > Grzegorz Grzybek > > czw., 17 sty 2019 o 19:37 Fabian Lange <lange.fab...@gmail.com> napisał(a): > >> I will have the same problem with jackson as well ;) >> >> pax-logging-log4j2 has really broad optional imports. probably for the >> other formatters that can be plugged. >> >> thats really inconvenient in my case :( >> >> Fabian >> >> On Thu, Jan 17, 2019 at 7:08 PM Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >>> >>> 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 <gr.grzy...@gmail.com> >> 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 <lange.fab...@gmail.com> >> 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 < >> 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 >> > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
