Bug report for Log4j [2014/06/15]

+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned

Why are two logger contexts started?

After improving the status logging, it is now clear that there are two LoggerContexts started: one with name=sun.misc.Launcher$AppClassLoader@1f3e8d89, and one with name=Default Is this expected? To reproduce this, change

LoggerContext config location

I would like the ability to get the ConfigurationSource from the LoggerContext in order to fix LOG4J2-539 . Currently LoggerContext has a field configLocation:URI, but this field may (or may not) be initialized when the LoggerContext is constructe

RE: LoggerContext config location

It sounds like you have a good user story.  Thoughts from Ralph?  Gary Original message From: Remko Popma Date:06/15/2014 08:33 (GMT-05:00) To: Log4J Developers List Subject: LoggerContext config location I would like the ability to get the ConfigurationSource from the L

Re: LoggerContext config location

I have no objections. Ralph On Jun 15, 2014, at 6:46 AM, Gary Gregory wrote: > It sounds like you have a good user story. Thoughts from Ralph? > > Gary > > > Original message > From: Remko Popma > Date:06/15/2014 08:33 (GMT-05:00) > To: Log4J Developers List > Subject: Lo

Re: Why are two logger contexts started?

That happens because line 51 is ((LifeCycle) LogManager.getContext()).stop(); // stop async thread and should be ((LifeCycle) LogManager.getContext(false)).stop(); // stop async thread Ralph On Jun 15, 2014, at 12:16 AM, Remko Popma wrote: > After improving the status logging, it is now cle

Re: debug output

While you improved some of the existing messages, you really didm’t address what I wanted fixed. The previous debug logs would have had messages similar to: Calling createLayout on class org.apache.logging.log4j.core.layout.PatternLayout for element PatternLayout with params(pattern="%d{HH:mm:s

Logo Files committed

Hi, I just committed the logo files to: http://svn.apache.org/repos/asf/logging/graphics/log4j/ I was thinking the working files should not necessary become part of the build, only the reduced versions we need. However if we want to offer a "powered by" it might make sense to move them around.

Re: Why are two logger contexts started?

Aha! Thank you! Sent from my iPhone > On 2014/06/16, at 1:12, Ralph Goers wrote: > > That happens because line 51 is > > ((LifeCycle) LogManager.getContext()).stop(); // stop async thread > > and should be > > ((LifeCycle) LogManager.getContext(false)).stop(); // stop async thread > > Ralp

Re: debug output

I see. I agree that the original format is much nicer. Matt, do you think you can achieve this with the builders? Sent from my iPhone > On 2014/06/16, at 1:29, Ralph Goers wrote: > > While you improved some of the existing messages, you really didm’t address > what I wanted fixed. The previo

[jira] [Updated] (LOG4J2-619) Unable to recover after loading corrupted XML

[ https://issues.apache.org/jira/browse/LOG4J2-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Harrington updated LOG4J2-619: Attachment: log4j-r1602630-reconfigure.patch > Unable to recover after loading corrupted XM

[jira] [Commented] (LOG4J2-619) Unable to recover after loading corrupted XML

[ https://issues.apache.org/jira/browse/LOG4J2-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032038#comment-14032038 ] Scott Harrington commented on LOG4J2-619: - Hi, I am not the original submitter but

Re: debug output

Do we need the builders? As I said, I prefer only one way for creating plugins. Ralph On Jun 15, 2014, at 2:49 PM, Remko Popma wrote: > I see. I agree that the original format is much nicer. > > Matt, do you think you can achieve this with the builders? > > Sent from my iPhone > > On 2014/

Re: debug output

Well, it could be done via the builders. The visit method just needs to accept a StringBuilder to continue building the log message. I'll take a look at this shortly. And in regards to builders versus factories, I actually have a third option that could reduce everything: prototypes. Instead of al

Re: LoggerContext config location

Sounds like a good idea! On 15 June 2014 10:50, Ralph Goers wrote: > I have no objections. > > Ralph > > On Jun 15, 2014, at 6:46 AM, Gary Gregory wrote: > > It sounds like you have a good user story. Thoughts from Ralph? > > Gary > > > Original message > From: Remko Popma >

Re: debug output

Yes, let's pick one way to do this. Unless there is a clear advantage to do it more than one way... Gary Original message From: Ralph Goers Date:06/15/2014 19:04 (GMT-05:00) To: Log4J Developers List Subject: Re: debug output Do we need the builders? As I said, I prefer

Re: debug output

I just committed the log messages improvement using the visitors and such. It was way simpler than I expected! On 15 June 2014 19:04, Gary Gregory wrote: > Yes, let's pick one way to do this. Unless there is a clear advantage to > do it more than one way... > > Gary > > > Original mess

[jira] [Commented] (LOG4J2-619) Unable to recover after loading corrupted XML

[ https://issues.apache.org/jira/browse/LOG4J2-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032058#comment-14032058 ] Matt Sicker commented on LOG4J2-619: I've applied the patch in r1602778. Could you ver

Re: debug output

+1 On Jun 15, 2014 4:05 PM, "Ralph Goers" wrote: > Do we need the builders? As I said, I prefer only one way for creating > plugins. > > Ralph > > On Jun 15, 2014, at 2:49 PM, Remko Popma wrote: > > I see. I agree that the original format is much nicer. > > Matt, do you think you can achieve th

[jira] [Commented] (LOG4J2-619) Unable to recover after loading corrupted XML

[ https://issues.apache.org/jira/browse/LOG4J2-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032069#comment-14032069 ] Scott Harrington commented on LOG4J2-619: - Hi Matt, I've updated to 1602778 and th

[jira] [Closed] (LOG4J2-619) Unable to recover after loading corrupted XML

[ https://issues.apache.org/jira/browse/LOG4J2-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Sicker closed LOG4J2-619. -- Resolution: Fixed Fix Version/s: 2.0-rc2 Fixed in r1602778 and verified by user. > Unable to re

Re: debug output

I'm fine with just the factory methods too. Sent from my iPhone > On 2014/06/16, at 9:44, Scott Deboy wrote: > > +1 > >> On Jun 15, 2014 4:05 PM, "Ralph Goers" wrote: >> Do we need the builders? As I said, I prefer only one way for creating >> plugins. >> >> Ralph >> >>> On Jun 15, 2014,

Re: debug output

I'm really against using factory methods due to language limitations in Java. You can't specify default values, for one. Two, the more parameters a factory takes, the crazier the method is. Seriously, tell me what this method is specifying: FileAppender.createAppender("true", "true", "true", "true

Re: debug output

Matt, The only objection I have to builders is that there should only be one way to configure plugins and I have neither the time or energy to convert all plugins from factories to builders. With 130+ open issues I think our time is better focused there instead of fixing something that already

[jira] [Created] (LOG4J2-670) DatePatternConverter ISO8601_PATTERN does not conform to ISO8601

Ralph Goers created LOG4J2-670: -- Summary: DatePatternConverter ISO8601_PATTERN does not conform to ISO8601 Key: LOG4J2-670 URL: https://issues.apache.org/jira/browse/LOG4J2-670 Project: Log4j 2

Re: debug output

Final fields may be quite important depending on the class. We should really consider a change like making a field mutable carefully. Not that I am advocating for builders in the first place,  I am not.  Gary Original message From: Matt Sicker Date:06/15/2014 19:31 (GMT-05:

Re: debug output

Well, I can live with factory methods if we have a better method for doing unit tests. Not all unit tests need an XML configuration file. On 15 June 2014 22:04, Ralph Goers wrote: > Matt, > > The only objection I have to builders is that there should only be one way > to configure plugins and I

Re: debug output

You don't want factory methods that take umpteen arguments. That's no way to make your builder extensible for future enhancements. Instead, you want a builder object that has a fluent API. http://docs.spring.io/spring/docs/3.2.8.RELEASE/javadoc-api/org/springframework/beans/factory/support/BeanDef

Build failures again

Failed tests: TestConfigurator.testReconfiguration:236 Configuration not reset FileConfigTest.testReconfiguration:62 Reconfiguration failed expected not same LoggerTest.testReconfiguration:210 Reconfiguration failed expected not same

Re: Build failures again

I'm fairly sure I ran the build and it worked after my last commit. Sent from my iPhone > On 2014/06/16, at 14:26, Ralph Goers wrote: > > > Failed tests: > TestConfigurator.testReconfiguration:236 Configuration not reset > FileConfigTest.testReconfiguration:62 Reconfiguration failed expe