karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Grzybek <gr.grzy...@gmail.com>
Subject Re: SCR Bundle refreshes Pax Logging?
Date Thu, 17 Jan 2019 18:46:34 GMT
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.fabian@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é <jb@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.grzybek@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.fabian@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.grzybek@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é <jb@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é <
> > >>> jb@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.fabian@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é
> > >>>>>>> jbonofre@apache.org
> > >>>>>>> http://blog.nanthrax.net
> > >>>>>>> Talend - http://www.talend.com
> > >>>>>
> > >>>>> --
> > >>>>> Jean-Baptiste Onofré
> > >>>>> jbonofre@apache.org
> > >>>>> http://blog.nanthrax.net
> > >>>>> Talend - http://www.talend.com
> > >>>>>
> > >>>
> >
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message