Re: layout optional?

[Matt Sicker]

Usually it's very minimal information like the log message and no metadata.

On 10 November 2015 at 09:53, Gary Gregory  wrote:

> Log4j Appenders usually create a default layout if one is not configured.
>
> Gary
> On Nov 10, 2015 7:22 AM, "Nicholas Duane"  wrote:
>
> > From reading the log4j2/log4net docs it appears adding a layout to an
> > appender is optional.  If I don't add a layout to an appender how does
> the
> > appender generate the string for the event?  Does it simply call
> > toString()/ToString() on the event object?  If that's the case then if we
> > want our event to have a specific format by default then I guess we need
> to
> > code that in toString()/ToString(), correct?
> >
> > Thanks,
> > Nick
> >
>



-- 
Matt Sicker 

Re: Log entries written to wrong file

[Chinh Do]

The manual (http://logging.apache.org/log4j/2.x/manual/logsep.html) says
you can follow step (3) below to get log separation. I am not clear on what
values to set for log4jContextName and log4jConfiguration, or how exactly
to do it on WebSphere 8.5 Has anyone done this? Really appreciate any help
in advance.
Using Context Selectors

There are a few patterns for achieving the desired state of logging
separation using ContextSelectors:

   1. Place the logging jars in the container's classpath and set the
   system property "Log4jContextSelector" to
   "org.apache.logging.log4j.core.selector.BasicContextSelector". This will
   create a single LoggerContext using a single configuration that will be
   shared across all applications.
   2. Place the logging jars in the container's classpath and use the
   default ClassLoaderContextSelector. Follow the instructions to
   initialize Log4j 2 in a web application
   . Each
   application can be configured to share the same configuration used at the
   container or can be individually configured. If status logging is set to
   debug in the configuration there will be output from when logging is
   initialized in the container and then again in each web application.
   3. Follow the instructions to initialize Log4j 2 in a web application
    and set the
   system property or servlet context parameter Log4jContextSelector to
   org.apache.logging.log4j.core.selector.JndiContextSelector. This will
   cause the container to use JNDI to locate each web application's
   LoggerContext. Be sure to set the isLog4jContextSelectorNamed context
   parameter to true and also set the log4jContextName and
   log4jConfiguration context parameters.

The exact method for setting system properties depends on the container.
For Tomcat, edit $CATALINA_HOME/conf/catalina.properties. Consult the
documentation for other web containers.

More info:
- log4j 2.1 with slf4j 1.7.12
- Not using Async Loggers right now (planning to use it later)
- WebSphere 8.5

On Mon, Nov 9, 2015 at 11:15 AM, Chinh Do  wrote:

> The manual (http://logging.apache.org/log4j/2.x/manual/logsep.html) says
> you can follow step (3) below to get log separation. I am not clear on what
> values to set for log4jContextName and log4jConfiguration. Has anyone done
> this?
> Using Context Selectors
>
> There are a few patterns for achieving the desired state of logging
> separation using ContextSelectors:
>
>1. Place the logging jars in the container's classpath and set the
>system property "Log4jContextSelector" to
>"org.apache.logging.log4j.core.selector.BasicContextSelector". This will
>create a single LoggerContext using a single configuration that will be
>shared across all applications.
>2. Place the logging jars in the container's classpath and use the
>default ClassLoaderContextSelector. Follow the instructions to
>initialize Log4j 2 in a web application
>. Each
>application can be configured to share the same configuration used at the
>container or can be individually configured. If status logging is set to
>debug in the configuration there will be output from when logging is
>initialized in the container and then again in each web application.
>3. Follow the instructions to initialize Log4j 2 in a web application
> and set the
>system property or servlet context parameter Log4jContextSelector to
>org.apache.logging.log4j.core.selector.JndiContextSelector. This will
>cause the container to use JNDI to locate each web application's
>LoggerContext. Be sure to set the isLog4jContextSelectorNamed context
>parameter to true and also set the log4jContextName and
>log4jConfiguration context parameters.
>
> The exact method for setting system properties depends on the container.
> For Tomcat, edit $CATALINA_HOME/conf/catalina.properties. Consult the
> documentation for other web containers.
>
> On Fri, Nov 6, 2015 at 8:43 AM, Chinh Do  wrote:
>
>> Hi Remko: I am using log4j 2.1 with slf4j 1.7.12. I am not using Async
>> Loggers right now (planning to use it later).
>>
>> Thanks
>>
>> On Thu, Nov 5, 2015 at 5:11 PM, Remko Popma 
>> wrote:
>>
>>> Two quick questions: What is your log4j2 version, and are you using
>>> Async Loggers?
>>>
>>> On Fri, Nov 6, 2015 at 2:17 AM, Chinh Do  wrote:
>>>
 Hi all,

 I am running multiple web apps (WARs) in the same WebSphere instance.
 Each
 web app has its own log4j2.xml and is configured to write to a separate
 log
 file. But I am seeing some log entries being written to the wrong log
 file.

 I think the problem is because we are using the log4j JARs in a shared
 

Re: Change log level on the fly?

[Gary Gregory]

The Configurator class had APIs just for this purpose.

Gary
On Nov 9, 2015 10:26 PM, "Matt Sicker"  wrote:

> Oh, good catch, never used the API like that outside of unit tests.
>
> On 9 November 2015 at 23:21, Ralph Goers 
> wrote:
>
> > Matt, the advice below won’t work properly. The LoggerConfig must be
> > modified, not the Logger. Then updateLoggers must be called (which will
> > update the logger’s level).
> >
> > Ralph
> >
> > > On Nov 9, 2015, at 9:07 PM, Matt Sicker  wrote:
> > >
> > > You can find the Logger from LogManager, cast to
> > > org.apache.logging.log4j.core.Logger, and use setLevel, though I bet
> > > there's a better way to do this via configuration files. You can reload
> > the
> > > configuration file and modify that from the user, but that might be
> > > overkill here.
> > >
> > > On 9 November 2015 at 21:59, John Lussmyer  > > wrote:
> > >
> > >> Looking at https://logging.apache.org/log4j/2.0/manual/jmx.html
> > >> Doesn't seem like the solution.
> > >> Asking the user to bring up jconsole seems rather excessive.
> > >> I just want to provide 3 radio buttons in my configuration.  Logging
> > >> Normal, Medium, Full.
> > >>
> > >> -Original Message-
> > >> From: Matt Sicker [mailto:boa...@gmail.com]
> > >> Sent: Monday, November 09, 2015 7:54 PM
> > >> To: Log4J Users List
> > >> Subject: Re: Change log level on the fly?
> > >>
> > >> Loggers can be reconfigured through JMX.
> > >>
> > >> On 9 November 2015 at 19:53, John Lussmyer 
> > wrote:
> > >>
> > >>> I'm hoping there is an easy to to just change the root level of my
> > >>> logger configuration on the fly.
> > >>> I want to be able to provide a configuration option to my users to
> > >>> turn up the logging level.
> > >>> I don't want to reconfigure everything, just change the level.
> > >>>
> > >>> Is there any easy way to do that?  Or do I have to build a
> > >>> Configuration factory?
> > >>>
> > >>>
> > >>> 
> > >>> Confidentiality notice: This message may contain confidential
> > >> information.
> > >>> It is intended only for the person to whom it is addressed. If you
> are
> > >>> not that person, you should not use this message. We request that you
> > >>> notify us by replying to this message, and then delete all copies
> > >>> including any contained in your reply. Thank you.
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Matt Sicker 
> > >>
> > >
> > >
> > >
> > > --
> > > Matt Sicker >
> >
> >
>
>
> --
> Matt Sicker 
>

layout optional?

[Nicholas Duane]

>From reading the log4j2/log4net docs it appears adding a layout to an appender 
>is optional.  If I don't add a layout to an appender how does the appender 
>generate the string for the event?  Does it simply call toString()/ToString() 
>on the event object?  If that's the case then if we want our event to have a 
>specific format by default then I guess we need to code that in 
>toString()/ToString(), correct?

Thanks,
Nick
  

Re: layout optional?

[Gary Gregory]

Log4j Appenders usually create a default layout if one is not configured.

Gary
On Nov 10, 2015 7:22 AM, "Nicholas Duane"  wrote:

> From reading the log4j2/log4net docs it appears adding a layout to an
> appender is optional.  If I don't add a layout to an appender how does the
> appender generate the string for the event?  Does it simply call
> toString()/ToString() on the event object?  If that's the case then if we
> want our event to have a specific format by default then I guess we need to
> code that in toString()/ToString(), correct?
>
> Thanks,
> Nick
>

Re: Log4j2 - HTML emails pattern

[Benjamin Jaton]

I am trying to use a logger in order to send "alerts" to the user. So for
me 1 log = 1 email (hence LOG4J2-1071).
I use the regular PatternLayout to produce a simple but full HTML page with
my alert email template.

For the HTMLLayout to be usable, it would have to allow to customize the
pattern, header and footer.
Bonus points if we could use the MDC in the email subject.

Ben

On Mon, Nov 9, 2015 at 11:48 AM, Gary Gregory 
wrote:

> Ben,
>
> Is there a way the current HTML layout could be customized to be better
> suited to your use-case?
>
> Gary
>
> On Mon, Nov 9, 2015 at 11:09 AM, Benjamin Jaton 
> wrote:
>
> > Thanks the feedback.
> > I found that the easiest way to achieve this was to have the
> PatternLayout
> > class support to set the contentType to "text/html".
> > Then one can write HTML directly in the pattern.
> >
> > Thanks again,
> > Ben
> >
> > On Mon, Nov 9, 2015 at 6:51 AM, Remko Popma 
> wrote:
> >
> > > Ben,
> > >
> > > The built-in HTML layout (
> > >
> >
> https://logging.apache.org/log4j/2.x/log4j-core/xref/org/apache/logging/log4j/core/layout/HtmlLayout.html
> > )
> > > does not support much customization.
> > >
> > > It sounds like you may want to create a custom layout and specify that
> > > layout with the SMTP appender.
> > >
> > > This manual page may be a good place to get started:
> > > http://logging.apache.org/log4j/2.x/manual/extending.html#Layouts
> > >
> > > Best regards,
> > > Remko
> > >
> > > > On 2015/11/06, at 4:55, Benjamin Jaton 
> > wrote:
> > > >
> > > > Hi,
> > > >
> > > > I am using the SMTPAppender with a custom pattern:
> > > >  "PatternLayout" : { "pattern" : "%m" }
> > > >
> > > > But the email is sent as text.
> > > >
> > > > I saw that there is a HTMLLayout but it doesn't seem to accept a
> > pattern?
> > > >
> > > > How can I produce a custom HTML message?
> > > >
> > > > Thanks!
> > > > Ben
> > >
> >
>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

RollingFileAppender maxDelayMillis?

[Benjamin Jaton]

Hi,

I am wondering if it would make sense to have a maxDelayMillis parameter
for the RollingFileAppender (like FlumeAppender).

Use case:
You have a web server access log, you produce an HTTP request and expect to
see it (and the response) in the access logs right away-ish (or at least
control how much you have to wait).

Thoughts?
Ben

Re: layout optional?

[Gary Gregory]

But sometimes it's a little more ;-)

See org.apache.logging.log4j.core.config.DefaultConfiguration.DEFAULT_PATTERN

Gary

On Tue, Nov 10, 2015 at 8:32 AM, Matt Sicker  wrote:

> Usually it's very minimal information like the log message and no metadata.
>
> On 10 November 2015 at 09:53, Gary Gregory  wrote:
>
> > Log4j Appenders usually create a default layout if one is not configured.
> >
> > Gary
> > On Nov 10, 2015 7:22 AM, "Nicholas Duane"  wrote:
> >
> > > From reading the log4j2/log4net docs it appears adding a layout to an
> > > appender is optional.  If I don't add a layout to an appender how does
> > the
> > > appender generate the string for the event?  Does it simply call
> > > toString()/ToString() on the event object?  If that's the case then if
> we
> > > want our event to have a specific format by default then I guess we
> need
> > to
> > > code that in toString()/ToString(), correct?
> > >
> > > Thanks,
> > > Nick
> > >
> >
>
>
>
> --
> Matt Sicker 
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: RollingFileAppender maxDelayMillis?

[Gary Gregory]

And more generally, can all appenders benefit from such a setting?

Gary

On Tue, Nov 10, 2015 at 11:04 AM, Benjamin Jaton 
wrote:

> Hi,
>
> I am wondering if it would make sense to have a maxDelayMillis parameter
> for the RollingFileAppender (like FlumeAppender).
>
> Use case:
> You have a web server access log, you produce an HTTP request and expect to
> see it (and the response) in the access logs right away-ish (or at least
> control how much you have to wait).
>
> Thoughts?
> Ben
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: RollingFileAppender maxDelayMillis?

[Remko Popma]

To check my understanding: the problem is that with bufferedIO=true the buffer 
contains log events that you want to see, but the buffer is only flushed to 
disk when it is full (which is not frequent enough); is that correct?

If you use AsyncAppender or Async Loggers, the buffer will be flushed when the 
queue is empty. This results in efficient IO (lumping together IO operations 
where possible), but at the same time your log file always reflects the most 
recent message. 

For synchronous buffered logging, I can see how a smarter flushing mechanism 
would be useful. 

Question is, what would trigger the check (whether the buffer needs to be 
flushed)? 

Easiest is to check with each log event, but if no new event arrives you still 
end up with a stale buffer. Better than nothing, but not great. 

An alternative is to check periodically from a background thread and flush if 
the buffer is non-empty. This probably gives the best results but is fairly 
complex to implement. 

I need to think about this a bit more, but for now I would suggest using async 
logging. It may be a good idea to create a Jira ticket for this. 

Remko 

> On 2015/11/11, at 5:16, Gary Gregory  wrote:
> 
> And more generally, can all appenders benefit from such a setting?
> 
> Gary
> 
> On Tue, Nov 10, 2015 at 11:04 AM, Benjamin Jaton 
> wrote:
> 
>> Hi,
>> 
>> I am wondering if it would make sense to have a maxDelayMillis parameter
>> for the RollingFileAppender (like FlumeAppender).
>> 
>> Use case:
>> You have a web server access log, you produce an HTTP request and expect to
>> see it (and the response) in the access logs right away-ish (or at least
>> control how much you have to wait).
>> 
>> Thoughts?
>> Ben
>> 
> 
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: RollingFileAppender maxDelayMillis?

[Remko Popma]

On Wed, Nov 11, 2015 at 2:34 PM, Benjamin Jaton 
wrote:

> On Tue, Nov 10, 2015 at 6:13 PM, Remko Popma 
> wrote:
>
> > To check my understanding: the problem is that with bufferedIO=true the
> > buffer contains log events that you want to see, but the buffer is only
> > flushed to disk when it is full (which is not frequent enough); is that
> > correct?
> >
>
> Yes that is correct.
> Typical scenario is when the server is not in production, so almost no
> traffic except for the request manually triggered by the operator, usually
> in order to debug something.
>
>
> > If you use AsyncAppender or Async Loggers, the buffer will be flushed
> when
> > the queue is empty. This results in efficient IO (lumping together IO
> > operations where possible), but at the same time your log file always
> > reflects the most recent message.
> >
>
> So I have a dumb question. What's the difference between bufferedIO and
> AsyncAppender?
> Isn't bufferedIO a kind of asynchronous treatment of the log messages? I'm
> sorry I'm a bit confused.
>

No problem at all. BufferedIO is not asynchronous. The difference between
bufferedIO and Async Appenders/Loggers is that the async stuff deals with a
queue of log event objects and happens further upstream, where bufferedIO
deals with a byte[] array buffer and happens further downstream.

When you use Async Appenders/Loggers, each time your application logs
something a Log Event object is added to a queue. A background thread takes
these events off the queue, asks the Layout to turn the event into a byte[]
array and uses the Appender to send these bytes to their destination.

Without Async Appenders/Loggers, there is no queue, and this work happens
in your application thread (the Layout turns the event into a byte[] array
and the Appender sends these bytes to their destination).

When the configuration has bufferedIO="true", the Appender will save up the
byte[] arrays for multiple log events together in an in-memory buffer first
instead of writing each byte[] array to its destination immediately,
to reduce the number of expensive I/O operations. As you noticed, this
sometimes results in data sitting in this in-memory buffer for a long time.

Now, with Async Appenders/Loggers, we can use what Martin Thompson calls "smart
batching
": when
the background thread processes a log event, it checks if the queue is now
empty (no further log events are in the pipeline to be processed) and if it
is, it will also call Appender.flush() in addition to the above.



> >
> > For synchronous buffered logging, I can see how a smarter flushing
> > mechanism would be useful.
> >
> > Question is, what would trigger the check (whether the buffer needs to be
> > flushed)?
> >
> > Easiest is to check with each log event, but if no new event arrives you
> > still end up with a stale buffer. Better than nothing, but not great.
> >
> > An alternative is to check periodically from a background thread and
> flush
> > if the buffer is non-empty. This probably gives the best results but is
> > fairly complex to implement.
> >
>
> That was what I had in mind but I don't know the complexity.
>
>
> >
> > I need to think about this a bit more, but for now I would suggest using
> > async logging. It may be a good idea to create a Jira ticket for this.
> >
>
> OK I will create a Jira for this.
>
>
> >
> > Remko
> >
> > > On 2015/11/11, at 5:16, Gary Gregory  wrote:
> > >
> > > And more generally, can all appenders benefit from such a setting?
> > >
> > > Gary
> > >
> > > On Tue, Nov 10, 2015 at 11:04 AM, Benjamin Jaton <
> > benjamin.ja...@gmail.com>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> I am wondering if it would make sense to have a maxDelayMillis
> parameter
> > >> for the RollingFileAppender (like FlumeAppender).
> > >>
> > >> Use case:
> > >> You have a web server access log, you produce an HTTP request and
> > expect to
> > >> see it (and the response) in the access logs right away-ish (or at
> least
> > >> control how much you have to wait).
> > >>
> > >> Thoughts?
> > >> Ben
> > >>
> > >
> > >
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > Java Persistence with Hibernate, Second Edition
> > > 
> > > JUnit in Action, Second Edition 
> > > Spring Batch in Action 
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> >
> > -
> > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >
> >
>

Re: Log4j2 - HTML emails pattern

[Matt Sicker]

It seems abusive, but couldn't you just use the PatternLayout and
interweave HTML?

On 10 November 2015 at 11:57, Benjamin Jaton 
wrote:

> I am trying to use a logger in order to send "alerts" to the user. So for
> me 1 log = 1 email (hence LOG4J2-1071).
> I use the regular PatternLayout to produce a simple but full HTML page with
> my alert email template.
>
> For the HTMLLayout to be usable, it would have to allow to customize the
> pattern, header and footer.
> Bonus points if we could use the MDC in the email subject.
>
> Ben
>
> On Mon, Nov 9, 2015 at 11:48 AM, Gary Gregory 
> wrote:
>
> > Ben,
> >
> > Is there a way the current HTML layout could be customized to be better
> > suited to your use-case?
> >
> > Gary
> >
> > On Mon, Nov 9, 2015 at 11:09 AM, Benjamin Jaton <
> benjamin.ja...@gmail.com>
> > wrote:
> >
> > > Thanks the feedback.
> > > I found that the easiest way to achieve this was to have the
> > PatternLayout
> > > class support to set the contentType to "text/html".
> > > Then one can write HTML directly in the pattern.
> > >
> > > Thanks again,
> > > Ben
> > >
> > > On Mon, Nov 9, 2015 at 6:51 AM, Remko Popma 
> > wrote:
> > >
> > > > Ben,
> > > >
> > > > The built-in HTML layout (
> > > >
> > >
> >
> https://logging.apache.org/log4j/2.x/log4j-core/xref/org/apache/logging/log4j/core/layout/HtmlLayout.html
> > > )
> > > > does not support much customization.
> > > >
> > > > It sounds like you may want to create a custom layout and specify
> that
> > > > layout with the SMTP appender.
> > > >
> > > > This manual page may be a good place to get started:
> > > > http://logging.apache.org/log4j/2.x/manual/extending.html#Layouts
> > > >
> > > > Best regards,
> > > > Remko
> > > >
> > > > > On 2015/11/06, at 4:55, Benjamin Jaton 
> > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I am using the SMTPAppender with a custom pattern:
> > > > >  "PatternLayout" : { "pattern" : "%m" }
> > > > >
> > > > > But the email is sent as text.
> > > > >
> > > > > I saw that there is a HTMLLayout but it doesn't seem to accept a
> > > pattern?
> > > > >
> > > > > How can I produce a custom HTML message?
> > > > >
> > > > > Thanks!
> > > > > Ben
> > > >
> > >
> >
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> > 
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
> >
>



-- 
Matt Sicker 

Re: RollingFileAppender maxDelayMillis?

[Benjamin Jaton]

On Tue, Nov 10, 2015 at 6:13 PM, Remko Popma  wrote:

> To check my understanding: the problem is that with bufferedIO=true the
> buffer contains log events that you want to see, but the buffer is only
> flushed to disk when it is full (which is not frequent enough); is that
> correct?
>

Yes that is correct.
Typical scenario is when the server is not in production, so almost no
traffic except for the request manually triggered by the operator, usually
in order to debug something.


> If you use AsyncAppender or Async Loggers, the buffer will be flushed when
> the queue is empty. This results in efficient IO (lumping together IO
> operations where possible), but at the same time your log file always
> reflects the most recent message.
>

So I have a dumb question. What's the difference between bufferedIO and
AsyncAppender?
Isn't bufferedIO a kind of asynchronous treatment of the log messages? I'm
sorry I'm a bit confused.


>
> For synchronous buffered logging, I can see how a smarter flushing
> mechanism would be useful.
>
> Question is, what would trigger the check (whether the buffer needs to be
> flushed)?
>
> Easiest is to check with each log event, but if no new event arrives you
> still end up with a stale buffer. Better than nothing, but not great.
>
> An alternative is to check periodically from a background thread and flush
> if the buffer is non-empty. This probably gives the best results but is
> fairly complex to implement.
>

That was what I had in mind but I don't know the complexity.


>
> I need to think about this a bit more, but for now I would suggest using
> async logging. It may be a good idea to create a Jira ticket for this.
>

OK I will create a Jira for this.


>
> Remko
>
> > On 2015/11/11, at 5:16, Gary Gregory  wrote:
> >
> > And more generally, can all appenders benefit from such a setting?
> >
> > Gary
> >
> > On Tue, Nov 10, 2015 at 11:04 AM, Benjamin Jaton <
> benjamin.ja...@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> I am wondering if it would make sense to have a maxDelayMillis parameter
> >> for the RollingFileAppender (like FlumeAppender).
> >>
> >> Use case:
> >> You have a web server access log, you produce an HTTP request and
> expect to
> >> see it (and the response) in the access logs right away-ish (or at least
> >> control how much you have to wait).
> >>
> >> Thoughts?
> >> Ben
> >>
> >
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> > 
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>
>

Re: Log4j2 - HTML emails pattern

[Benjamin Jaton]

You mean just put HTML in the pattern directly?
You need to content type of the email to be set to text/html, other you
would just see the HTML code in the email.

On Tue, Nov 10, 2015 at 9:21 PM, Matt Sicker  wrote:

> It seems abusive, but couldn't you just use the PatternLayout and
> interweave HTML?


> On 10 November 2015 at 11:57, Benjamin Jaton 
> wrote:
>
> > I am trying to use a logger in order to send "alerts" to the user. So for
> > me 1 log = 1 email (hence LOG4J2-1071).
> > I use the regular PatternLayout to produce a simple but full HTML page
> with
> > my alert email template.
> >
> > For the HTMLLayout to be usable, it would have to allow to customize the
> > pattern, header and footer.
> > Bonus points if we could use the MDC in the email subject.
> >
> > Ben
> >
> > On Mon, Nov 9, 2015 at 11:48 AM, Gary Gregory 
> > wrote:
> >
> > > Ben,
> > >
> > > Is there a way the current HTML layout could be customized to be better
> > > suited to your use-case?
> > >
> > > Gary
> > >
> > > On Mon, Nov 9, 2015 at 11:09 AM, Benjamin Jaton <
> > benjamin.ja...@gmail.com>
> > > wrote:
> > >
> > > > Thanks the feedback.
> > > > I found that the easiest way to achieve this was to have the
> > > PatternLayout
> > > > class support to set the contentType to "text/html".
> > > > Then one can write HTML directly in the pattern.
> > > >
> > > > Thanks again,
> > > > Ben
> > > >
> > > > On Mon, Nov 9, 2015 at 6:51 AM, Remko Popma 
> > > wrote:
> > > >
> > > > > Ben,
> > > > >
> > > > > The built-in HTML layout (
> > > > >
> > > >
> > >
> >
> https://logging.apache.org/log4j/2.x/log4j-core/xref/org/apache/logging/log4j/core/layout/HtmlLayout.html
> > > > )
> > > > > does not support much customization.
> > > > >
> > > > > It sounds like you may want to create a custom layout and specify
> > that
> > > > > layout with the SMTP appender.
> > > > >
> > > > > This manual page may be a good place to get started:
> > > > > http://logging.apache.org/log4j/2.x/manual/extending.html#Layouts
> > > > >
> > > > > Best regards,
> > > > > Remko
> > > > >
> > > > > > On 2015/11/06, at 4:55, Benjamin Jaton  >
> > > > wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am using the SMTPAppender with a custom pattern:
> > > > > >  "PatternLayout" : { "pattern" : "%m" }
> > > > > >
> > > > > > But the email is sent as text.
> > > > > >
> > > > > > I saw that there is a HTMLLayout but it doesn't seem to accept a
> > > > pattern?
> > > > > >
> > > > > > How can I produce a custom HTML message?
> > > > > >
> > > > > > Thanks!
> > > > > > Ben
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > > Java Persistence with Hibernate, Second Edition
> > > 
> > > JUnit in Action, Second Edition 
> > > Spring Batch in Action 
> > > Blog: http://garygregory.wordpress.com
> > > Home: http://garygregory.com/
> > > Tweet! http://twitter.com/GaryGregory
> > >
> >
>
>
>
> --
> Matt Sicker 
>