We Keep Coding

How to enable DEBUG level logging with Jetty from UI

I'm trying to set the logging level to DEBUG in a Jetty instance. It is working when we add
-Dorg.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.StdErrLog
-Dorg.eclipse.jetty.LEVEL=DEBUG Under property file and pass it to the JVM.
My use case is I was trying to set logging level from UI so that without restarting the server we can switch logging level.
for example, DEBUG to WARN

Option 1: Jetty 9 and StdErrLog with JMX
Using Jetty 9, enable JMX on the server, and use a JMX client to set the StdErrLog debug attributes.
Look for MBean Name org.eclipse.jetty.util.log:type=stderrlog,id=0
The attribute is called debugEnabled (a boolean).
Option 2: Jetty 10+ and jetty-slf4j-impl with JMX
If using Jetty 10+, enable JMX on the server, and use a JMX client to set the level on your logger of choice.
Eg: if you are using the jetty-slf4j-impl (the spiritual successor of StdErrLog) ...
Look for MBean Name org.eclipse.jetty.logging:type=jettyloggerfactory,id=0
All of the named loggers are listed as attributes.
The operations let you getLoggerLevel and setLoggerLevel using normal JMX operation techniques.
Option 3: Different Logging Framework
Alternatively, you can use a more robust logger, like logback, or log4j2, or even java.util.logging and have even more options of runtime control over the logging.
Some offer runtime control over JMX.
Some offer the ability to reload the configuration if the configuration file changes.
Check your logger to know what it can do.
Option 4: Write your own logger level change API
You can easily write your own tooling to change the logger level based on some kind of event that your own application is in control over.
You can even make this a Handler on Jetty that only responds to specific named ServerConnectors that only list on localhost.
You just need to fetch the named Logger and then set the level. (the exact API and technique depends on your chosen logger implementation)

How to change log level to DEBUG within stormcrawler SDK?

I see that SLF4J is used for logging entries during stormcrawler components execution. However I cannot find the file containing the configuration used for SLF4J logging. Do I need a separate configuration file to enable debug level logging?

Spring boot logging / Java logging - Tool to show config/setup

I'm used to using log4j and whenever there were setup/config problems I'd enable "-Dlog4j.debug" and all the config info would be dumped out at startup.
This was very useful on a number of occasions.
Now I'm working on a Spring boot application, which I've found uses:
Commons logging Logger statements in the client code
A bridge jar (jcl-over-slf4j-xxx.jar) which translates the commons logging calls into slf4j more info here
Finally slf4j uses "logback" as the underlying logging framework
I found it rather painful to figure all this out.
Is there an equivalent of -Dlog4j.debug which can show me how this is all hanging together at startup time?

This is the best/only option I've found so far, and it's logback specific.
Use this -D on the command line:
-Dlogback.statusListenerClass=ch.qos.logback.core.status.OnConsoleStatusListener
Taken from here
This essentially is the logback equivalent of log4j's -Dlog4j.debug.
It dumps the logback startup sequence to the console at startup time, as the logging system is initialised.
This is not a true answer as I'd like some messages to show before this to show why logback is being used, but I haven't found anything like that yet.
Aside: This may also be useful for Spring Boot:
-Ddebug
Taken from here and here

If you are using logback, I assume you are using the logback.xml file? Then if you start that file with <configuration debug="true"> then it should dump the status information. More information in the documentation under status data section.

How to remove DEBUG logging from the Amazon EC2 client

I have the following simple code
AmazonEC2 ec2 = AmazonEC2ClientBuilder.standard().withRegion(Regions.US_EAST_1).build();
DescribeInstancesRequest request = new DescribeInstancesRequest();
DescribeInstancesResult response = ec2.describeInstances(request);
While running this code I see the multiline debug output. I show only the beginning below. How to remove this output?
14:03:29.877 [main] DEBUG com.amazonaws.AmazonWebServiceClient - Internal logging successfully configured to commons logger: true
14:03:38.129 [main] DEBUG com.amazonaws.metrics.AwsSdkMetrics - Admin mbean registered under com.amazonaws.management:type=AwsSdkMetrics
14:03:38.480 [main] DEBUG com.amazonaws.auth.AWSCredentialsProviderChain - Unable to load credentials from EnvironmentVariableCredentialsProvider: Unable to load AWS credentials from environment variables (AWS_ACCESS_KEY_ID (or AWS_ACCESS_KEY) and AWS_SECRET_KEY (or AWS_SECRET_ACCESS_KEY))
14:03:38.482 [main] DEBUG com.amazonaws.auth.AWSCredentialsProviderChain - Unable to load credentials from SystemPropertiesCredentialsProvider: Unable to load AWS credentials from Java system properties (aws.accessKeyId and aws.secretKey)
14:03:38.580 [main] DEBUG com.amazonaws.auth.AWSCredentialsProviderChain - Loading credentials from com.amazonaws.auth.profile.ProfileCredentialsProvider#7fb9f71f
14:03:38.786 [main] DEBUG com.amazonaws.request - Sending Request: POST https://ec2.us-east-1.amazonaws.com / Parameters: ({"Action":["DescribeInstances"],"Version":["2016-11-15"]}Headers: (User-Agent: aws-sdk-java/1.11.135 Mac_OS_X/10.12.6 Java_HotSpot(TM)_64-Bit_Server_VM/25.144-b01/1.8.0_144, amz-sdk-invocation-id: 0a1303b3-16c0-b140-8d9b-b2e22dc685b1, )
14:03:40.160 [main] DEBUG com.amazonaws.auth.AWS4Signer - AWS4 Canonical Request: '"POST /
amz-sdk-invocation-id:0a1303b3-16c0-b140-8d9b-b2e22dc685b1
amz-sdk-retry:0/0/500
host:ec2.us-east-1.amazonaws.com
user-agent:aws-sdk-java/1.11.135 Mac_OS_X/10.12.6 Java_HotSpot(TM)_64-Bit_Server_VM/25.144-b01/1.8.0_144
x-amz-date:20171113T190338Z

Log4j Assumption
Under the assumption your application's logging system is configured via a property file like log4j.properties present at the base of your Java classpath, you can reduce verbosity of the loggers by including the line
log4j.logger.com.amazonaws=WARN
WARN or ERROR will guarantee you get the least amount of logs for the loggers inside the AWS SDK.
Should you wish to keep a more granular level of logging for a specific component of the AWS SDK, you can always override the level on a restricted scope (i.e. a subpackage of the com.amazonaws), e.g.
log4j.logger.com.amazonaws.request=INFO
Logging frameworks supported by AWS Java SDK
The AWS SDK documentation states "Supported logging systems include the Java Logging Framework and Apache Log4j, among others".
I refer you to Logging AWS SDK for Java Calls for further reference.
Checking which logging framework is used by the test
The Apache Commons logging library referenced from Gradle is an abstraction layer on top of logging libraries which provide actual implementations of loggers. It is not, in itself, the logging implementation used by your test. In the statement you provided, you are using the Java logging framework ( java.util.Logger a.k.a JUL). But is it really the logging implementation your test uses?
A quick check you could do to verify if log4j is on your test's classpath is to add the VM argument -Dlog4j.debug=true and launch your test. If log4j is on your classpath you will see some output from the library printed on the console.
You could also check the runtime classpath of your test, because there may be transitive dependencies (as opposed to direct) to logging libraries, which may not be visible from the list of compile-time dependencies.
One last resort possibility could be to put a breakpoint there and debug to see which logger is used from the SDK itself (this code is called in your test because it is shown in the logs you provided).

I have been using spring boot and use aws client to get some secrets before bootstrap spring boot environment, but all secrets go to debug messages then I tried a lot of methods but this is the one works for me:
LoggerContext loggerContext = (LoggerContext)
LoggerFactory.getILoggerFactory();
loggerContext.getLogger("org.apache.http").setLevel(Level.INFO);
loggerContext.getLogger("com.amazonaws").setLevel(Level.INFO);

Log4j2 JMX: Updating the logging level via jConsole doesn't take effect

I am trying to configure log4j2 so that
I can access the loggers via JMX and
change their log levels.
When I hook everything up, I am able to access the LoggerContext via JConsole, which contains all of my LoggerConfigs.
Each LoggerConfig show the correct log level with which the application is running. And if I update a log level in any LoggerConfig it call the MBean and update the logging level correctly, which I have inspected via debugging. But the problem is that updating the log level doesn't take any effect. The application keeps on logging with the old logging level.
For example If I start the application with the XYZ logger with log level DEBUG, and change this log level to FATAL via JConsole, it changes successfully but application keep on logging in DEBUG level.
If instead of updating the single LoggerConfig if I update the LoggerContext by passing the new xml configuration with updated logging levels it works as expected.
What should be the problem? Documentation is quite and google refused to help me.
My Findings:
As far as I understood this problem is that when I update the Log level in the LoggerConfig via JConsole, log4j2 update the log level via MBean correctly but its not updating the LoggerContext, it simply call the setter method and returns. But in case if I update LoggerCoentext log4j2 create the new context to update itself.

This was indeed a bug. Thanks for reporting it. This has been fixed in trunk and will be included in the next release (rc2).

Sounds like a bug in Log4j2. I see you have raised it on their JIRA # https://issues.apache.org/jira/browse/LOG4J2-637 so we'll track the progress there. :)