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.grzybek@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 <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
>>>
>>> --
>>> 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
|