org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

Gary Gregory-4
Hi All:

Using 2.8.2, I call org.apache.logging.log4j.core.config.Configurator.initialize(String, String) with a non-exiting file location.

The method does not return null because it found another log4j2.xml file on my classpath. So I get a LoggerContext but not what I expect...

That does not sound right to me, it should return null, and then I can look in the status logger to see what went wrong (if I happen to have it set to DEBUG in the log4j2.xml file it did find.)

Thoughts?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

Remko Popma-2
I can see both sides of the argument. 

Rather than changing the semantics of the existing method, what about adding a method `Configurator.initializeStrict(String, String)` which fails if the specified file doesn't exist? Not sure what the best way to fail is: return null or throw exception...

Sent from my iPhone

On Apr 12, 2017, at 9:13, Gary Gregory <[hidden email]> wrote:

Hi All:

Using 2.8.2, I call org.apache.logging.log4j.core.config.Configurator.initialize(String, String) with a non-exiting file location.

The method does not return null because it found another log4j2.xml file on my classpath. So I get a LoggerContext but not what I expect...

That does not sound right to me, it should return null, and then I can look in the status logger to see what went wrong (if I happen to have it set to DEBUG in the log4j2.xml file it did find.)

Thoughts?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

Ralph Goers
I'd prefer an error message but then have it continue with the current behavior.

Sent from my iPhone

On Apr 11, 2017, at 5:47 PM, Remko Popma <[hidden email]> wrote:

I can see both sides of the argument. 

Rather than changing the semantics of the existing method, what about adding a method `Configurator.initializeStrict(String, String)` which fails if the specified file doesn't exist? Not sure what the best way to fail is: return null or throw exception...

Sent from my iPhone

On Apr 12, 2017, at 9:13, Gary Gregory <[hidden email]> wrote:

Hi All:

Using 2.8.2, I call org.apache.logging.log4j.core.config.Configurator.initialize(String, String) with a non-exiting file location.

The method does not return null because it found another log4j2.xml file on my classpath. So I get a LoggerContext but not what I expect...

That does not sound right to me, it should return null, and then I can look in the status logger to see what went wrong (if I happen to have it set to DEBUG in the log4j2.xml file it did find.)

Thoughts?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

Remko Popma-2
I thought Gary needed a way to detect that the specified location didn't work. But perhaps a warning message is sufficient. 

Sent from my iPhone

On Apr 12, 2017, at 10:05, Ralph Goers <[hidden email]> wrote:

I'd prefer an error message but then have it continue with the current behavior.

Sent from my iPhone

On Apr 11, 2017, at 5:47 PM, Remko Popma <[hidden email]> wrote:

I can see both sides of the argument. 

Rather than changing the semantics of the existing method, what about adding a method `Configurator.initializeStrict(String, String)` which fails if the specified file doesn't exist? Not sure what the best way to fail is: return null or throw exception...

Sent from my iPhone

On Apr 12, 2017, at 9:13, Gary Gregory <[hidden email]> wrote:

Hi All:

Using 2.8.2, I call org.apache.logging.log4j.core.config.Configurator.initialize(String, String) with a non-exiting file location.

The method does not return null because it found another log4j2.xml file on my classpath. So I get a LoggerContext but not what I expect...

That does not sound right to me, it should return null, and then I can look in the status logger to see what went wrong (if I happen to have it set to DEBUG in the log4j2.xml file it did find.)

Thoughts?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

Ralph Goers
That’s a good point. It is a programmatic interface so it should return an error. But generally we want logging to do something reasonable other than fail, so it should either use whatever configuration it finds or use the default.

Ralph

On Apr 11, 2017, at 8:42 PM, Remko Popma <[hidden email]> wrote:

I thought Gary needed a way to detect that the specified location didn't work. But perhaps a warning message is sufficient. 

Sent from my iPhone

On Apr 12, 2017, at 10:05, Ralph Goers <[hidden email]> wrote:

I'd prefer an error message but then have it continue with the current behavior.

Sent from my iPhone

On Apr 11, 2017, at 5:47 PM, Remko Popma <[hidden email]> wrote:

I can see both sides of the argument. 

Rather than changing the semantics of the existing method, what about adding a method `Configurator.initializeStrict(String, String)` which fails if the specified file doesn't exist? Not sure what the best way to fail is: return null or throw exception...

Sent from my iPhone

On Apr 12, 2017, at 9:13, Gary Gregory <[hidden email]> wrote:

Hi All:

Using 2.8.2, I call org.apache.logging.log4j.core.config.Configurator.initialize(String, String) with a non-exiting file location.

The method does not return null because it found another log4j2.xml file on my classpath. So I get a LoggerContext but not what I expect...

That does not sound right to me, it should return null, and then I can look in the status logger to see what went wrong (if I happen to have it set to DEBUG in the log4j2.xml file it did find.)

Thoughts?


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: org.apache.logging.log4j.core.config.Configurator.initialize(String, String)

Gary Gregory-4
The problem with the API as it is now is that I have no idea if the API did what I asked it to do. It does initialize log4j all right but not in a way I expect. 

I see that we could:

1) make the current API throw an IllegalArgumentException that means "file not found", this keeps the API signature the same.
2) make the current API return null (but should it still initialize log4j with the 'next' config file it finds?). Not great as this would likely break some apps.
3) add a new API that throws an exception that means 'config file not found'
4) add a new API that returns null

The nice thing about throwing an exception is that you can give a detailed error message. Returning null tells you something is wrong, not what, still a mystery.

So I prefer 3).

Regardless, we need some better Javadocs on the existing APIs... the behavior is just too surprising IMO.

Thoughts?

Gary



On Tue, Apr 11, 2017 at 10:01 PM, Ralph Goers <[hidden email]> wrote:
That’s a good point. It is a programmatic interface so it should return an error. But generally we want logging to do something reasonable other than fail, so it should either use whatever configuration it finds or use the default.

Ralph

On Apr 11, 2017, at 8:42 PM, Remko Popma <[hidden email]> wrote:

I thought Gary needed a way to detect that the specified location didn't work. But perhaps a warning message is sufficient. 

Sent from my iPhone

On Apr 12, 2017, at 10:05, Ralph Goers <[hidden email]> wrote:

I'd prefer an error message but then have it continue with the current behavior.

Sent from my iPhone

On Apr 11, 2017, at 5:47 PM, Remko Popma <[hidden email]> wrote:

I can see both sides of the argument. 

Rather than changing the semantics of the existing method, what about adding a method `Configurator.initializeStrict(String, String)` which fails if the specified file doesn't exist? Not sure what the best way to fail is: return null or throw exception...

Sent from my iPhone

On Apr 12, 2017, at 9:13, Gary Gregory <[hidden email]> wrote:

Hi All:

Using 2.8.2, I call org.apache.logging.log4j.core.config.Configurator.initialize(String, String) with a non-exiting file location.

The method does not return null because it found another log4j2.xml file on my classpath. So I get a LoggerContext but not what I expect...

That does not sound right to me, it should return null, and then I can look in the status logger to see what went wrong (if I happen to have it set to DEBUG in the log4j2.xml file it did find.)

Thoughts?





--
Loading...