You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Fabian Lange <la...@gmail.com> on 2018/11/26 00:21:39 UTC
SCR Bundle refreshes Pax Logging?
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
Re: SCR Bundle refreshes Pax Logging?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
It sounds reasonable. Agree to improve pax-logging in that way.
Regards
JB
On 17/01/2019 20:29, Robert Varga wrote:
> 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.
>
> Yes, and also it would be nice to have a basic slim core jar and have
> rest optionally delivered -- I bet most deployments would use much less
> than 1.8MiB this is currently costing...
>
> Regards,
> Robert
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: SCR Bundle refreshes Pax Logging?
Posted by Robert Varga <ni...@hq.sk>.
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.
Yes, and also it would be nice to have a basic slim core jar and have
rest optionally delivered -- I bet most deployments would use much less
than 1.8MiB this is currently costing...
Regards,
Robert
Re: SCR Bundle refreshes Pax Logging?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Again, that's pax-logging specific because pax-logging starts in the
very early stage.
I think that the best fix is actually to implement kind of locator in
pax-logging.
Regards
JB
On 18/01/2019 13:59, Fabian Lange wrote:
> Thats a pit, because it is the no longer under the control of a
> feature, and then version updates cause a new bundle rather than
> replace the old.
>
> Tricky. I will experiment some more, looking forward to a cleanup in
> pax logging!
>
> Thanks for all the interesting tips and tricks
>
> Fabian
>
> On Fri, Jan 18, 2019 at 1:49 PM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>>
>> 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é <jb...@nanthrax.net> 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 <gr...@gmail.com> 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é <jb...@nanthrax.net> 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é <jb...@nanthrax.net>
>>>>>>> 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 <la...@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 <la...@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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>
>> --
>> 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
Re: SCR Bundle refreshes Pax Logging?
Posted by Fabian Lange <la...@gmail.com>.
Thats a pit, because it is the no longer under the control of a
feature, and then version updates cause a new bundle rather than
replace the old.
Tricky. I will experiment some more, looking forward to a cleanup in
pax logging!
Thanks for all the interesting tips and tricks
Fabian
On Fri, Jan 18, 2019 at 1:49 PM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
> 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é <jb...@nanthrax.net> 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 <gr...@gmail.com> 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é <jb...@nanthrax.net> 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é <jb...@nanthrax.net>
> >>>>> 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 <la...@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 <la...@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
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> 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
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: SCR Bundle refreshes Pax Logging?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@nanthrax.net> 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 <gr...@gmail.com> 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é <jb...@nanthrax.net> 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é <jb...@nanthrax.net>
>>>>> 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 <la...@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 <la...@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
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: SCR Bundle refreshes Pax Logging?
Posted by Fabian Lange <la...@gmail.com>.
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é <jb...@nanthrax.net> 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 <gr...@gmail.com> 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é <jb...@nanthrax.net> 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é <jb...@nanthrax.net>
> >>> 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 <la...@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 <la...@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
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> 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
Re: SCR Bundle refreshes Pax Logging?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <gr...@gmail.com> 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é <jb...@nanthrax.net> 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é <jb...@nanthrax.net>
>>> 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 <la...@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 <la...@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
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> 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
Re: SCR Bundle refreshes Pax Logging?
Posted by Fabian Lange <la...@gmail.com>.
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 <gr...@gmail.com> 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é <jb...@nanthrax.net> 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é <jb...@nanthrax.net>
> > 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 <la...@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 <la...@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
> > >>>>
> > >>>
> > >>
> > >> --
> > >> 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
> >
Re: SCR Bundle refreshes Pax Logging?
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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é <jb...@nanthrax.net> 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é <jb...@nanthrax.net>
> 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 <la...@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 <la...@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
> >>>>
> >>>
> >>
> >> --
> >> 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
>
Re: SCR Bundle refreshes Pax Logging?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@nanthrax.net> 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 <la...@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...@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 <la...@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
>>>>
>>>
>>
>> --
>> 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
Re: SCR Bundle refreshes Pax Logging?
Posted by Fabian Lange <la...@gmail.com>.
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é <jb...@nanthrax.net> 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 <la...@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...@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 <la...@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
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: SCR Bundle refreshes Pax Logging?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <la...@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...@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 <la...@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
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: SCR Bundle refreshes Pax Logging?
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <la...@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...@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 <la...@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
>
Re: SCR Bundle refreshes Pax Logging?
Posted by Fabian Lange <la...@gmail.com>.
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...@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 <la...@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...@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
Re: SCR Bundle refreshes Pax Logging?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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...@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 <la...@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...@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
Re: SCR Bundle refreshes Pax Logging?
Posted by Fabian Lange <la...@gmail.com>.
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...@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 <la...@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...@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
> > > >
> >
Re: SCR Bundle refreshes Pax Logging?
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <la...@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...@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
> > >
>
Re: SCR Bundle refreshes Pax Logging?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi
indeed, maybe commons-csv headers are not fully correct.
By the way, feature:install -v -t gives good details about the reasons
of a refresh.
Regards
JB
On 17/01/2019 17:06, Fabian Lange wrote:
> 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...@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 <la...@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
Re: SCR Bundle refreshes Pax Logging?
Posted by Fabian Lange <la...@gmail.com>.
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...@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 <la...@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
> >
Re: SCR Bundle refreshes Pax Logging?
Posted by Grzegorz Grzybek <gr...@gmail.com>.
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 <la...@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
>
Re: SCR Bundle refreshes Pax Logging?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <la...@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
Re: SCR Bundle refreshes Pax Logging?
Posted by Fabian Lange <la...@gmail.com>.
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 <la...@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
Re: SCR Bundle refreshes Pax Logging?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <la...@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
Re: SCR Bundle refreshes Pax Logging?
Posted by Fabian Lange <la...@gmail.com>.
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 <la...@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