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.grzy...@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é <j...@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é <j...@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.fab...@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é
>>>>> jbono...@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbono...@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>

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

Reply via email to