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 Fri, 18 Jan 2019 12:49:05 GMT
No in the case of pax-logging as it starts before the feature service
(iself in startup.properties). Featuresboot works fine for ActiveMQ for
instance. However, for the early staged bundles, you need to add in
etc/startup.properties (as said in my previous email:

"In your case, just install commons-csv (via startup.properties for
instance)."

Regards
JB

On 18/01/2019 13:46, Fabian Lange wrote:
> It's not working as bootFeature, you mentioned that this should be possible JB.
> It looks like the bundle in startup.properties is started before
> bootFeatures is processed, and when thats done it refreshes the bundle
> nonetheless
> 
> Fabian
> 
> On Fri, Jan 18, 2019 at 1:23 PM Jean-Baptiste Onofré <jb@nanthrax.net> wrote:
>>
>> 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

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

Mime
View raw message