We Keep Coding

Debugging in Java - Eclipse [duplicate]

I want to change the logging level depending if I'm debbugging or not, but I can't find a code snippet to check if the application is running in debug mode.
I'm using eclipse to debug the application, so if the solution only works within Eclipse it will be fine.

Found the answer on how-to-find-out-if-debug-mode-is-enabled
boolean isDebug = java.lang.management.ManagementFactory.getRuntimeMXBean().
getInputArguments().toString().contains("-agentlib:jdwp");
This will check if the Java Debug Wire Protocol agent is used.

You could modify the Debug Configuration. For example add a special VM argument only in the Debug Configuration. You can use System.getProperties() to read the supplied arguments.
Even better, modify the configurations (Run and Debug) to load a different logging configuration file. It isn't good if you need to write code to determine the logging level. This should only be a matter of configuration.

There is not an officially sanctioned way to reliably determine if any given JVM is in debug mode from inside the JVM itself, and relying on artifacts will just break your code some time in the future.
You will therefore need to introduce a methology yourself. Suggestions:
A system property.
An environment variable (shell variable like $HOME or %HOME%)
Ask the JVM about the physical location of a given resource - http://www.exampledepot.com/egs/java.lang/ClassOrigin.html - and based on it, make your decision (does the path contain the word "debug"? is it inside a jar or an unpacked class file? etc).
JNDI
The existance or content of a particular resource.

Have you tried add a vm argument in the eclipse run config?
Pass this as a VM Argument
-Ddebug=true
then you can do Boolean.getBoolean("debug") to check this.

If you are setting the debug level from your own program, may be a line like:
public static final boolean DEBUG_MODE = System.getProperty("java.vm.info", "").contains("sharing");
would do the trick.
Just tested it in eclipse3.5:
package test;
public class Test
{
/**
* #param args
*/
public static void main(String[] args)
{
System.out.println(System.getProperty("java.vm.info", ""));
}
}
will display:
mixed mode, sharing
if launched without debug
mixed mode
if executed with debug launcher
Joachim Sauer comments:
This is highly system depending.
I assume the "sharing" indicates that cross-VM class-sharing is active.
This is a very new feature and is only available on some platforms.
Furthermore there can be many possible reasons to en- or disable it, so I wouldn't use this for debug-mode detection.
(Note: I tested it with the latest jdk1.6b14. I leave this as a CW answer.)

Have a look here:
http://wiki.eclipse.org/FAQ_How_do_I_use_the_platform_debug_tracing_facility%3F
Moreover, I think you can't know if your app is run in debug mode. The only thing you can do is to pass an argument to your JVM when you debug.
Manu

If using socket (e.g. 9999) you can call netstat to check if connection was established:
Process p = new ProcessBuilder("netstat", "-n").start();
String stdout = IOUtils.toString(p.getInputStream(), Charset.defaultCharset());
Then scan in stdout for 127.0.0.1:9999.*ESTABLISHED

vertx LoggerHandler not adding logback

I am trying to use LoggerHandler to log all incoming requests. I am using logback.xml to specify appenders. I am setting system property for logging.
System.setProperty("org.vertx.logger-delegate-factory-class-name",
"org.vertx.java.core.logging.impl.SLF4JLogDelegateFactory");
Still it is logging everything in console not in file.

This worked for me with Vert.x 3.4.1:
import static io.vertx.core.logging.LoggerFactory.LOGGER_DELEGATE_FACTORY_CLASS_NAME;
import io.vertx.core.logging.LoggerFactory;
// ...
setProperty (LOGGER_DELEGATE_FACTORY_CLASS_NAME, SLF4JLogDelegateFactory.class.getName ());
LoggerFactory.getLogger (LoggerFactory.class); // Required for Logback to work in Vertx
The key is to get a logger, which I guess initializes the Logging subsystem, the class that you use to get a Logger seems irrelevant as I tried with two different ones.
I run these lines as the first ones of the program in production code and in the tests to work properly in both contexts.

I was able to get it to work by setting the VM options as such:
-Dvertx.logger-delegate-factory-class-name=io.vertx.core.logging.Log4jLogDelegateFactory
Then in my log4j.properties, I had to add this:
log4j.category.io.vertx = TRACE

I know this question is getting a bit old, but the only way I was able to get the vertx LoggerHandler to not use JUL was to call LoggerFactory.initialise() after setting the system property as described in the question.
Even better, I set the property in my build.gradle, like so:
run {
systemProperty(
"vertx.logger-delegate-factory-class-name",
"io.vertx.core.logging.SLF4JLogDelegateFactory"
)
args = ['run', mainVerticleName, "--redeploy=$watchForChange", "--launcher-class=$mainClassName", "--on-redeploy=$doOnChange",
"-Dvertx.logger-delegate-factory-class-name=io.vertx.core.logging.SLF4JLogDelegateFactory" ]
}
And then at the very top of my MainVerticle::start I have:
LoggerFactory.initialise()
And, boom. Everything is now formatted correctly, including all the startup output.

Jodd Java - Can i hide WARN message on console?

My Program not error is perfect work but I feel annoyed from warning message.
So, I want to hide it from program console. What should I do?
(i can't edit html source code)
[Thread-4] WARN jodd.lagarto.dom.LagartoDOMBuilderTagVisitor - Orphan closed tag ignored </meta>
[Thread-3] WARN jodd.lagarto.dom.LagartoDOMBuilderTagVisitor - Unclosed tag closed: <p>
Thanks for kindness.

Oh Yea!
I can find solution with myself. (Thank a lot Elliott Frisch for guide :) )
i use Logback Library
import ch.qos.logback.classic.Logger;
import org.slf4j.LoggerFactory;
public class Main {
final static Logger joddlogger = (Logger) LoggerFactory.getLogger("jodd");
public static void main(String[] argv) {
joddlogger.setLevel(ch.qos.logback.classic.Level.OFF);
//do something...
}
}

That is one correct answer, as #Jaynova and #Elliott Frisch said. Jodd uses Logback, so all you have to do is to mute the logging category in logback configuration, as explained in the other answer. You can do that from Java or from logback configuration file.
There is one more solution, added recently: LagartoDOMBuilder has a property parsingErrorLogLevel, which purpose is to set the log level of parsing errors (by default is set to WARN). Sometimes, its important to have these errors in the log (eg parsing your own code), and sometimes its just annoying (parsing live code, usually with lot of errors).
So while you can switch off the all logging for that package, you may also mute just the parsing errors by setting the level to DEBUG (assuming your global log level is higher).
So, in short, get the LagartoDOMBuilder instance before parsing and set this flag :)

Unable to set log level in a Java web start application?

Some logging levels appear to be broke?
I run a Java web start (which I will begin to call JWS from now on) application straight from a GlassFish 3.1.2.2 instance. The client has a static logger like so:
private final static Logger LOGGER;
static {
LOGGER = Logger.getLogger(App.class.getName());
// Not sure how one externalize this setting or even if we want to:
LOGGER.setLevel(Level.FINER);
}
In the main method, I begin my logic with some simple testing of the logging feature:
alert("isLoggable() INFO? " + LOGGER.isLoggable(Level.INFO)); // Prints TRUE!
alert("isLoggable() FINE? " + LOGGER.isLoggable(Level.FINE)); // ..TRUE
alert("isLoggable() FINER? " + LOGGER.isLoggable(Level.FINER)); // ..TRUE
alert("isLoggable() FINEST? " + LOGGER.isLoggable(Level.FINEST)); // ..FALSE
My alert methods will display a JOptionPane dialog box for "true GUI logging". Anyways, you see the printouts in my comments I added to the code snippet. As expected, the logger is enabled for levels INFO, FINE and FINER but not FINEST.
After my alert methods, I type:
// Info
LOGGER.info("Level.INFO");
LOGGER.log(Level.INFO, "Level.INFO");
// Fine
LOGGER.fine("Level.FINE");
LOGGER.log(Level.FINE, "Level.FINE");
// Finer
LOGGER.finer("Level.FINER");
LOGGER.log(Level.FINER, "Level.FINER");
LOGGER.entering("", "Level.FINER", args); // <-- Uses Level.FINER!
// Finest
LOGGER.finest("Level.FINEST");
LOGGER.log(Level.FINEST, "Level.FINEST");
I go to my Java console and click on the tab "Advanced", then I tick "Enable logging". Okay let's start the application. Guess what happens? Only Level.INFO prints! Here's my proof (look at the bottom):
I've done my best to google for log files on my computer and see if not Level.FINE and Level.FINER end up somewhere on the file system. However, I cannot find the log messages anywhere.
Summary of Questions
Why does it appear that logging of Level.FINE and Level.FINER does not work in the example provided?
I set the logging level in my static initializing block, but I'd sure like to externalize this setting to a configuration file of some sort, perhaps packaged together with the EAR file I deploy on GlassFish. Or why not manually write in some property in the JNLP file we download from the server. Is this possible somehow?

Solution for problem no 1.
After doing a little bit more reading on the topic, I concluded that a logger in Java uses a handler to publish his logs. And this handler in his turn has his own set of "walls" for what levels he handles. But this handler need not be attached directly to our logger! You see loggers are organized in a hierarchical namespace and a child logger may inherit his parents handlers. If so, then By default a Logger will log any output messages to its parent's handlers, and so on recursively up the tree (see Java Logging Overview - Oracle).
I ain't saying I get the full picture just yet, and I sure didn't find any quotes about how all of this relates to a Java Web Start application. Surely there has to be some differences. Anyways, I did manage to write together this static initializing block that solves my immediate problem:
static {
LOGGER = Logger.getLogger(App.class.getName());
/*
* This logic can be externalized. See the next solution!
*/
// DEPRECATED: LOGGER.setLevel(Level.FINER);
if (LOGGER.getUseParentHandlers())
LOGGER.getParent().getHandlers()[0].setLevel(Level.FINER);
else
LOGGER.setLevel(Level.FINER);
}
Solution for problem no 2.
The LogManager API docs provided much needed information for the following solution. In a subdirectory of your JRE installation, there is a subdirectory called "lib" and in there you shall find a "logging.properties" file. This is the full path to my file on my Windows machine:
C:\Program Files (x86)\Java\jre7\lib\logging.properties
In here you can change a lot of flavors. One cool thing you could do is to change the global logging level. In my file, this was done on row 29 (why do we see only a dot in front of the "level"? The root-parent of all loggers is called ""!). That will produce a hole lot of output; on my machine I received about one thousand log messages per second. Thus changing the global level isn't even plausible enough to be considered an option. Instead, add a new row where you specify the level of your logger. In my case, I added this row:
martinandersson.com.malivechat.app.App.level = FINER
However, chances are you still won't see any results. In solution no 1, I talked about how loggers are connected to handlers. The default handler is specified in logging.properties, most likely on row 18. Here's how my line reads:
handlers= java.util.logging.ConsoleHandler
Also previously, I talked about how these handlers in their turn use levels for what should trouble their mind. So, find the line that reads something like this (should now be on row 44?):
java.util.logging.ConsoleHandler.level = INFO
..and in my case I swapped "INFO" to "FINER". Problem solved.
But!
My original inquiry into this matter still hasn't provided an answer how one can set these properties closer in par with the application deployment. More specifically, I would like to attach these properties in a separate file, bundled with the application EAR file I deploy on GlassFish or something like that. Do you have more information? Please share!

Cleaning noise out of Java stack traces

My Java stack traces have a lot of entries that I don't care about, showing method invocation going through proxies and Spring reflection methods and stuff like that. It can make it pretty hard to pick out the part of the stack trace that's actually from my code. Ruby on Rails includes a "stack trace cleaner" where you can specify a list of stack trace patterns to omit from printed stack traces - what's the best way to do something like that, universally, for Java?
It'd be best if this worked everywhere, including in the Eclipse jUnit runner.

intellij-idea allows customizable stack trace folding, especially useful with dynamic languages.
(source: jetbrains.com)
and an Analyzing external stack traces tool.
I can imagine general tool/filter working on logging framework (like logback or log4j) level. I don't think there is any general support for that, but I think it is a great idea to implement this. I will have a look, maybe it is not that much work.
UPDATE: I implemented filtering irrelevant stack trace lines in logs for logback, also follow LBCLASSIC-325.

eclipse has a preference Stack trace filter patterns (look at java > junit or search for stacktrace in the preferences). You can ignore packages (also with wildcards), classes or methods. Does work for direct Test calls (via Run as junit Test), not for commandline runs like ant or maven.

I actually wrote an open source library MgntUtils (available at Github and maven central)
that contains several utilities. Here is a link to an article about the library: MgntUtils Open Source Java library. One of the utilities is a general purpose stacktrace
filter that I used extensively and found it very useful. The class is called
TextUtils and it has method getStacktrace() with several overridden signatures.
It takes a Throwable instance and allows to set a package prefix of the packages
that are relevant. Let's say your company's code always resides in packages that
start with "com.plain.*" So you set such a prefix and do this
logger.info(TextUtils.getStacktrace(e, true, "com.plain."));
this will filter out very smartly all the useless parts of the trace leaving
you with very concise stacktrace. Also I found it very convinient to pre-set the
prefix and then just use the convinience method
TextUtils.getStacktrace(e);
It will do the same. To preset the prefix just use method
setRelevantPackage("com.plain.");
Also if you use Spring environment you can add the following segment to your
Spring configuration and then you all set:
<bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
<property name="targetClass" value="com.mgnt.utils.TextUtils"/>
<property name="targetMethod" value="setRelevantPackage"/>
<property name="arguments" value="com.plain."/>
</bean>
The library comes with well written (I hope) Javadoc that explains everything in detail. But here is a little teaser: you will get a following stacktrace:
at com.plain.BookService.listBooks()
at com.plain.BookService$$FastClassByCGLIB$$e7645040.invoke()
at net.sf.cglib.proxy.MethodProxy.invoke()
...
at com.plain.LoggingAspect.logging()
at sun.reflect.NativeMethodAccessorImpl.invoke0()
...
at com.plain.BookService$$EnhancerByCGLIB$$7cb147e4.listBooks()
at com.plain.web.BookController.listBooks()
instead of
at com.plain.BookService.listBooks()
at com.plain.BookService$$FastClassByCGLIB$$e7645040.invoke()
at net.sf.cglib.proxy.MethodProxy.invoke()
at org.springframework.aop.framework.Cglib2AopProxy$CglibMethodInvocation.invokeJoinpoint()
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed()
at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed()
at com.plain.LoggingAspect.logging()
at sun.reflect.NativeMethodAccessorImpl.invoke0()
at sun.reflect.NativeMethodAccessorImpl.invoke()
at sun.reflect.DelegatingMethodAccessorImpl.invoke()
at java.lang.reflect.Method.invoke()
at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs()
at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod()
at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke()
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed()
at org.springframework.aop.interceptor.AbstractTraceInterceptor.invoke()
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed()
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke()
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed()
at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke()
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed()
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept()
at com.plain.BookService$$EnhancerByCGLIB$$7cb147e4.listBooks()
at com.plain.web.BookController.listBooks()

For log4j:
package package1;
public class FilteringThrowableRenderer implements ThrowableRenderer {
private static final String PACKAGES_SEPARATOR = "\\s*,\\s*";
private final static String TRACE_PREFIX = "\tat ";
private static final String FILTERED_WARNING = " [Stacktrace is filtered]";
ThrowableRenderer defaultRenderer = new EnhancedThrowableRenderer();
List<String> skippedLinePrefixes;
public FilteringThrowableRenderer() {
String skippedPackagesString = "java,org"; // TODO: move it to config
String[] skippedPackages =
skippedPackagesString.trim().split(PACKAGES_SEPARATOR);
skippedLinePrefixes = new ArrayList<String>(skippedPackages.length);
for (String packageName : skippedPackages) {
skippedLinePrefixes.add(TRACE_PREFIX + packageName);
}
}
#Override
public String[] doRender(Throwable throwable) {
String[] initialTrace = defaultRenderer.doRender(throwable);
if (!skippedLinePrefixes.isEmpty()) {
List<String> result = new ArrayList<String>(initialTrace.length);
boolean filtered = false;
trace: for (String element : initialTrace) {
for (String skippedLinePrefix : skippedLinePrefixes) {
if (element.startsWith(skippedLinePrefix)) {
filtered = true;
continue trace;
}
}
result.add(element);
}
if (filtered && result.size() > 0) {
result.set(0, result.get(0) + FILTERED_WARNING);
}
return result.toArray(new String[result.size()]);
} else {
return initialTrace;
}
}
}
to enable it with code:
ThrowableRendererSupport loggerRepository =
(ThrowableRendererSupport) LogManager.getLoggerRepository();
loggerRepository.setThrowableRenderer(new FilteringThrowableRenderer());
or with log4j.properties:
log4j.throwableRenderer=package1.FilteringThrowableRenderer

This plugin's pretty nice
https://marketplace.eclipse.org/content/grep-console
Just a generalized grep formatting utility for the Eclipse console, so no additional dependencies. I format all my irrelevant noise to grey text.

Not exactly what you are looking for (and, to the best of my knowledge, there is no universal solution for your problem, at least I've never heard of a famous tool to clean and extract info from Java stacktraces).
Anyway, this post from July, 05, 2011 at Faux' Blog describes a Java Agent in early stages whose purpose is to enrich (and not filter) stack traces. It evens provide a link to a git repository with a mavenized project. Maybe you can go from here, tweak his code and roll your own solution (who knows, maybe even start an open source project).