karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: SCR Bundle refreshes Pax Logging?
Date Thu, 17 Jan 2019 20:06:19 GMT
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 <lange.fabian@gmail.com> napisał(a):
> 
>> I will have the same problem with jackson as well ;)
>>
>> pax-logging-log4j2 has really broad optional imports. probably for the
>> other formatters that can be plugged.
>>
>> thats really inconvenient in my case :(
>>
>> Fabian
>>
>> On Thu, Jan 17, 2019 at 7:08 PM Jean-Baptiste Onofré <jb@nanthrax.net>
>> wrote:
>>>
>>> Yeah, I don't remember why pax-logging-log4j2 has this import.
>>>
>>> Let me check where the package could be used.
>>>
>>> Regards
>>> JB
>>>
>>> On 17/01/2019 18:42, Fabian Lange wrote:
>>>> Well, that does look like a wrong dependency in pax-logging-log4j2,
>> doesnt it?
>>>> or can a logic for that be found ;)
>>>>
>>>> Fabian
>>>>
>>>> On Thu, Jan 17, 2019 at 6:34 PM Grzegorz Grzybek <gr.grzybek@gmail.com>
>> wrote:
>>>>>
>>>>> You don't have to find the source of WTF :)
>>>>>
>>>>> pax-logging-log4j2 has: Import-Package:
>>>>> org.apache.commons.csv;resolution:=optional
>>>>>
>>>>> regards
>>>>> Grzegorz Grzybek
>>>>>
>>>>> czw., 17 sty 2019 o 17:07 Fabian Lange <lange.fabian@gmail.com>
>> napisał(a):
>>>>>
>>>>>> Hi,
>>>>>> see its not a karaf problem.
>>>>>> Grzegorz gave me really good hints off-list, and it turns out I do
>>>>>> load a feature which contains this apache commons bundle:
>>>>>>
>>>>>> mvn:org.apache.commons/commons-csv/1.5
>>>>>>
>>>>>> after I remove this bundle, the logging classes are no longer loaded
>> twice.
>>>>>> Now the next step is to find out WTF, but I leave that for another
>> day
>>>>>>
>>>>>> Fabian
>>>>>>
>>>>>> On Thu, Jan 17, 2019 at 3:49 PM Grzegorz Grzybek <
>> gr.grzybek@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hello
>>>>>>>
>>>>>>> I suggest checking jansi - you have SL=8 for jansi bundle and
SL=7
>> for
>>>>>>> pax-logging-log4j2.
>>>>>>>
>>>>>>> pax-logging-log4j has optional import for org.fusesource.jansi
-
>> and this
>>>>>>> may be the cause of refresh.
>>>>>>>
>>>>>>> In my custom distro, my etc/startup.properties has:
>>>>>>>
>>>>>>> mvn\:org.fusesource.jansi/jansi/1.17 = 8
>>>>>>> mvn\:org.ops4j.pax.logging/pax-logging-api/1.10.1 = 8
>>>>>>> mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.10.1 = 8
>>>>>>>
>>>>>>> So I've already ensured that jansi starts/resolves before
>>>>>>> pax-logging-log4j2.
>>>>>>>
>>>>>>> I hope this helps.
>>>>>>>
>>>>>>> regards
>>>>>>> Grzegorz Grzybek
>>>>>>>
>>>>>>> czw., 17 sty 2019 o 15:15 Jean-Baptiste Onofré <jb@nanthrax.net>
>>>>>> napisał(a):
>>>>>>>
>>>>>>>> Not a problem, Jira should be used when we "suspect" something.
I
>> think
>>>>>>>> it's good for the tracking and also for the history of faced
>> problems.
>>>>>>>>
>>>>>>>> Just my €0.01 ;)
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>> On 17/01/2019 15:12, Fabian Lange wrote:
>>>>>>>>> I already feel bad for asking such wide questions here.
I usually
>>>>>> only
>>>>>>>>> file tickets once I kind-of know whats going on.
>>>>>>>>> Could be a Felix or SCR issue as well ;)
>>>>>>>>>
>>>>>>>>> Fabian
>>>>>>>>>
>>>>>>>>> On Thu, Jan 17, 2019 at 3:10 PM Jean-Baptiste Onofré
<
>>>>>> jb@nanthrax.net>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Fabian,
>>>>>>>>>>
>>>>>>>>>> did you create a Jira about that ? It's for the tracking
as I'm
>>>>>>>>>> preparing Karaf 4.2.3 ;)
>>>>>>>>>>
>>>>>>>>>> Thanks !
>>>>>>>>>> Regards
>>>>>>>>>> JB
>>>>>>>>>>
>>>>>>>>>> On 17/01/2019 15:08, Fabian Lange wrote:
>>>>>>>>>>> Quick update, this apparently is still the case
with Karaf 4.2.2
>>>>>>>>>>>
>>>>>>>>>>> Would appreciate if somebody knows a workaround.
I am able to
>> play
>>>>>>>>>>> around with startlevels, but I cant seem to avoid
this.
>>>>>>>>>>>
>>>>>>>>>>> Fabian
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Nov 26, 2018 at 1:21 AM Fabian Lange
<
>>>>>> lange.fabian@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> currently debugging an issue. Maybe the bits
I came up so far
>> are
>>>>>>>>>>>> already sufficient for you guys to fix it,
or you help me how
>> to
>>>>>> debug
>>>>>>>>>>>> this better.
>>>>>>>>>>>> In our distribution, we have these features
>>>>>>>>>>>>
>>>>>>>>>>>>   0 │ Active   │   0 │ 5.6.10     
 │ System Bundle,
>> Fragments: 1
>>>>>>>>>>>>   1 │ Resolved │   1 │ 4.2.1      
 │ Apache Karaf :: Features
>> ::
>>>>>>>>>>>> Extension, Hosts: 0
>>>>>>>>>>>>   2 │ Active   │   5 │ 2.5.4      
 │ OPS4J Pax Url - aether:
>>>>>>>>>>>>   3 │ Active   │   7 │ 1.10.1     
 │ OPS4J Pax Logging -
>> Log4j v2
>>>>>>>>>>>>   4 │ Active   │   7 │ 1.10.1     
 │ OPS4J Pax Logging - API
>>>>>>>>>>>>   5 │ Active   │   8 │ 1.17.1     
 │ jansi
>>>>>>>>>>>>   6 │ Active   │   9 │ 1.0.2      
 │ Apache Felix Coordinator
>>>>>> Service
>>>>>>>>>>>>   7 │ Active   │  10 │ 1.9.4      
 │ Apache Felix
>> Configuration
>>>>>>>> Admin Service
>>>>>>>>>>>>   8 │ Active   │  11 │ 3.6.4      
 │ Apache Felix File Install
>>>>>>>>>>>>   9 │ Active   │  15 │ 4.2.1      
 │ Apache Karaf :: Features
>> ::
>>>>>> Core
>>>>>>>>>>>>  10 │ Active   │  20 │ 2.2.11.1   
 │ Apache ServiceMix ::
>>>>>> Bundles ::
>>>>>>>> jaxb-impl
>>>>>>>>>>>>  11 │ Active   │  30 │ 1.2.0      
 │ Apache Felix Metatype
>>>>>> Service
>>>>>>>>>>>>  12 │ Active   │  30 │ 2.1.2      
 │ Apache Felix Declarative
>>>>>>>> Services
>>>>>>>>>>>>  13 │ Active   │  30 │ 4.2.1      
 │ Apache Karaf :: Bundle ::
>>>>>> Core
>>>>>>>>>>>>  14 │ Active   │  30 │ 4.2.1      
 │ Apache Karaf ::
>> ConfigAdmin
>>>>>> ::
>>>>>>>> Core
>>>>>>>>>>>>  15 │ Active   │  30 │ 4.2.1      
 │ Apache Karaf :: Features
>> ::
>>>>>>>> Command
>>>>>>>>>>>>  16 │ Active   │  30 │ 4.2.1      
 │ Apache Karaf :: Log ::
>> Core
>>>>>>>>>>>>  17 │ Active   │  30 │ 4.2.1      
 │ Apache Karaf :: SCR ::
>>>>>> Bundle
>>>>>>>> State
>>>>>>>>>>>>  18 │ Active   │  30 │ 4.2.1      
 │ Apache Karaf :: Service
>> ::
>>>>>> Core
>>>>>>>>>>>>  19 │ Active   │  30 │ 4.2.1      
 │ Apache Karaf :: Shell ::
>>>>>>>> Various Commands
>>>>>>>>>>>>  20 │ Active   │  30 │ 4.2.1      
 │ Apache Karaf :: Shell ::
>>>>>> Core
>>>>>>>>>>>>  21 │ Active   │  30 │ 4.2.1      
 │ Apache Karaf :: System ::
>>>>>> Core
>>>>>>>>>>>>  22 │ Active   │  30 │ 3.9.0      
 │ JLine Builtins
>>>>>>>>>>>>  23 │ Active   │  30 │ 3.9.0      
 │ JLine Reader
>>>>>>>>>>>>  24 │ Active   │  30 │ 3.9.0      
 │ JLine Terminal,
>> Fragments:
>>>>>> 25
>>>>>>>>>>>>  25 │ Resolved │  30 │ 3.9.0      
 │ JLine JANSI Terminal,
>>>>>> Hosts: 24
>>>>>>>>>>>>
>>>>>>>>>>>> What I noticed is that A LOT of apache LOG4J
classes are loaded
>>>>>> twice
>>>>>>>>>>>> in the JVM.
>>>>>>>>>>>> I turned on -verbose:class and saw this snippet:
>>>>>>>>>>>>
>>>>>>>>>>>> [5.580s][info][class,load]
>>>>>>>>>>>> org.apache.felix.scr.impl.logger.StdOutLogger
source:
>>>>>>>>>>>> jar:bundle://12.0:0/!/
>>>>>>>>>>>> [5.626s][info][class,load]
>>>>>>>>>>>> org.apache.felix.framework.util.ImmutableMap$1
source:
>>>>>>>>>>>>
>>>>>>>>
>>>>>>
>> file:/Users/fabian/work/karaf-dist/system/org/apache/felix/org.apache.felix.framework/5.6.10/org.apache.felix.framework-5.6.10.jar
>>>>>>>>>>>> [5.834s][info][class,load]
>>>>>>>>>>>>
>>>>>>>>
>>>>>>
>> org.apache.karaf.features.internal.service.BundleInstallSupportImpl$$Lambda$412/0x00000007fecd0c40
>>>>>>>>>>>> source:
>>>>>>>> org.apache.karaf.features.internal.service.BundleInstallSupportImpl
>>>>>>>>>>>> [5.834s][info][class,load]
>>>>>>>>>>>> org.apache.felix.framework.Felix$RefreshHelper
source:
>>>>>>>>>>>>
>>>>>>>>
>>>>>>
>> file:/Users/fabian/work/karaf-dist/system/org/apache/felix/org.apache.felix.framework/5.6.10/org.apache.felix.framework-5.6.10.jar
>>>>>>>>>>>> [5.970s][info][class,load]
>>>>>>>>>>>> org.ops4j.pax.logging.log4j2.internal.Activator
source:
>>>>>>>>>>>> jar:bundle://3.0:0/!/
>>>>>>>>>>>>
>>>>>>>>>>>> So here is my suspicion: Whatever SCR does,
it causes the
>> Log4j2
>>>>>>>>>>>> bundle to reload all classes and activate
again. This leads to
>> all
>>>>>>>>>>>> bundles before the SCR to reference the first
loaded log4j
>>>>>> classes,
>>>>>>>>>>>> and all afterwards the refreshed bundle.
>>>>>>>>>>>>
>>>>>>>>>>>> Can we prevent this somehow? Also curiously
SCR uses its
>>>>>> StdOutLogger,
>>>>>>>>>>>> which it shouldnt do.
>>>>>>>>>>>> Is this reload caused by the Service Tracker
>>>>>>>>>>>> org.apache.felix.scr.impl.logger.LogServiceEnabledLogger
uses?
>>>>>>>>>>>>
>>>>>>>>>>>> Ideas, suggestions how to prevent this refresh?
I played with
>> the
>>>>>> load
>>>>>>>>>>>> order but it does not seem possible to get
it right
>>>>>>>>>>>>
>>>>>>>>>>>> Fabian
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jean-Baptiste Onofré
>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jean-Baptiste Onofré
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message