Re: @Required on layout on AbstractAppender

2016-09-15 Thread Mikael Ståldal 
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 have a default layout.

See https://issues.apache.org/jira/browse/LOG4J2-1465

On Sun, Sep 11, 2016 at 5:48 PM, Gary Gregory 
wrote:

> 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, 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
>



-- 
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com

Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.

Re: @Required on layout on AbstractAppender

2016-09-13 Thread Steffen Offermann 

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 from my iPhone


On 2016/09/13, at 18:24, Steffen Offermann  wrote:

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 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 to my work-mate who implemented that part.


On 09/13/2016 10:49 AM, Steffen Offermann wrote:
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" : "Console",
  "name" : "Console",
  "DetailsLayout" : {
 "extendedFormat" : true
  }
   },
   {
  "type" : "RandomAccessFile",
  "name" : "File",
  "fileName" : "logs/oid.log",
  "DetailsLayout" : {
 "extendedFormat" : true
  },
  "policies" : {
 "CronTriggeringPolicy" : {
"schedule" : "0 0 0 * * ?"
 },
 "SizeBasedTriggeringPolicy" : {
"size" : "1GB"
 },
 "ExternalTriggeringPolicy" : {
 }
  }
   },
   {
  "type" : "RandomAccessFile",
  "name" : "File/metrics",
  "fileName" : "logs/oid-metrics.log",
  "DetailsLayout" : {
 "extendedFormat" : true
  },
  "policies" : {
 "CronTriggeringPolicy" : {
"schedule" : "0 0 0 * * ?"
 },
 "SizeBasedTriggeringPolicy" : {
"size" : "1GB"
 },
 "ExternalTriggeringPolicy" : {
 }
  }
   }
]
 },
 "loggers" : {
"asyncRoot" : {
   "level" : "info",
   "includeLocation" : true,
   "AppenderRef" : [
  {
 "ref" : "File"
  }
   ]
},
"asyncLogger" : [
   {
  "name" : "com.aixigo.tec",
  "level" : "debug",
  "additivity" : "false",
  "includeLocation" : true,
  "AppenderRef" : [
 { "ref" : "File" }
  ]
   },
   {
  "name" : "oid-metrics",
  "level" : "stats",
  "additivity" : "false",
  "includeLocation" : true,
  "AppenderRef" : [
 { "ref" : "File/metrics" }
  ]
   }
]
 }
  }
}




On 09/13/2016 10:02 AM, Remko Popma wrote:
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 matches element policies
  2016-09-13 09:08:24,618 localhost-startStop-9 ERROR appender has no parameter 
that matches element policies

Regards,
Steffen



On 09/13/2016 08:47 AM, Steffen Offermann wrote:
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 test cases).

I have yet to test it in our other artefacts, where the actual logging takes 
place.

Regards,
Steffeh


On 09/12/2016 05:27 PM, Matt Sicker wrote:
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 mailto:steffen.offerm...@aixigo.de>> wrote:


  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 (as mentioned in 
the documentation) though?


  On 09/12/2016 09:16 AM, Steffen Offermann wr

Re: @Required on layout on AbstractAppender

2016-09-13 Thread Remko Popma 
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 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 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 to my work-mate who implemented that part.
>>> 
 On 09/13/2016 10:49 AM, Steffen Offermann wrote:
 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" : "Console",
   "name" : "Console",
   "DetailsLayout" : {
  "extendedFormat" : true
   }
},
{
   "type" : "RandomAccessFile",
   "name" : "File",
   "fileName" : "logs/oid.log",
   "DetailsLayout" : {
  "extendedFormat" : true
   },
   "policies" : {
  "CronTriggeringPolicy" : {
 "schedule" : "0 0 0 * * ?"
  },
  "SizeBasedTriggeringPolicy" : {
 "size" : "1GB"
  },
  "ExternalTriggeringPolicy" : {
  }
   }
},
{
   "type" : "RandomAccessFile",
   "name" : "File/metrics",
   "fileName" : "logs/oid-metrics.log",
   "DetailsLayout" : {
  "extendedFormat" : true
   },
   "policies" : {
  "CronTriggeringPolicy" : {
 "schedule" : "0 0 0 * * ?"
  },
  "SizeBasedTriggeringPolicy" : {
 "size" : "1GB"
  },
  "ExternalTriggeringPolicy" : {
  }
   }
}
 ]
  },
  "loggers" : {
 "asyncRoot" : {
"level" : "info",
"includeLocation" : true,
"AppenderRef" : [
   {
  "ref" : "File"
   }
]
 },
 "asyncLogger" : [
{
   "name" : "com.aixigo.tec",
   "level" : "debug",
   "additivity" : "false",
   "includeLocation" : true,
   "AppenderRef" : [
  { "ref" : "File" }
   ]
},
{
   "name" : "oid-metrics",
   "level" : "stats",
   "additivity" : "false",
   "includeLocation" : true,
   "AppenderRef" : [
  { "ref" : "File/metrics" }
   ]
}
 ]
  }
   }
 }
 
 
 
> On 09/13/2016 10:02 AM, Remko Popma wrote:
> 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 matches element policies
>>   2016-09-13 09:08:24,618 localhost-startStop-9 ERROR appender has no 
>> parameter that matches element policies
>> 
>> Regards,
>> Steffen
>> 
>> 
>>> On 09/13/2016 08:47 AM, Steffen Offermann wrote:
>>> 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 test cases).
>>> 
>>> I have yet to test it in our other artefacts, where the actual logging 
>>> takes place.
>>> 
>>> Regards,
>>> Steffeh

Re: @Required on layout on AbstractAppender

2016-09-13 Thread Steffen Offermann 

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 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 to my work-mate who implemented that part.

On 09/13/2016 10:49 AM, Steffen Offermann wrote:

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" : "Console",
   "name" : "Console",
   "DetailsLayout" : {
  "extendedFormat" : true
   }
},
{
   "type" : "RandomAccessFile",
   "name" : "File",
   "fileName" : "logs/oid.log",
   "DetailsLayout" : {
  "extendedFormat" : true
   },
   "policies" : {
  "CronTriggeringPolicy" : {
 "schedule" : "0 0 0 * * ?"
  },
  "SizeBasedTriggeringPolicy" : {
 "size" : "1GB"
  },
  "ExternalTriggeringPolicy" : {
  }
   }
},
{
   "type" : "RandomAccessFile",
   "name" : "File/metrics",
   "fileName" : "logs/oid-metrics.log",
   "DetailsLayout" : {
  "extendedFormat" : true
   },
   "policies" : {
  "CronTriggeringPolicy" : {
 "schedule" : "0 0 0 * * ?"
  },
  "SizeBasedTriggeringPolicy" : {
 "size" : "1GB"
  },
  "ExternalTriggeringPolicy" : {
  }
   }
}
 ]
  },
  "loggers" : {
 "asyncRoot" : {
"level" : "info",
"includeLocation" : true,
"AppenderRef" : [
   {
  "ref" : "File"
   }
]
 },
 "asyncLogger" : [
{
   "name" : "com.aixigo.tec",
   "level" : "debug",
   "additivity" : "false",
   "includeLocation" : true,
   "AppenderRef" : [
  { "ref" : "File" }
   ]
},
{
   "name" : "oid-metrics",
   "level" : "stats",
   "additivity" : "false",
   "includeLocation" : true,
   "AppenderRef" : [
  { "ref" : "File/metrics" }
   ]
}
 ]
  }
   }
}



On 09/13/2016 10:02 AM, Remko Popma wrote:

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 matches element policies
   2016-09-13 09:08:24,618 localhost-startStop-9 ERROR appender has no 
parameter that matches element policies

Regards,
 Steffen



On 09/13/2016 08:47 AM, Steffen Offermann wrote:
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 test cases).

I have yet to test it in our other artefacts, where the actual logging takes 
place.

Regards,
 Steffeh


On 09/12/2016 05:27 PM, Matt Sicker wrote:
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 mailto:steffen.offerm...@aixigo.de>> wrote:


   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 (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 wrote:

   I understand now, thank y

Re: @Required on layout on AbstractAppender

2016-09-13 Thread Steffen Offermann 

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 of Log4j2 may not
be compatible with the generated Logger any more, so it has to be regenerated.

I'll have to talk to my work-mate who implemented that part.

On 09/13/2016 10:49 AM, Steffen Offermann wrote:

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" : "Console",
   "name" : "Console",
   "DetailsLayout" : {
  "extendedFormat" : true
   }
},
{
   "type" : "RandomAccessFile",
   "name" : "File",
   "fileName" : "logs/oid.log",
   "DetailsLayout" : {
  "extendedFormat" : true
   },
   "policies" : {
  "CronTriggeringPolicy" : {
 "schedule" : "0 0 0 * * ?"
  },
  "SizeBasedTriggeringPolicy" : {
 "size" : "1GB"
  },
  "ExternalTriggeringPolicy" : {
  }
   }
},
{
   "type" : "RandomAccessFile",
   "name" : "File/metrics",
   "fileName" : "logs/oid-metrics.log",
   "DetailsLayout" : {
  "extendedFormat" : true
   },
   "policies" : {
  "CronTriggeringPolicy" : {
 "schedule" : "0 0 0 * * ?"
  },
  "SizeBasedTriggeringPolicy" : {
 "size" : "1GB"
  },
  "ExternalTriggeringPolicy" : {
  }
   }
}
 ]
  },
  "loggers" : {
 "asyncRoot" : {
"level" : "info",
"includeLocation" : true,
"AppenderRef" : [
   {
  "ref" : "File"
   }
]
 },
 "asyncLogger" : [
{
   "name" : "com.aixigo.tec",
   "level" : "debug",
   "additivity" : "false",
   "includeLocation" : true,
   "AppenderRef" : [
  { "ref" : "File" }
   ]
},
{
   "name" : "oid-metrics",
   "level" : "stats",
   "additivity" : "false",
   "includeLocation" : true,
   "AppenderRef" : [
  { "ref" : "File/metrics" }
   ]
}
 ]
  }
   }
}



On 09/13/2016 10:02 AM, Remko Popma wrote:

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 matches element policies
   2016-09-13 09:08:24,618 localhost-startStop-9 ERROR appender has no 
parameter that matches element policies

Regards,
 Steffen



On 09/13/2016 08:47 AM, Steffen Offermann wrote:
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 test cases).

I have yet to test it in our other artefacts, where the actual logging takes 
place.

Regards,
 Steffeh


On 09/12/2016 05:27 PM, Matt Sicker wrote:
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 mailto:steffen.offerm...@aixigo.de>> wrote:


   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 (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 wrote:

   I understand now, thank you. All build methods do not use the 
same default. I'll remove the @Required tomorrow.

   Gary

Re: @Required on layout on AbstractAppender

2016-09-13 Thread Steffen Offermann 
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 to my work-mate who implemented that part.

On 09/13/2016 10:49 AM, Steffen Offermann wrote:

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" : "Console",
   "name" : "Console",
   "DetailsLayout" : {
  "extendedFormat" : true
   }
},
{
   "type" : "RandomAccessFile",
   "name" : "File",
   "fileName" : "logs/oid.log",
   "DetailsLayout" : {
  "extendedFormat" : true
   },
   "policies" : {
  "CronTriggeringPolicy" : {
 "schedule" : "0 0 0 * * ?"
  },
  "SizeBasedTriggeringPolicy" : {
 "size" : "1GB"
  },
  "ExternalTriggeringPolicy" : {
  }
   }
},
{
   "type" : "RandomAccessFile",
   "name" : "File/metrics",
   "fileName" : "logs/oid-metrics.log",
   "DetailsLayout" : {
  "extendedFormat" : true
   },
   "policies" : {
  "CronTriggeringPolicy" : {
 "schedule" : "0 0 0 * * ?"
  },
  "SizeBasedTriggeringPolicy" : {
 "size" : "1GB"
  },
  "ExternalTriggeringPolicy" : {
  }
   }
}
 ]
  },
  "loggers" : {
 "asyncRoot" : {
"level" : "info",
"includeLocation" : true,
"AppenderRef" : [
   {
  "ref" : "File"
   }
]
 },
 "asyncLogger" : [
{
   "name" : "com.aixigo.tec",
   "level" : "debug",
   "additivity" : "false",
   "includeLocation" : true,
   "AppenderRef" : [
  { "ref" : "File" }
   ]
},
{
   "name" : "oid-metrics",
   "level" : "stats",
   "additivity" : "false",
   "includeLocation" : true,
   "AppenderRef" : [
  { "ref" : "File/metrics" }
   ]
}
 ]
  }
   }
}



On 09/13/2016 10:02 AM, Remko Popma wrote:

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 matches element policies
   2016-09-13 09:08:24,618 localhost-startStop-9 ERROR appender has no 
parameter that matches element policies

Regards,
 Steffen



On 09/13/2016 08:47 AM, Steffen Offermann wrote:
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 test cases).

I have yet to test it in our other artefacts, where the actual logging takes 
place.

Regards,
 Steffeh


On 09/12/2016 05:27 PM, Matt Sicker wrote:
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 mailto:steffen.offerm...@aixigo.de>> wrote:


   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 (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 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, "Matt Sicker" mailto:boa...@gmail.com>

Re: @Required on layout on AbstractAppender

2016-09-13 Thread Steffen Offermann 

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" : "Console",
   "name" : "Console",
   "DetailsLayout" : {
  "extendedFormat" : true
   }
},
{
   "type" : "RandomAccessFile",
   "name" : "File",
   "fileName" : "logs/oid.log",
   "DetailsLayout" : {
  "extendedFormat" : true
   },
   "policies" : {
  "CronTriggeringPolicy" : {
 "schedule" : "0 0 0 * * ?"
  },
  "SizeBasedTriggeringPolicy" : {
 "size" : "1GB"
  },
  "ExternalTriggeringPolicy" : {
  }
   }
},
{
   "type" : "RandomAccessFile",
   "name" : "File/metrics",
   "fileName" : "logs/oid-metrics.log",
   "DetailsLayout" : {
  "extendedFormat" : true
   },
   "policies" : {
  "CronTriggeringPolicy" : {
 "schedule" : "0 0 0 * * ?"
  },
  "SizeBasedTriggeringPolicy" : {
 "size" : "1GB"
  },
  "ExternalTriggeringPolicy" : {
  }
   }
}
 ]
  },
  "loggers" : {
 "asyncRoot" : {
"level" : "info",
"includeLocation" : true,
"AppenderRef" : [
   {
  "ref" : "File"
   }
]
 },
 "asyncLogger" : [
{
   "name" : "com.aixigo.tec",
   "level" : "debug",
   "additivity" : "false",
   "includeLocation" : true,
   "AppenderRef" : [
  { "ref" : "File" }
   ]
},
{
   "name" : "oid-metrics",
   "level" : "stats",
   "additivity" : "false",
   "includeLocation" : true,
   "AppenderRef" : [
  { "ref" : "File/metrics" }
   ]
}
 ]
  }
   }
}



On 09/13/2016 10:02 AM, Remko Popma wrote:

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 matches element policies
   2016-09-13 09:08:24,618 localhost-startStop-9 ERROR appender has no 
parameter that matches element policies

Regards,
 Steffen



On 09/13/2016 08:47 AM, Steffen Offermann wrote:
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 test cases).

I have yet to test it in our other artefacts, where the actual logging takes 
place.

Regards,
 Steffeh


On 09/12/2016 05:27 PM, Matt Sicker wrote:
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 mailto:steffen.offerm...@aixigo.de>> wrote:


   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 (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 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, "Matt Sicker" mailto:boa...@gmail.com> >> wrote:

   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

Re: @Required on layout on AbstractAppender

2016-09-13 Thread Remko Popma 
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 matches element policies
>2016-09-13 09:08:24,618 localhost-startStop-9 ERROR appender has no 
> parameter that matches element policies
> 
> Regards,
>  Steffen
> 
> 
>> On 09/13/2016 08:47 AM, Steffen Offermann wrote:
>> 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 test cases).
>> 
>> I have yet to test it in our other artefacts, where the actual logging takes 
>> place.
>> 
>> Regards,
>>  Steffeh
>> 
>>> On 09/12/2016 05:27 PM, Matt Sicker wrote:
>>> 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 
>>> mailto:steffen.offerm...@aixigo.de>> wrote:
>>> 
>>> 
>>>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 (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 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, "Matt Sicker" >>  >> >> wrote:
>>> 
>>>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.
>>> 
>>>On 11 September 2016 at 21:20, Gary Gregory 
>>> mailto:garydgreg...@gmail.com> 
>>> >> wrote:
>>> 
>>>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, Sep 11, 2016 at 11:43 AM, Matt Sicker 
>>> mailto:boa...@gmail.com> >> >> wrote:
>>> 
>>>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 
>>> mailto:garydgreg...@gmail.com> 
>>> >> wrote:
>>> 
>>>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.build()
>>> 
>>>All provide default layouts.
>>> 
>>>Gary
>>> 
>>> 
>>>On Sun, Sep 11, 2016 at 8:48 AM, Gary 
>>> Gregory mailto:garydgreg...@gmail.com> 
>>> >>
>>>wrote:
>>> 
>>>I'm pretty sure we no longer need 
>>> @Required on layout on 
>>> org.apache.logging.log4j.core.appender.AbstractAppender.Builder.layout

Re: @Required on layout on AbstractAppender

2016-09-13 Thread Steffen Offermann 

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

Regards,
  Steffen


On 09/13/2016 08:47 AM, Steffen Offermann wrote:

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 test cases).

I have yet to test it in our other artefacts, where the actual logging takes 
place.

Regards,
  Steffeh

On 09/12/2016 05:27 PM, Matt Sicker wrote:

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 mailto:steffen.offerm...@aixigo.de>> wrote:


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 (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 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, "Matt Sicker" mailto:boa...@gmail.com> >> wrote:

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.

On 11 September 2016 at 21:20, Gary Gregory mailto:garydgreg...@gmail.com> >> wrote:

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, Sep 11, 2016 at 11:43 AM, Matt Sicker mailto:boa...@gmail.com> >> 
wrote:

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 mailto:garydgreg...@gmail.com> >> wrote:

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.build()

All provide default layouts.

Gary


On Sun, Sep 11, 2016 at 8:48 AM, Gary Gregory 
mailto:garydgreg...@gmail.com> >>
wrote:

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, Second Edition

Re: @Required on layout on AbstractAppender

2016-09-12 Thread Steffen Offermann 
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 test cases).


I have yet to test it in our other artefacts, where the actual logging takes 
place.

Regards,
  Steffeh

On 09/12/2016 05:27 PM, Matt Sicker wrote:

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 mailto:steffen.offerm...@aixigo.de>> wrote:


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 (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 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, "Matt Sicker" mailto:boa...@gmail.com> >> wrote:

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.

On 11 September 2016 at 21:20, Gary Gregory mailto:garydgreg...@gmail.com> >> wrote:

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, Sep 11, 2016 at 11:43 AM, Matt Sicker mailto:boa...@gmail.com> >> 
wrote:

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 mailto:garydgreg...@gmail.com> >> wrote:

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.build()

All provide default layouts.

Gary


On Sun, Sep 11, 2016 at 8:48 AM, Gary Gregory 
mailto:garydgreg...@gmail.com> >>
wrote:

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, Second Edition 
>
JUnit in Action, Second Edition 
>
Spring Batch in Action 
>

Re: @Required on layout on AbstractAppender

2016-09-12 Thread Gary Gregory 
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:
>>
>> @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.
>>
>> On 11 September 2016 at 21:20, Gary Gregory 
>> wrote:
>>
>>> 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, Sep 11, 2016 at 11:43 AM, Matt Sicker  wrote:
>>>
 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.build()
> org.apache.logging.log4j.core.appender.FileAppender.Builder.build()
> org.apache.logging.log4j.core.appender.RollingFileAppender.B
> uilder.build()
> org.apache.logging.log4j.core.appender.SocketAppender.Builder.build()
>
> All provide default layouts.
>
> Gary
>
>
> On Sun, Sep 11, 2016 at 8:48 AM, Gary Gregory 
> wrote:
>
>> I'm pretty sure we no longer need @Required on layout on
>> org.apache.logging.log4j.core.appender.AbstractAppender.Buil
>> der.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, 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
>>
>
>
>
> --
> 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 

>>>
>>>
>>>
>>> --
>>> 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 
>>
>


-- 
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: @Required on layout on AbstractAppender

2016-09-12 Thread Matt Sicker 
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 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 (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 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, "Matt Sicker" >>> boa...@gmail.com>> wrote:

 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.

 On 11 September 2016 at 21:20, Gary Gregory >>> > wrote:

 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, Sep 11, 2016 at 11:43 AM, Matt Sicker >>> > wrote:

 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 <
 garydgreg...@gmail.com > wrote:

 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.build()

 All provide default layouts.

 Gary


 On Sun, Sep 11, 2016 at 8:48 AM, Gary Gregory <
 garydgreg...@gmail.com > wrote:

 I'm pretty sure we no longer need @Required on
 layout on org.apache.logging.log4j.core.appender.AbstractAppender.Buil
 der.layout.

 Would it be OK to say that an appender should
 provide a default layout?

 Gary

 --
 E-Mail: garydgreg...@gmail.com >>> garydgreg...@gmail.com> | ggreg...@apache.org >>> ggreg...@apache.org>
 Java Persistence with Hibernate, Second Edition <
 http://www.manning.com/bauer3/>
 JUnit in Action, Second Edition <
 http://www.manning.com/tahchiev/>
 Spring Batch in Action <
 http://www.manning.com/templier/>
 Blog: http://garygregory.wordpress.com <
 http://garygregory.wordpress.com/>
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory




 --
 E-Mail: garydgreg...@gmail.com >>> garydgreg...@gmail.com> | ggreg...@apache.org >>> ggreg...@apache.org>
 Java Persistence with Hibernate, Second Edition <
 http://www.manning.com/bauer3/>
 JUnit in Action, Second Edition <
 http://www.manning.com/tahchiev/>
 Spring Batch in Action 
 Blog: http://garygregory.wordpress.com <
 http://garygregory.wordpress.com/>
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory




 --
 Matt Sicker mailto:boa...@gmail.com>>




 --
 E-Mail: garydgreg...@gmail.com 
 | ggreg...@apache.org 
 Java Persistence with Hibernate, Second Edition <
 http://www.manning.com/bauer3/>
 J

Re: @Required on layout on AbstractAppender

2016-09-12 Thread Steffen Offermann 


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 (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 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, "Matt Sicker" mailto:boa...@gmail.com>> wrote:

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.

On 11 September 2016 at 21:20, Gary Gregory mailto:garydgreg...@gmail.com>> wrote:

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, Sep 11, 2016 at 11:43 AM, Matt Sicker mailto:boa...@gmail.com>> wrote:

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 mailto:garydgreg...@gmail.com>> wrote:

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.build()

All provide default layouts.

Gary


On Sun, Sep 11, 2016 at 8:48 AM, Gary Gregory mailto:garydgreg...@gmail.com>> wrote:

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, 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




--
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 mailto:boa...@gmail.com>>




--
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 mailto:boa...@gmail.com>>










--
aixigo AG - financial solutions & technology
Karl-Friedrich-Straße 68, 52072 Aachen, Germany
fon: +49 (0)241 559709-65, fax: +49 (0)241 559709-99
eMail: steffen.offerm...@aixigo.de, web: http://www.aixigo.de

Amtsgericht Aachen - HRB 8057
Vorstand: Erich Borsch, Christian Friedrich, Tobias Haustein
Vors. des Aufsichtsrates: Prof. Dr. Rüdiger von Nitzsch

-
To

Re: @Required on layout on AbstractAppender

2016-09-12 Thread Steffen Offermann 

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 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, "Matt Sicker" mailto:boa...@gmail.com>> wrote:

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.

On 11 September 2016 at 21:20, Gary Gregory mailto:garydgreg...@gmail.com>> wrote:

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, Sep 11, 2016 at 11:43 AM, Matt Sicker mailto:boa...@gmail.com>> wrote:

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 mailto:garydgreg...@gmail.com>> wrote:

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.build()

All provide default layouts.

Gary


On Sun, Sep 11, 2016 at 8:48 AM, Gary Gregory mailto:garydgreg...@gmail.com>> wrote:

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, 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




--
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 mailto:boa...@gmail.com>>




--
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 mailto:boa...@gmail.com>>







--
aixigo AG - financial solutions & technology
Karl-Friedrich-Straße 68, 52072 Aachen, Germany
fon: +49 (0)241 559709-65, fax: +49 (0)241 559709-99
eMail: steffen.offerm...@aixigo.de, web: http://www.aixigo.de

Amtsgericht Aachen - HRB 8057
Vorstand: Erich Borsch, Christian Friedrich, Tobias Haustein
Vors. des Aufsichtsrates: Prof. Dr. Rüdiger von Nitzsch

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

Re: @Required on layout on AbstractAppender

2016-09-12 Thread Steffen Offermann 

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, "Matt Sicker" mailto:boa...@gmail.com>> wrote:

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.

On 11 September 2016 at 21:20, Gary Gregory mailto:garydgreg...@gmail.com>> wrote:

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, Sep 11, 2016 at 11:43 AM, Matt Sicker mailto:boa...@gmail.com>> wrote:

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 mailto:garydgreg...@gmail.com>> wrote:

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.build()

All provide default layouts.

Gary


On Sun, Sep 11, 2016 at 8:48 AM, Gary Gregory mailto:garydgreg...@gmail.com>> wrote:

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, 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




--
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 mailto:boa...@gmail.com>>




--
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 mailto:boa...@gmail.com>>




--
aixigo AG - financial solutions & technology
Karl-Friedrich-Straße 68, 52072 Aachen, Germany
fon: +49 (0)241 559709-65, fax: +49 (0)241 559709-99
eMail: steffen.offerm...@aixigo.de, web: http://www.aixigo.de

Amtsgericht Aachen - HRB 8057
Vorstand: Erich Borsch, Christian Friedrich, Tobias Haustein
Vors. des Aufsichtsrates: Prof. Dr. Rüdiger von Nitzsch

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

Re: @Required on layout on AbstractAppender

2016-09-11 Thread Gary Gregory 
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.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.
>
> On 11 September 2016 at 21:20, Gary Gregory 
> wrote:
>
>> 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, Sep 11, 2016 at 11:43 AM, Matt Sicker  wrote:
>>
>>> 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.build()
 org.apache.logging.log4j.core.appender.FileAppender.Builder.build()
 org.apache.logging.log4j.core.appender.RollingFileAppender.B
 uilder.build()
 org.apache.logging.log4j.core.appender.SocketAppender.Builder.build()

 All provide default layouts.

 Gary


 On Sun, Sep 11, 2016 at 8:48 AM, Gary Gregory 
 wrote:

> I'm pretty sure we no longer need @Required on layout on
> org.apache.logging.log4j.core.appender.AbstractAppender.Buil
> der.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, 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
>



 --
 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 
>>>
>>
>>
>>
>> --
>> 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: @Required on layout on AbstractAppender

2016-09-11 Thread Matt Sicker 
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.

On 11 September 2016 at 21:20, Gary Gregory  wrote:

> 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, Sep 11, 2016 at 11:43 AM, Matt Sicker  wrote:
>
>> 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.build()
>>> org.apache.logging.log4j.core.appender.FileAppender.Builder.build()
>>> org.apache.logging.log4j.core.appender.RollingFileAppender.B
>>> uilder.build()
>>> org.apache.logging.log4j.core.appender.SocketAppender.Builder.build()
>>>
>>> All provide default layouts.
>>>
>>> Gary
>>>
>>>
>>> On Sun, Sep 11, 2016 at 8:48 AM, Gary Gregory 
>>> wrote:
>>>
 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, 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

>>>
>>>
>>>
>>> --
>>> 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 
>>
>
>
>
> --
> 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: @Required on layout on AbstractAppender

2016-09-11 Thread Gary Gregory 
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, Sep 11, 2016 at 11:43 AM, Matt Sicker  wrote:

> 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.build()
>> org.apache.logging.log4j.core.appender.FileAppender.Builder.build()
>> org.apache.logging.log4j.core.appender.RollingFileAppender.B
>> uilder.build()
>> org.apache.logging.log4j.core.appender.SocketAppender.Builder.build()
>>
>> All provide default layouts.
>>
>> Gary
>>
>>
>> On Sun, Sep 11, 2016 at 8:48 AM, Gary Gregory 
>> wrote:
>>
>>> 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, 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
>>>
>>
>>
>>
>> --
>> 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 
>



-- 
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: @Required on layout on AbstractAppender

2016-09-11 Thread Matt Sicker 
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.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.build()
>
> All provide default layouts.
>
> Gary
>
>
> On Sun, Sep 11, 2016 at 8:48 AM, Gary Gregory 
> wrote:
>
>> 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, 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
>>
>
>
>
> --
> 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: @Required on layout on AbstractAppender

2016-09-11 Thread Gary Gregory 
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.build()

All provide default layouts.

Gary


On Sun, Sep 11, 2016 at 8:48 AM, Gary Gregory 
wrote:

> 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, 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
>



-- 
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