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
>
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
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
ately(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.startB
> 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) [?:?]
>
, 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
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
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
