I would say no. It may make sense for some appenders to have a default
layout, and we should keep it for those which already have it for BC
reasons.
But I don't think we should provide default layout for those appenders
which do not already have it, and we should not force all future appenders
to
Thanks, Remko! Sounds reasonable. ;)
On 09/13/2016 03:40 PM, Remko Popma wrote:
Looking at the configuration, you have a RandomAccessFile appender (not a
RollingRandomAccessFile appender) that you are trying to set a rollover policy
on.
Changing the appender type should fix it.
Remko
Sent f
Looking at the configuration, you have a RandomAccessFile appender (not a
RollingRandomAccessFile appender) that you are trying to set a rollover policy
on.
Changing the appender type should fix it.
Remko
Sent from my iPhone
> On 2016/09/13, at 18:24, Steffen Offermann
> wrote:
>
> It lo
It looks like this has already happened with Log4j2 v2.6.2, too.
On 09/13/2016 11:13 AM, Steffen Offermann wrote:
Nope, recreation of the custom Logger did not solve the problem.
On 09/13/2016 10:56 AM, Steffen Offermann wrote:
I guess I have an idea what might cause the error messages: We use
Nope, recreation of the custom Logger did not solve the problem.
On 09/13/2016 10:56 AM, Steffen Offermann wrote:
I guess I have an idea what might cause the error messages: We use a custom
Logger implementation (to provide factory methods for our custom log levels).
The current master version
I guess I have an idea what might cause the error messages: We use a custom Logger implementation (to provide factory methods for our custom log levels). The current master version of Log4j2 may not
be compatible with the generated Logger any more, so it has to be regenerated.
I'll have to talk
This is the log4j2 configuration for the respective WAR (note that we use
custom log levels):
{
"configuration" : {
"status" : "warn",
"name" : "OID",
"packages" : "com.aixigo.tec.logging",
"appenders" : {
"appender" : [
{
"type" : "
What is the configuration that generates this error?
Sent from my iPhone
> On 2016/09/13, at 16:10, Steffen Offermann
> wrote:
>
> I cannot see any real consequences yet, but in catalina.out I find:
>
>2016-09-13 09:08:24,616 localhost-startStop-9 ERROR appender has no
> parameter that m
I cannot see any real consequences yet, but in catalina.out I find:
2016-09-13 09:08:24,616 localhost-startStop-9 ERROR appender has no
parameter that matches element policies
2016-09-13 09:08:24,618 localhost-startStop-9 ERROR appender has no
parameter that matches element policies
Re
I have to take a look at the respective code (I did not write it), but it seems I can already give the all-clear: The latest master does not break any of our logging-specific test cases any more
(except within Eclipse, but that's probably related to a very specific requirement of ours in those tes
On Sun, Sep 11, 2016 at 10:55 PM, Gary Gregory
wrote:
> I understand now, thank you. All build methods do not use the same
> default. I'll remove the @Required tomorrow.
>
Done.
Gary
> Gary
>
> On Sep 11, 2016 9:11 PM, "Matt Sicker" wrote:
>
>> I mean if you do something like this:
>>
>> @Plu
Steffen, is the code you're looking at using the factory methods? Or are
you using the builder class?
On 12 September 2016 at 02:33, Steffen Offermann <
steffen.offerm...@aixigo.de> wrote:
>
> Nope, this does not work. The test case mentioned in LOG4J2-1573 works if
> I remove the @Required annot
Nope, this does not work. The test case mentioned in LOG4J2-1573 works if I
remove the @Required annotation, like Gary suggested, but then most of the
other tests break.
Regards,
Steffen
On 09/12/2016 09:17 AM, Steffen Offermann wrote:
Hmmm, would that still guarantee the correct defaults
Hmmm, would that still guarantee the correct defaults (as mentioned in the
documentation) though?
On 09/12/2016 09:16 AM, Steffen Offermann wrote:
Looks like this would also fix
https://issues.apache.org/jira/browse/LOG4J2-1573. I'll try that shortly.
On 09/12/2016 07:55 AM, Gary Gregory wro
Looks like this would also fix
https://issues.apache.org/jira/browse/LOG4J2-1573. I'll try that shortly.
On 09/12/2016 07:55 AM, Gary Gregory wrote:
I understand now, thank you. All build methods do not use the same default.
I'll remove the @Required tomorrow.
Gary
On Sep 11, 2016 9:11 PM,
I understand now, thank you. All build methods do not use the same default.
I'll remove the @Required tomorrow.
Gary
On Sep 11, 2016 9:11 PM, "Matt Sicker" wrote:
> I mean if you do something like this:
>
> @PluginElement("Layout")
> @Required
> private Layout layout = PatternLayout.defaultLayo
I mean if you do something like this:
@PluginElement("Layout")
@Required
private Layout layout = PatternLayout.defaultLayout();
Then it should work. But if you defer the creation of a default layout
until you execute the build() method, then the validator will err out
before build() is called.
O
HI Matt,
Right now, all of the build() methods handle null layouts by using a
default layout. That works for programmatic configs. But in order for that
to work from a config file, the @Required needs to be removed.
I feel like I am not understanding something in your message :-(
Gary
On Sun, S
I thought that @Required would check the field at build time, not injection
time. If the field was set to null, then you're going to have a bad time.
On 11 September 2016 at 10:50, Gary Gregory wrote:
> I forgot to say that:
>
> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder.buil
I forgot to say that:
org.apache.logging.log4j.core.appender.ConsoleAppender.Builder.build()
org.apache.logging.log4j.core.appender.FileAppender.Builder.build()
org.apache.logging.log4j.core.appender.RollingFileAppender.Builder.build()
org.apache.logging.log4j.core.appender.SocketAppender.Builder.
I'm pretty sure we no longer need @Required on layout on
org.apache.logging.log4j.core.appender.AbstractAppender.Builder.layout.
Would it be OK to say that an appender should provide a default layout?
Gary
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate,
21 matches
Mail list logo
