Newbie: Change logging level programmatically?

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

Newbie: Change logging level programmatically?

Andrew P. Lentvorski
I'm clearly missing something obvious, but I absolutely cannot figure
out how to change the logging level in either my build.gradle file or my
actual Java code.  I want DEBUG level, but I can't seem to find the
right thing to twiddle.  What am I missing?

My build.gradle files has these dependencies:

dependencies {

     compile 'org.slf4j:slf4j-api:1.7.21'

     compile 'org.slf4j:slf4j-simple:1.7.21'

I don't want to use command line options for various reasons.  (The
primary reason being that Buildship (Eclipse gradle integration) doesn't
seem to cooperate very well with them).

Thanks,
-a
_______________________________________________
slf4j-user mailing list
[hidden email]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Newbie: Change logging level programmatically?

Joachim Durchholz
Am 17.10.2016 um 01:31 schrieb Andrew P. Lentvorski:
> I'm clearly missing something obvious, but I absolutely cannot figure
> out how to change the logging level

You do not configure SLF4J, you configure the backend you're using
(logback, log4j, or whatever it is).
These are typically configured using property files.

 > in either my build.gradle file

The primary purpose of Gradle is to build your software, i.e. to compile
it, package it in jars, and possibly deploy it.
It does not run your code - unless you do automated testing, which means
it will run your code for some scenarios but not all where you want
logging. Not unless you're doing something very unusual anyway :-)

So build.gradle is probably not the right place to configure logging.

 > or my actual Java code.

Best practice is to avoid doing that as far as possible.
You want log levels to be configurable from the config file, so you can
change them withough having to recompile the code.
(The purpose of logging is for diagnosis: Software health monitoring,
pinpointing bugs, etc. Per-package log levels allow you to highlight
those parts of that machine that are under investigation, so you want to
be able to adjust that on the fly. At least one backend allows you to
reconfigure logging while the software is running.)

> I don't want to use command line options for various reasons.  (The
> primary reason being that Buildship (Eclipse gradle integration) doesn't
> seem to cooperate very well with them).

Buildship has no business with passing on command-line parameters
actually; its primary purposes are to run the various rules of a
build.gradle, and to update the Eclipse project's compiler etc. settings
so that they match what build.gradle is doing.

So if you want to pass on command-line parameters inside the Gradle
build, you do that in gradle.build; if you want to pass them to your
running code, you use an Eclipse launch configuration.
(You can store launch configurations as part of your project. It's
inside the "Common" tab of the launch configuration.)

HTH
Jo
_______________________________________________
slf4j-user mailing list
[hidden email]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Newbie: Change logging level programmatically?

Ceki Gulcu

Andrew mentioned that he was using slf4j-simple which is mostly a
bare-bones implementation of the org.slf4j.Logger directing all output
to System.err or System.out.

See the following page for more details.

http://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html

HTH,

On 10/17/2016 6:55, Joachim Durchholz wrote:

> Am 17.10.2016 um 01:31 schrieb Andrew P. Lentvorski:
>> I'm clearly missing something obvious, but I absolutely cannot figure
>> out how to change the logging level
>
> You do not configure SLF4J, you configure the backend you're using
> (logback, log4j, or whatever it is).
> These are typically configured using property files.
>
>> in either my build.gradle file
>
> The primary purpose of Gradle is to build your software, i.e. to compile
> it, package it in jars, and possibly deploy it.
> It does not run your code - unless you do automated testing, which means
> it will run your code for some scenarios but not all where you want
> logging. Not unless you're doing something very unusual anyway :-)
>
> So build.gradle is probably not the right place to configure logging.
>
>> or my actual Java code.
>
> Best practice is to avoid doing that as far as possible.
> You want log levels to be configurable from the config file, so you can
> change them withough having to recompile the code.
> (The purpose of logging is for diagnosis: Software health monitoring,
> pinpointing bugs, etc. Per-package log levels allow you to highlight
> those parts of that machine that are under investigation, so you want to
> be able to adjust that on the fly. At least one backend allows you to
> reconfigure logging while the software is running.)
>
>> I don't want to use command line options for various reasons.  (The
>> primary reason being that Buildship (Eclipse gradle integration) doesn't
>> seem to cooperate very well with them).
>
> Buildship has no business with passing on command-line parameters
> actually; its primary purposes are to run the various rules of a
> build.gradle, and to update the Eclipse project's compiler etc. settings
> so that they match what build.gradle is doing.
>
> So if you want to pass on command-line parameters inside the Gradle
> build, you do that in gradle.build; if you want to pass them to your
> running code, you use an Eclipse launch configuration.
> (You can store launch configurations as part of your project. It's
> inside the "Common" tab of the launch configuration.)
>
> HTH
> Jo
> _______________________________________________
> slf4j-user mailing list
> [hidden email]
> http://mailman.qos.ch/mailman/listinfo/slf4j-user
_______________________________________________
slf4j-user mailing list
[hidden email]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
Loading...