> 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
