Yes, that's the purpose of custom distribution: install your applications, and dependencies to avoid refresh.
It's what I'm doing in my custom distro as well. Regards JB On 18/01/2019 11:31, Fabian Lange wrote: > featuresBoot doesnt seem to work, > listing in etc/startup.properties does > > hooray, this saves me about 10% of native memory eaten up by the > duplicate classloading. > > On Fri, Jan 18, 2019 at 10:33 AM Grzegorz Grzybek <[email protected]> > wrote: >> >> Hello >> >> having commons-csv in etc/startup.properties is the best (for now) way to >> resolve this unnecessary refresh problem (I did it many times with JBoss >> Fuse). >> >> For pax-logging fix, I've created >> https://ops4j1.jira.com/browse/PAXLOGGING-248 to track it. >> >> regards >> Grzegorz Grzybek >> >> pt., 18 sty 2019 o 06:19 Jean-Baptiste Onofré <[email protected]> napisał(a): >> >>> A simple hack is to actually install the bundle causing the refresh as >>> boot feature or startup.properties. If the optional imports are already >>> resolved/provided, the refresh won't happen. >>> >>> In your case, just install commons-csv (via startup.properties for >>> instance). >>> >>> Regards >>> JB >>> >>> On 17/01/2019 21:12, Fabian Lange wrote: >>>> Is there a hack with which I can prevent the bundle from refreshing? I >>>> can of course monkeypatch the manifest :) >>>> >>>> Fabian >>>> >>>> On Thu, Jan 17, 2019 at 9:06 PM Jean-Baptiste Onofré <[email protected]> >>> wrote: >>>>> >>>>> 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 <[email protected]> >>> 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é <[email protected] >>>> >>>>>>> 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 < >>> [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 >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> 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
