Agreed, some sort of postProcessInterceptor/marshallingInteceptor would make 
sense.. detect any fields that have ’secret’ annotation and mask them out using 
the same mask character that is used for the console (also set via annotation).

Matt

> On Oct 2, 2025, at 11:43 PM, Jean-Baptiste Onofré <[email protected]> wrote:
> 
> I think that’s in the pax logging handling that we should improve that. 
> Because it could be also a concern to include the whole log event message in 
> the thread name. 
> 
> About the display of sensitive information like password in the console, it’s 
> not a log:log issue (or even a karaf console issue). I would consider as a 
> felix gogo thing. That said, we can certainly find workaround in Karaf shell 
> console for that (using interceptor with pattern detection for instance). 
> 
> Regards
> JB
> 
> Le mer. 1 oct. 2025 à 15:23, Matt Pavlovich <[email protected] 
> <mailto:[email protected]>> a écrit :
>> Your logging configuration must be using a pattern that includes the thread 
>> name in the log output. You can remove that macro, or configure a separate 
>> log appender for the packages you want to filter and give that a different 
>> logging pattern without the thread macro.
>> 
>> -Matt 
>> 
>> > On Oct 1, 2025, at 5:35 AM, Ephemeris Lappis <[email protected] 
>> > <mailto:[email protected]>> wrote:
>> > 
>> > Hello.
>> > 
>> > We need to use the Karaf's shell "log" command to trace actions during 
>> > some deployment opérations..
>> > 
>> > We've seen that the thread name using the "log:log" command is the command 
>> > itself, producing very big lines in the log file.
>> > 
>> > Example :
>> > admin@root()> log:log --level WARNING "A very very long text..."
>> > 12:29:39.362 WARN  [pipe-log:log --level WARNING "A very very long 
>> > text..."] A very very long text...
>> > 
>> > The thread name is "pipe-log:log --level WARNING "A very very long 
>> > text...""
>> > 
>> > In reality, messages may be actually bigger, since we want to trace very 
>> > detailed information about the current deployments.
>> > 
>> > Is there any way to avoid this ?
>> > 
>> > Thanks in advance for your help.
>> > 
>> > Regards.
>> 

Reply via email to