No in the case of pax-logging as it starts before the feature service (iself in startup.properties). Featuresboot works fine for ActiveMQ for instance. However, for the early staged bundles, you need to add in etc/startup.properties (as said in my previous email:
"In your case, just install commons-csv (via startup.properties for instance)." Regards JB On 18/01/2019 13:46, Fabian Lange wrote: > It's not working as bootFeature, you mentioned that this should be possible > JB. > It looks like the bundle in startup.properties is started before > bootFeatures is processed, and when thats done it refreshes the bundle > nonetheless > > Fabian > > On Fri, Jan 18, 2019 at 1:23 PM Jean-Baptiste Onofré <[email protected]> > wrote: >> >> 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 -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
