Add commands to view Java Language Server debug and error logs

[karlvr]

Resolves #2367, which in spite of being closed wasn't resolved as such (we found out how to view the logs but didn't make it easy)

[rgrunber]

I think exposing the stdout/stderror logs of the server is a good idea for those wishing to get more information.

@testforstephen , let me know if you're fine with such an addition.

[rgrunber]

I wonder whether it makes sense to rename these, since they aren't exactly what's listed.

We have 4 log files :

• the client log : this is just the logs on the client side that document the interaction between the client and server
• the server log : this is the Eclipse Platform logging service. That's why you see the !ENTRY...!Message for every entry. They are actually meant to be shown to the user in a table, by any plugin that wishes to report something.
• the standard output/error logs : These are what this PR is exposing. If you look at https://github.com/eclipse/eclipse.jdt.ls/blob/master/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/JavaLanguageServerPlugin.java#L518-L528 , you'll see that's the case. However, only when jdt.ls.debug is set to true .

Basically, I would probably call them :

Open Java Language Server Standard Output Log File
Open Java Language Server Standard Error Log File

Things like SERVER_DEBUG or serverDebug should probably become SERVER_STDOUT / serverStdout
Things like SERVER_ERROR or serverError should probably become SERVER_STDERR / serverStderr

[karlvr]

@rgrunber Thank you very much for this feedback. I've pushed a correction for this now.

What do you think about alerting with instructions to set jdt.ls.debug to true if those files can't be found? I'll experiment a little with that.

[testforstephen]

I'm thinking who is the audience for these logs. To me, extension developers might be interested in these logs, but normal users might not be. If this is the case, I'd rather not expose too many log commands in the Command Palette, and instead reuse the existing command Java: Open All Log Files.

We can refactor this to Java: Open All Log Files.... And when you click on it, it will list all possible log locations for user to pick, including:

• Java Extension Client Log File
• Java Language Server Log File
• Java Language Server Standard Output Log File
• Java Language Server Standard Error Log File
• Any others if needed

@karlvr @rgrunber WDYT?

[karlvr]

@testforstephen I started down this path because I wanted to see the logs from Maven; effectively the Maven Console I missed from Eclipse.

@rgrunber directed me to the files, including how to activate them, in #2367.

The contents of the stdout (I think) is actually what I expected to see in the Maven output window in VS Code… whereas at least for me that output only ever consists of one line identifying my local repository. Given how much Maven does, seeing its output is actually something I'm regularly interested in, especially when I'm pondering how long it's taking and how much processing power it's using!

I do agree that the approach I've used in this PR is a proliferation of options.

Perhaps it would be possible to channel items from at least one of these logs into the Maven Output window, so it's directly accessible?

[rgrunber]

• I did also feel a bit like adding 2 more commands for logs might cause more confusion/clutter. So how about we remove the code that exposes the 2 additional commands, and simply have openLogs() call openRollingServerLogFile(..) twice (once for .out-jdt.ls & .err-jdt.ls). That should still improve things for now.
• What do you mean by "Maven Output window" ? I don't think we provide such a view. Is it coming from vscode-maven ? It would be different than the "Maven" output/error we produce.
• To your question of whether we could redirect the m2e stdout/stderr to somehwere else, I was thinking about this as well! At the end of the day, the only reason those 2 files exist, is because we defined them at https://github.com/eclipse/eclipse.jdt.ls/blob/master/org.eclipse.jdt.ls.core/logback.xml. But that was just the easiest thing to do at the time. There's plenty of other "Appenders" we could use. See https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.logback.configuration/defaultLogbackConfiguration/logback.xml as an example. The interesting one is EclipseLogAppender. It looks like it's logging to the Eclipse Platform log, so this might actually be the way to redirect everything into the JDT-LS server logs! The slight downside.. we need to add org.eclipse.m2e.logback.appender (~12kb) to our JDT-LS runtime.

[karlvr]

@rgrunber sorry, too many plugins! The Maven Output is from the Maven plugin. It has an entry in the Output tab, but it's underused. It's always where I imagined the Maven log would appear. I discovered when I started my investigation there that the Maven plugin didn't control m2e but forgot!

If we can't extract just the m2e bits then getting the logs into the Java Language Server Output would be great.

[rgrunber]

Going through trying to get the EclipseLogAppender working made me discover we have an issue with custom logback configs : eclipse-jdtls/eclipse.jdt.ls#2077 , so the discussion is definitely appreciated.

I was able to get some of the events to be logged to the language server .log file, but not all. So until we get it working properly, I'm fine with accepting this. Just need to make the following change :

• Do not register the stdout/stderr commands in the command palette. They should exist so that Open All Log Files calls them but for now let's not expose them beyond this.
  I think the way to do this is under the commandPalette definition in package.json, define something like :

{
  "command": "the.command.to.hide",
  "when": "false"
}

• Do the same for java.open.serverLog & java.open.clientLog

[rgrunber]

I'll be pushing this in since @karlvr did some good work to get this ready. I've used preview: false from TextDocumentOptions in order to allow the log file tabs to open under the same view column. This makes them a lot easier to read than opening each one in its own column.

The Maven related logging will show up under the server logs once the logback tracing PR is merged. It's still good to be able to view the stdout/stderr logs. Further improvements might involve adding a quick-pick menu to select which (of the 4) logs.

[testforstephen]

Oh, you hide this command. "Open Java Language Server Log File" is the most frequently command I use for troubleshooting.

You need to update wiki as well.
https://github.com/redhat-developer/vscode-java/wiki/Troubleshooting

[rgrunber]

I"m open to restoring it, if you feel the convenience of not having the other 3 log files show up is worth it.

[testforstephen]

Yes, I'd like to keep server log command.

[jdneo]

The current change breaks the VS Code's package.json schema:

• title is a mandatory field here.
• when is not a valid field here, should be used under menus section.

A warning can be seen after startup:

[testforstephen]

Agreed. For those commands that are taken as APIs, we don't need to declare it in package.json.