Re: SCR Bundle refreshes Pax Logging?
Again, that's pax-logging specific because pax-logging starts in the very early stage. I think that the best fix is actually to implement kind of locator in pax-logging. Regards JB On 18/01/2019 13:59, Fabian Lange wrote: > Thats a pit, because it is the no longer under the control of a > feature, and then version updates cause a new bundle rather than > replace the old. > > Tricky. I will experiment some more, looking forward to a cleanup in > pax logging! > > Thanks for all the interesting tips and tricks > > Fabian > > On Fri, Jan 18, 2019 at 1:49 PM Jean-Baptiste Onofré > wrote: >> >> 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é >>> 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 > 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é >> 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é >>> 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 >>> 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é >>> >>> >>> 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
Re: SCR Bundle refreshes Pax Logging?
Thats a pit, because it is the no longer under the control of a feature, and then version updates cause a new bundle rather than replace the old. Tricky. I will experiment some more, looking forward to a cleanup in pax logging! Thanks for all the interesting tips and tricks Fabian On Fri, Jan 18, 2019 at 1:49 PM Jean-Baptiste Onofré wrote: > > 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é > > 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 > >>> 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é > 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é > >> > > 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 > > 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é > > >> > > 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
Re: SCR Bundle refreshes Pax Logging?
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é > 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 >>> 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é 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é > 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 > 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é > > > 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 > 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 <
Re: SCR Bundle refreshes Pax Logging?
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é 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 > > 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é > >> 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é > >>> 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 > >>> 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é > >>> > >>> 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 > >>> 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
Re: SCR Bundle refreshes Pax Logging?
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 > 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é 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é >>> 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 >>> 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é >>> >>> 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 >>> 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é >>> napisał(a): >
Re: SCR Bundle refreshes Pax Logging?
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 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é 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é > > 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 > > 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é > > > > 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 > > 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é > > napisał(a): > > > > > >> Not a problem, Jira should be used when we "suspect" something. > > I > > think > > >> it's good for the tracking and
Re: SCR Bundle refreshes Pax Logging?
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é 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é > 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 > 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é > > 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 > 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é > 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
Re: SCR Bundle refreshes Pax Logging?
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é > 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 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é 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 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 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é 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
Re: SCR Bundle refreshes Pax Logging?
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é 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 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é > >> 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 > >> 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 > >> 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é > >> 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 >
Re: SCR Bundle refreshes Pax Logging?
It sounds reasonable. Agree to improve pax-logging in that way. Regards JB On 17/01/2019 20:29, Robert Varga wrote: > 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. > > Yes, and also it would be nice to have a basic slim core jar and have > rest optionally delivered -- I bet most deployments would use much less > than 1.8MiB this is currently costing... > > Regards, > Robert > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: SCR Bundle refreshes Pax Logging?
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 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é >> 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 >> 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 >> 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é >> 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
Re: SCR Bundle refreshes Pax Logging?
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 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é > 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 > 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 > 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é > > >>> 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 > >
Re: SCR Bundle refreshes Pax Logging?
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é 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 > > 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 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 > >>> 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é > >>> 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
Re: SCR Bundle refreshes Pax Logging?
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 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 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 >>> 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é >>> 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
Re: SCR Bundle refreshes Pax Logging?
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 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 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 > > 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é > > 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│
Re: SCR Bundle refreshes Pax Logging?
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 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 > 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é > 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
Re: SCR Bundle refreshes Pax Logging?
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 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é >> 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é >>> 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 >>> 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] >>>
Re: SCR Bundle refreshes Pax Logging?
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é 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é > 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 > 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/0x0007fecd0c40 > 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
Re: SCR Bundle refreshes Pax Logging?
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é > 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 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/0x0007fecd0c40 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
Re: SCR Bundle refreshes Pax Logging?
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é 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 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/0x0007fecd0c40 > >> 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
Re: SCR Bundle refreshes Pax Logging?
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 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/0x0007fecd0c40 >> 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
