Improve tracing capability of m2e through m2e.logback.configuration.

[rgrunber]

• Add 'org.eclipse.m2e.logback.feature' to target platform
• Add 'org.eclipse.m2e.logback' plugin to language server product
• This exposes the 'logback.configurationFile' system property through
  which one can provide a logback configuration

Signed-off-by: Roland Grunberg rgrunber@redhat.com

A few notes on how this could work :

Suppose we want to log using standard out/err :

In : /path/to/logback.xml

<configuration scan="true">
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
      <pattern>%date [%thread] %-5level %logger{35} - %msg%n</pattern>
    </encoder>
  </appender>
  <root level="DEBUG">
    <appender-ref ref="STDOUT" />
  </root>
</configuration>

Now when launching JDT-LS, we need to set -Dlogback.configurationFile=/path/to/logback.xml -Djdt.ls.debug=true
(The latter ensures JDT-LS will create the correct log files in the workspace .metadata folder. One would need to use java.jdt.ls.vmargs to set these on the client side.

A custom logfile location is also possible, but all that configuration would happen in the logback.xml without the need for setting
jdt.ls.debug=true

Update :

With this change, the default logging for m2e would generate 'INFO' level logging only in ${workspace}/.metadata/.plugins/org.eclipse.m2e.logback.configuration/0.log.

@fbricon

[snjeza]

The PR works properly. Could you update:

• https://github.com/eclipse/eclipse.jdt.ls/blob/master/launch/jdt.ls.remote.server.launch
• https://github.com/eclipse/eclipse.jdt.ls/blob/master/launch/jdt.ls.socket-stream.launch

[rgrunber]

The PR works properly. Could you update:
* https://github.com/eclipse/eclipse.jdt.ls/blob/master/launch/jdt.ls.remote.server.launch
* https://github.com/eclipse/eclipse.jdt.ls/blob/master/launch/jdt.ls.socket-stream.launch

Added.

[testforstephen]

Would you consider sending a PR at vscode-java side to adopt the new log capability?

[rgrunber]

I think this would be the next logical step. Making it easier to do the above steps by enabling some preference.

[testforstephen]

OK, i'm saying this to just want a bits to have a look at the whole E2E workflow in VS Code.

A few questions here:

• Will the logs from the new m2e.logback be merged to the existing jdt.ls .log file under .metadata directory?
• Is this enabled by default, right?
  My understanding is that the -Dlogback.configurationFile=/path/to/logback.xml vmArgs is just an optional parameter. It's used to override the log preference such as the log level. If you don't specify this parameter, m2e.logback will startup with the default preference, right?

[rgrunber]

* Will the logs from the new m2e.logback be merged to the existing jdt.ls .log file under .metadata directory?

No, they will be merged into .out-jdt.ls-${date}.log which would be right beside the .log file. The jdt.ls.debug=true creates new logfiles that this change takes advantage of.

If you want to log directly to The Eclipse workspace .log, I believe this should be possible, though I haven't tested. There is an additional plugin, org.eclipse.m2e.logback.appender (also fairly small) that provides EclipseLogAppender

* Is this enabled by default, right?

In the process of answering this, I've found a possible issue. While the above isn't enable by default, there is some logging that can happen by default. By just adding the configuration plugin, and if no logback file is defined, it defaults to the logback.xml file stored within the plugin. STDOUT/EclipseLog/MavenConsoleLog won't do anything by default, but FILE will log because ${org.eclipse.m2e.log.dir} is set to the workspace location by default. It's set to INFO though, so it's not verbose.

  My understanding is that the `-Dlogback.configurationFile=/path/to/logback.xml` vmArgs is just an optional parameter. It's used to override the log preference such as the log level. If you don't specify this parameter, m2e.logback will startup with the default preference, right?

Yes. Without that property, m2e will use the default logback settings, which it generates in ${workspace}/.metadata/.plugins/org.eclipse.m2e.logback.configuration/logback.xml

[snjeza]

There is an additional plugin, org.eclipse.m2e.logback.appender (also fairly small) that provides EclipseLogAppender

The org.eclipse.m2e.logback.appender plugin requires the org.eclipse.m2e.core.ui and org.eclipse.ui.* plugins. We can't use it in Java LS.

[rgrunber]

There is an additional plugin, org.eclipse.m2e.logback.appender (also fairly small) that provides EclipseLogAppender

The org.eclipse.m2e.logback.appender plugin requires the org.eclipse.m2e.core.ui and org.eclipse.ui.* plugins. We can't use it in Java LS.

Yup, Looks like because of the Maven appender relying on some m2e ui components.

So the only remaining concern is about the new INFO-level logging in .metadata/.plugins/org.eclipse.m2e.logback.configuration/0.log that this would introduce. I think the amount is comparable to what logging is done in .metadata/.log .

[testforstephen]

I see.

Since this new trace capability is just used to diagnose the language server itself, rather than the user's application, and asking the end user to provide a logback.xml file to enable verbose looks a little too heavy.

A more reasonable approach is only exposing one switch jdt.ls.debug to control the verbose mode for jdt.ls. The extension could auto feed the corresponding logback.xml configurations to logback plugin based on jdt.ls.debug. For example, when the extension detects the jdt.ls.debug is enabled, then automatically add the built-in verbose config to the vmArgs -Dlogback.configurationFile=/extension_internal_path/logback.xml. Also this could be done at eclipse.jdt.ls side if it supports setting logback.configurationFile via programming API.

[rgrunber]

Now, setting jdt.ls.debug=true should automatically enable DEBUG level logging (provided by our own logback.xml) into ${workspace}/.metadata/.out-jdt.ls-${timestamp}.log as long as logback.configurationFile has not been set.

The requirement (in the code) that logback.configurationFile not be set is so that users could still have jdt.ls.debug=true but provide their own logback xml file.

[snjeza]

test this please

[rgrunber]

test this please

I've tested the change with/without jdt.ls.debug and it looks like it's working for me. I've also tested the launch configurations for debugging in VSCode and they also appear to start up and connect.

[snjeza]

test this please
I've tested the change with/without jdt.ls.debug and it looks like it's working for me. I've also tested the launch configurations for debugging in VSCode and they also appear to start up and connect.

"test this please" is a github command. It restarts the build.

[snjeza]

test this please