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
|