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é <j...@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 <lange.fab...@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é <j...@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.grzy...@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.fab...@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.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
>>>>
>>>
>>
>> --
>> 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