How to write encrypted (!) lines to logfile ?
As far as I know the standard way of writing log output to logfiles is as plain human readable text. Is there a way to configure log4j to enrypt lines before writing? Or (re-)encrypt whole logfile after writing? The encryption should NOT take place IN the writing application but be configured inside log4j configuration. Ben - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: How to write encrypted (!) lines to logfile ?
Interesting! Currently there's no such feature, but would you mind raising a feature request in the log4j2 Jira issue tracker? Thanks! Remko Sent from my iPhone On 2014/12/19, at 19:43, Ben Stover bxsto...@yahoo.co.uk wrote: As far as I know the standard way of writing log output to logfiles is as plain human readable text. Is there a way to configure log4j to enrypt lines before writing? Or (re-)encrypt whole logfile after writing? The encryption should NOT take place IN the writing application but be configured inside log4j configuration. Ben - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: How to write encrypted (!) lines to logfile ?
I started going this a while back in the pre 2.0 days but could take the time to finish. The configuration is complicated though. I'll revisit during the holidays... Gary div Original message /divdivFrom: Remko Popma remko.po...@gmail.com /divdivDate:12/19/2014 06:43 (GMT-05:00) /divdivTo: Log4J Users List log4j-user@logging.apache.org /divdivCc: /divdivSubject: Re: How to write encrypted (!) lines to logfile ? /divdiv /divInteresting! Currently there's no such feature, but would you mind raising a feature request in the log4j2 Jira issue tracker? Thanks! Remko Sent from my iPhone On 2014/12/19, at 19:43, Ben Stover bxsto...@yahoo.co.uk wrote: As far as I know the standard way of writing log output to logfiles is as plain human readable text. Is there a way to configure log4j to enrypt lines before writing? Or (re-)encrypt whole logfile after writing? The encryption should NOT take place IN the writing application but be configured inside log4j configuration. Ben - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Race condition stopping context
Hello, I have an application in which I'm using all async loggers. When I stop the LoggerContext, there're still some events waiting in disruptor's buffer and when it tries to execute them the context is already closed and thus those events are lost. Is there some kind of hook, callback or whatever I can use so that when the context is stopped: - the loggers stop accepting new messages - the context waits for disruptor's buffer to be empty before actually stopping Thanks
Using markers or ThreadContext to select logger via slf4j
I have some libraries that leverage slf4j for logging (can't change it) however my application leverages log4j2 and the slf4j-log4j2 bridge. I was wondering if there is a way I can at the beginning of the request flow set a value in the ThreadContext or something so that the slf4j loggers will route to a specific log4j2 logger instead of the root logger. Is this possible? Thanks, James
Re: Race condition stopping context
We used to have this problem in older versions but these issues have been addressed in 2.1 as far as I know. Which version are you using? Sent from my iPhone On 2014/12/19, at 22:01, Mariano Gonzalez mariano.l.gonza...@gmail.com wrote: Hello, I have an application in which I'm using all async loggers. When I stop the LoggerContext, there're still some events waiting in disruptor's buffer and when it tries to execute them the context is already closed and thus those events are lost. Is there some kind of hook, callback or whatever I can use so that when the context is stopped: - the loggers stop accepting new messages - the context waits for disruptor's buffer to be empty before actually stopping Thanks - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Race condition stopping context
Hello Remko, I'm using 2.1. Any pointers ? On Fri, Dec 19, 2014 at 11:20 AM, Remko Popma remko.po...@gmail.com wrote: We used to have this problem in older versions but these issues have been addressed in 2.1 as far as I know. Which version are you using? Sent from my iPhone On 2014/12/19, at 22:01, Mariano Gonzalez mariano.l.gonza...@gmail.com wrote: Hello, I have an application in which I'm using all async loggers. When I stop the LoggerContext, there're still some events waiting in disruptor's buffer and when it tries to execute them the context is already closed and thus those events are lost. Is there some kind of hook, callback or whatever I can use so that when the context is stopped: - the loggers stop accepting new messages - the context waits for disruptor's buffer to be empty before actually stopping Thanks - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Using markers or ThreadContext to select logger via slf4j
What do you mean by “request flow”? You can certainly do this in your code. Ralph On Dec 19, 2014, at 6:10 AM, James Hutton james.a.hut...@gmail.com wrote: I have some libraries that leverage slf4j for logging (can't change it) however my application leverages log4j2 and the slf4j-log4j2 bridge. I was wondering if there is a way I can at the beginning of the request flow set a value in the ThreadContext or something so that the slf4j loggers will route to a specific log4j2 logger instead of the root logger. Is this possible? Thanks, James - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Using markers or ThreadContext to select logger via slf4j
So for example a cxf interceptor that is using slf4j internally, I'd like to add an interceptor before it to add items to the ThreadContext that would cause getLogger(Class) to return a different logger based upon the value set in the ThreadContext. On Fri, Dec 19, 2014 at 9:55 AM, Ralph Goers ralph.go...@dslextreme.com wrote: What do you mean by “request flow”? You can certainly do this in your code. Ralph On Dec 19, 2014, at 6:10 AM, James Hutton james.a.hut...@gmail.com wrote: I have some libraries that leverage slf4j for logging (can't change it) however my application leverages log4j2 and the slf4j-log4j2 bridge. I was wondering if there is a way I can at the beginning of the request flow set a value in the ThreadContext or something so that the slf4j loggers will route to a specific log4j2 logger instead of the root logger. Is this possible? Thanks, James - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Race condition stopping context
Hello,
I've been taking a look at LoggerContext#stop() and for what I see there's
code to prevent disruptor to take new messages but there's nothing making
sure that the ring buffer is empty before actually closing up.
I did a simple test with an Appender wrapper like this:
final class StopConditionSafeAppenderWrapper extends BaseAppenderWrapper
{
private final LoggerContext loggerContext;
StopConditionSafeAppenderWrapper(Appender delegate, LoggerContext
loggerContext)
{
super(delegate);
this.loggerContext = loggerContext;
}
@Override
public void append(LogEvent event)
{
if (!loggerContext.isStarted()) {
return;
}
super.append(event);
}
}
Using this appender wrapper I still get the same error, because at the time
that append was closed the context was started but by the time disruptor
processed it it was already stopped (this I could verify with a debugger).
Should I open a bug? Any workaround you could suggest?
Thanks!
