Re: Karaf pax-logging-log4j2 bundle gets restarted - how to avoid?
That would be awesome. I wasn't sure how much your hands might be tied on that one. Glad to hear there is something that could be done. I'm just working around or dealing with it :). On Thu, May 16, 2019 at 11:59 PM Jean-Baptiste Onofré wrote: > Hi Ryan, > > We are working some cleanups in Pax Logging. Definitely, > pax-logging-log4j2 has a lot of optional imports that causing those > refreshes. > This is due to support log4j2 appenders easily, but we can improve this. > > I will create a Jira at Pax Logging to improve this and avoid all those > optional imports causing refresh issue. > > Regards > JB > > On 16/05/2019 20:36, rkmoquin wrote: > > I see this problem a lot when deploying my project in Karaf, for > example, I > > was trying to allow installing different features independently > depending on > > which capability someone might need, a feature that uses the Jackson > > libraries for example (either directly or via camel-jackson or one of the > > other myriads of projects that use jackson). If any features are > already > > installed, this causes a cascading reload of just about everything. I > guess > > it feels like the main karaf dependencies shouldn't be refreshed by > default > > since it can cause strange stuff to happen. > > > > I'm sure it's not as simple as that, but it definitely does bug me as > well > > that pax-logging-log4j2 would have a dependency on Jackson, Kafka, > ZeroMQ, > > etc... Jackson is at least somewhat stomach-able as a dependency, but > not > > ZeroMQ or Kafka. I'm not sure how pax-logging built, so I'm not sure if > > it's possible to control any of this, or if this is because of something > > like log4j being coupled to every library it possible can be coupled to > (not > > the first library to do that sort of thing and unfortunately won't be the > > last) ;) > > > > For now I'm just trying to identify dependencies that feel like I can > > justify pre-installing in a custom distribution to try to get around > this. > > It doesn't solve the whole problem but at least some of it. > > > > Ryan > > > > > > > > -- > > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html > > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
Re: Karaf pax-logging-log4j2 bundle gets restarted - how to avoid?
Hi Ryan, We are working some cleanups in Pax Logging. Definitely, pax-logging-log4j2 has a lot of optional imports that causing those refreshes. This is due to support log4j2 appenders easily, but we can improve this. I will create a Jira at Pax Logging to improve this and avoid all those optional imports causing refresh issue. Regards JB On 16/05/2019 20:36, rkmoquin wrote: > I see this problem a lot when deploying my project in Karaf, for example, I > was trying to allow installing different features independently depending on > which capability someone might need, a feature that uses the Jackson > libraries for example (either directly or via camel-jackson or one of the > other myriads of projects that use jackson). If any features are already > installed, this causes a cascading reload of just about everything. I guess > it feels like the main karaf dependencies shouldn't be refreshed by default > since it can cause strange stuff to happen. > > I'm sure it's not as simple as that, but it definitely does bug me as well > that pax-logging-log4j2 would have a dependency on Jackson, Kafka, ZeroMQ, > etc... Jackson is at least somewhat stomach-able as a dependency, but not > ZeroMQ or Kafka. I'm not sure how pax-logging built, so I'm not sure if > it's possible to control any of this, or if this is because of something > like log4j being coupled to every library it possible can be coupled to (not > the first library to do that sort of thing and unfortunately won't be the > last) ;) > > For now I'm just trying to identify dependencies that feel like I can > justify pre-installing in a custom distribution to try to get around this. > It doesn't solve the whole problem but at least some of it. > > Ryan > > > > -- > Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Re: Karaf pax-logging-log4j2 bundle gets restarted - how to avoid?
I see this problem a lot when deploying my project in Karaf, for example, I was trying to allow installing different features independently depending on which capability someone might need, a feature that uses the Jackson libraries for example (either directly or via camel-jackson or one of the other myriads of projects that use jackson). If any features are already installed, this causes a cascading reload of just about everything. I guess it feels like the main karaf dependencies shouldn't be refreshed by default since it can cause strange stuff to happen. I'm sure it's not as simple as that, but it definitely does bug me as well that pax-logging-log4j2 would have a dependency on Jackson, Kafka, ZeroMQ, etc... Jackson is at least somewhat stomach-able as a dependency, but not ZeroMQ or Kafka. I'm not sure how pax-logging built, so I'm not sure if it's possible to control any of this, or if this is because of something like log4j being coupled to every library it possible can be coupled to (not the first library to do that sort of thing and unfortunately won't be the last) ;) For now I'm just trying to identify dependencies that feel like I can justify pre-installing in a custom distribution to try to get around this. It doesn't solve the whole problem but at least some of it. Ryan -- Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
Re: Re: Karaf pax-logging-log4j2 bundle gets restarted - how to avoid?
> Did you identify the optional import in cause ? pax-logging bundle has all these optional imports, I'm just wondering why. It makes it susceptible to many other bundles that are loaded later on. Shouldn't pax-logging be more self-sufficient? com.beust.jcommander;resolution:=optional, com.beust.jcommander.validators;resolution:=optional, com.conversantmedia.util.concurrent;resolution:=optional, com.fasterxml.jackson.annotation;resolution:=optional, com.fasterxml.jackson.core;resolution:=optional, com.fasterxml.jackson.core.type;resolution:=optional, com.fasterxml.jackson.core.util;resolution:=optional, com.fasterxml.jackson.databind;resolution:=optional, com.fasterxml.jackson.databind.annotation;resolution:=optional, com.fasterxml.jackson.databind.deser.std;resolution:=optional, com.fasterxml.jackson.databind.module;resolution:=optional, com.fasterxml.jackson.databind.node;resolution:=optional, com.fasterxml.jackson.databind.ser;resolution:=optional, com.fasterxml.jackson.databind.ser.impl;resolution:=optional, com.fasterxml.jackson.databind.ser.std;resolution:=optional, com.fasterxml.jackson.dataformat.xml;resolution:=optional, com.fasterxml.jackson.dataformat.xml.annotation;resolution:=optional, com.fasterxml.jackson.dataformat.xml.util;resolution:=optional, com.fasterxml.jackson.dataformat.yaml;resolution:=optional, com.lmax.disruptor;resolution:=optional, com.lmax.disruptor.dsl;resolution:=optional, javax.activation;resolution:=optional, javax.annotation.processing;resolution:=optional, javax.crypto;resolution:=optional, javax.jms;resolution:=optional, javax.lang.model;resolution:=optional, javax.lang.model.element;resolution:=optional, javax.lang.model.util;resolution:=optional, javax.mail;resolution:=optional, javax.mail.internet;resolution:=optional, javax.mail.util;resolution:=optional, javax.management;resolution:=optional, javax.naming;resolution:=optional, javax.net;resolution:=optional, javax.net.ssl;resolution:=optional, javax.persistence;resolution:=optional, javax.script;resolution:=optional, javax.sql;resolution:=optional, javax.tools;resolution:=optional, org.apache.commons.compress.compressors;resolution:=optional, org.apache.commons.compress.utils;resolution:=optional, org.apache.commons.csv;resolution:=optional, org.apache.kafka.clients.producer;resolution:=optional, org.codehaus.stax2;resolution:=optional, org.fusesource.jansi;resolution:=optional, org.jctools.queues;resolution:=optional, org.zeromq;resolution:=optional On 12.12.2018 11:48, Jean-Baptiste Onofré wrote: Hi, if your Pax Exam @Config provides all featuresBoot to avoid the refresh, the refresh should not happen. Did you identify the optional import in cause ? Thanks, Regards JB On 12/12/2018 11:32, Martin Lichtin wrote: It happens during a Pax-Exam test, so all features are loaded via "featuresBoot". What I can see is that the pax-logging-log4j2 bundle has a lot of optional Imports. So when more bundles are loaded, re-wiring is happening. On 11.12.2018 19:41, Jean-Baptiste Onofré wrote: Hi, Can you please provide your feature or do a feature:install -v to see the cause of the refresh ? A simple workaround is to set your feature as featuresBoot, you won't have the refresh. Regards JB On 11/12/2018 18:47, Martin Lichtin wrote: When loading features, I have the problematic situation of 2018-12-11T18:16:00,189 | INFO | features-1-thread-1 | FeaturesServiceImpl | FeaturesServiceImpl 1286 | karaf.features.core - 4.1.7 | Stopping bundles: 2018-12-11T18:16:00,189 | INFO | features-1-thread-1 | FeaturesServiceImpl | FeaturesServiceImpl 1286 | karaf.features.core - 4.1.7 | org.ops4j.pax.logging.pax-logging-log4j2/1.10.1 It therefore goes into a blind flight (no more logging) and only a couple of seconds later (usually 10-20s), the logging returns (when that bundle gets started again). Any way to avoid this log4j2 bundle refresh/re-wiring? - Martin
Re: Karaf pax-logging-log4j2 bundle gets restarted - how to avoid?
Hi, if your Pax Exam @Config provides all featuresBoot to avoid the refresh, the refresh should not happen. Did you identify the optional import in cause ? Thanks, Regards JB On 12/12/2018 11:32, Martin Lichtin wrote: It happens during a Pax-Exam test, so all features are loaded via "featuresBoot". What I can see is that the pax-logging-log4j2 bundle has a lot of optional Imports. So when more bundles are loaded, re-wiring is happening. On 11.12.2018 19:41, Jean-Baptiste Onofré wrote: Hi, Can you please provide your feature or do a feature:install -v to see the cause of the refresh ? A simple workaround is to set your feature as featuresBoot, you won't have the refresh. Regards JB On 11/12/2018 18:47, Martin Lichtin wrote: When loading features, I have the problematic situation of 2018-12-11T18:16:00,189 | INFO | features-1-thread-1 | FeaturesServiceImpl | FeaturesServiceImpl 1286 | karaf.features.core - 4.1.7 | Stopping bundles: 2018-12-11T18:16:00,189 | INFO | features-1-thread-1 | FeaturesServiceImpl | FeaturesServiceImpl 1286 | karaf.features.core - 4.1.7 | org.ops4j.pax.logging.pax-logging-log4j2/1.10.1 It therefore goes into a blind flight (no more logging) and only a couple of seconds later (usually 10-20s), the logging returns (when that bundle gets started again). Any way to avoid this log4j2 bundle refresh/re-wiring? - Martin
Re: Re: Karaf pax-logging-log4j2 bundle gets restarted - how to avoid?
It happens during a Pax-Exam test, so all features are loaded via "featuresBoot". What I can see is that the pax-logging-log4j2 bundle has a lot of optional Imports. So when more bundles are loaded, re-wiring is happening. On 11.12.2018 19:41, Jean-Baptiste Onofré wrote: Hi, Can you please provide your feature or do a feature:install -v to see the cause of the refresh ? A simple workaround is to set your feature as featuresBoot, you won't have the refresh. Regards JB On 11/12/2018 18:47, Martin Lichtin wrote: When loading features, I have the problematic situation of 2018-12-11T18:16:00,189 | INFO | features-1-thread-1 | FeaturesServiceImpl | FeaturesServiceImpl 1286 | karaf.features.core - 4.1.7 | Stopping bundles: 2018-12-11T18:16:00,189 | INFO | features-1-thread-1 | FeaturesServiceImpl | FeaturesServiceImpl 1286 | karaf.features.core - 4.1.7 | org.ops4j.pax.logging.pax-logging-log4j2/1.10.1 It therefore goes into a blind flight (no more logging) and only a couple of seconds later (usually 10-20s), the logging returns (when that bundle gets started again). Any way to avoid this log4j2 bundle refresh/re-wiring? - Martin
Re: Karaf pax-logging-log4j2 bundle gets restarted - how to avoid?
Hi, Can you please provide your feature or do a feature:install -v to see the cause of the refresh ? A simple workaround is to set your feature as featuresBoot, you won't have the refresh. Regards JB On 11/12/2018 18:47, Martin Lichtin wrote: > When loading features, I have the problematic situation of > > 2018-12-11T18:16:00,189 | INFO | features-1-thread-1 | > FeaturesServiceImpl | FeaturesServiceImpl 1286 | karaf.features.core - > 4.1.7 | Stopping bundles: > 2018-12-11T18:16:00,189 | INFO | features-1-thread-1 | > FeaturesServiceImpl | FeaturesServiceImpl 1286 | karaf.features.core - > 4.1.7 | org.ops4j.pax.logging.pax-logging-log4j2/1.10.1 > > It therefore goes into a blind flight (no more logging) and only a > couple of seconds later (usually 10-20s), the logging returns (when that > bundle gets started again). > > Any way to avoid this log4j2 bundle refresh/re-wiring? > > - Martin > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com