Re: Read-only logging config causing exceptions
Done. https://issues.apache.org/jira/browse/FELIX-6519 Thanks JB! G On Tue, Apr 5, 2022 at 11:35 PM Jean-Baptiste Onofré wrote: > Hi Greg, > > Yes, it's "normal". Let me explain. To avoid an infinite loop when you > are logged in via ssh, log:* commands (log:tail and log:display for > instance) are changing default org.ops4j.pax.logging configuration. > So, if the config files are read only, configadmin won't be able to update. > > It's something I did for 3.4.6 a while ago. > > However I can update the logic a bit to deal with the read only case. > > Do you mind creating a Jira about that ? > > Regards > JB > > Regards > JB > > On Tue, Apr 5, 2022 at 9:36 PM Greg Logan wrote: > > > > Hi all, > > > > We are looking at upgrading from Karaf 3.4.3 to 3.4.6, and noticed an > odd behaviour. If your Karaf config files are read only (say, in a docker > container) and you try to run log:tail you get an immediate stack > trace[1]. Is this intended behaviour? It's not blocking our ability to > upgrade since it works fine 99% of the time, but it seems like odd > behaviour to me - especially since it doesn't happen in 3.4.3! > > > > Thanks, > > G > > > > 1: > https://github.com/opencast/opencast/pull/3542#issuecomment-1078458078 >
Re: Read-only logging config causing exceptions
Hi Greg, Yes, it's "normal". Let me explain. To avoid an infinite loop when you are logged in via ssh, log:* commands (log:tail and log:display for instance) are changing default org.ops4j.pax.logging configuration. So, if the config files are read only, configadmin won't be able to update. It's something I did for 3.4.6 a while ago. However I can update the logic a bit to deal with the read only case. Do you mind creating a Jira about that ? Regards JB Regards JB On Tue, Apr 5, 2022 at 9:36 PM Greg Logan wrote: > > Hi all, > > We are looking at upgrading from Karaf 3.4.3 to 3.4.6, and noticed an odd > behaviour. If your Karaf config files are read only (say, in a docker > container) and you try to run log:tail you get an immediate stack trace[1]. > Is this intended behaviour? It's not blocking our ability to upgrade since > it works fine 99% of the time, but it seems like odd behaviour to me - > especially since it doesn't happen in 3.4.3! > > Thanks, > G > > 1: https://github.com/opencast/opencast/pull/3542#issuecomment-1078458078
Read-only logging config causing exceptions
Hi all, We are looking at upgrading from Karaf 3.4.3 to 3.4.6, and noticed an odd behaviour. If your Karaf config files are read only (say, in a docker container) and you try to run log:tail you get an immediate stack trace[1]. Is this intended behaviour? It's not blocking our ability to upgrade since it works fine 99% of the time, but it seems like odd behaviour to me - especially since it doesn't happen in 3.4.3! Thanks, G 1: https://github.com/opencast/opencast/pull/3542#issuecomment-1078458078
Re: Logging config
racker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415) > [?:?] > at > org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232) [?:?] > at > org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444) > [?:?] > at > org.apache.felix.framework.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:915) > [?:?] > at > org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:834) > [?:?] > at > org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:516) > [?:?] > at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4579) > [?:?] > at org.apache.felix.framework.Felix.startBundle(Felix.java:2174) [?:?] > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) [?:?] > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308) > [?:?] > at java.lang.Thread.run(Thread.java:844) [?:?] > > -Original Message- > From: Jean-Baptiste Onofré > Sent: Saturday, October 13, 2018 12:01 AM > To: user@karaf.apache.org > Subject: Re: Logging config > > Hi, > > Not sure I fully understand what you mean, but it depends of the application > and the logger in used. > > You can set off level for a specific logger. > > Regards > JB > > On 12/10/2018 18:11, Leschke, Scott wrote: >> Is there any way to cause Karaf to suppress logging the full exception >> stack and instead just log the exception type and message for one or >> more bundles? >> >> >> >> There are occasions that I want to fail a service activation because >> of a configuration error but I really don't need or want a full trace >> of the IllegalArgumentException that was thrown. >> >> >> >> Scott >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Re: Logging config
ked.customizerModified(BundleTracker.java:415) > [?:?] > at > org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232) [?:?] > at > org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444) > [?:?] > at > org.apache.felix.framework.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:915) > [?:?] > at > org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:834) > [?:?] > at > org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:516) > [?:?] > at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4579) > [?:?] > at org.apache.felix.framework.Felix.startBundle(Felix.java:2174) [?:?] > at > org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) [?:?] > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308) > [?:?] > at java.lang.Thread.run(Thread.java:844) [?:?] > > -Original Message- > From: Jean-Baptiste Onofré > Sent: Saturday, October 13, 2018 12:01 AM > To: user@karaf.apache.org > Subject: Re: Logging config > > Hi, > > Not sure I fully understand what you mean, but it depends of the application > and the logger in used. > > You can set off level for a specific logger. > > Regards > JB > > On 12/10/2018 18:11, Leschke, Scott wrote: >> Is there any way to cause Karaf to suppress logging the full exception >> stack and instead just log the exception type and message for one or >> more bundles? >> >> >> >> There are occasions that I want to fail a service activation because >> of a configuration error but I really don't need or want a full trace >> of the IllegalArgumentException that was thrown. >> >> >> >> Scott >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
RE: Logging config
$MultipleDynamicCustomizer.addedService(DependencyManager.java:302) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1216) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerAdded(ServiceTracker.java:1137) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.trackAdding(ServiceTracker.java:944) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.track(ServiceTracker.java:880) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1168) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.BundleComponentActivator$ListenerInfo.serviceChanged(BundleComponentActivator.java:125) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.framework.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:990) [?:?] at org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:838) [?:?] at org.apache.felix.framework.EventDispatcher.fireServiceEvent(EventDispatcher.java:545) [?:?] at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4595) [?:?] at org.apache.felix.framework.Felix.registerService(Felix.java:3587) [?:?] at org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.java:348) [?:?] at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:891) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.manager.AbstractComponentManager$3.register(AbstractComponentManager.java:877) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.manager.RegistrationManager.changeRegistration(RegistrationManager.java:128) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.manager.AbstractComponentManager.registerService(AbstractComponentManager.java:944) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:727) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.manager.AbstractComponentManager.enableInternal(AbstractComponentManager.java:661) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:427) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:665) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:339) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:381) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.Activator.access$200(Activator.java:49) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:263) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:169) [93:org.apache.felix.scr:2.1.2] at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:49) [93:org.apache.felix.scr:2.1.2] at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482) [?:?] at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415) [?:?] at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232) [?:?] at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444) [?:?] at org.apache.felix.framework.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:915) [?:?] at org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:834) [?:?] at org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:516) [?:?] at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4579) [?:?] at org.apache.felix.framework.Felix.startBundle(Felix.java:2174) [?:?] at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1373) [?:?] at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308) [?:?] at java.lang.Thread.run(Thread.java:844) [?:?] -Original Message- From: Jean-Baptiste Onofré Sent: Saturday, October 13, 2018 12:01 AM To: user@karaf.apache.org Subject: Re: Logging config Hi, Not sure I fully
Re: Logging config
Hi, Not sure I fully understand what you mean, but it depends of the application and the logger in used. You can set off level for a specific logger. Regards JB On 12/10/2018 18:11, Leschke, Scott wrote: > Is there any way to cause Karaf to suppress logging the full exception > stack and instead just log the exception type and message for one or > more bundles? > > > > There are occasions that I want to fail a service activation because of > a configuration error but I really don’t need or want a full trace of > the IllegalArgumentException that was thrown. > > > > Scott > -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
Logging config
Is there any way to cause Karaf to suppress logging the full exception stack and instead just log the exception type and message for one or more bundles? There are occasions that I want to fail a service activation because of a configuration error but I really don't need or want a full trace of the IllegalArgumentException that was thrown. Scott
