-
-
Notifications
You must be signed in to change notification settings - Fork 404
Prefix logging for BSP #5154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Prefix logging for BSP #5154
Conversation
Seems integration.ide[bsp-server].packaged.server.testForked is run on CI, but not the local one
So that it's shared between class loaders
Includes #5153 for now |
This comment was marked as resolved.
This comment was marked as resolved.
About 1113602, without it, it seems |
final def info(s: String): Unit = | ||
info(logKey, s) | ||
|
||
def info(logKey: Seq[String], s: String): Unit | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need these changes to the Logger
interface?
Logger
is shared throughout Mill as part of core.api
, and thus it really needs to be as simple as possible. Rather than adding a more verbose version of info
/debug
/etc., could we instead instantiate sub-classes of Logger
inside MillBuildServer
that have the correct logKey
set?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we even use the PrefixLogger
class for this? Adding a prefix to log lines is exactly what that class is meant to do
handlerTasks( | ||
targetIds = _ => targetIds, | ||
tasks = { case m: RunModuleApi => m.bspJvmRunTestEnvironment } | ||
tasks = { case m: RunModuleApi => m.bspJvmRunTestEnvironment }, | ||
requestDescription = "jvmRunTestEnv", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need custom names for these? We already take the sourcecode.Name
of each endpoint method, which I would have thought would give us enough information about what endpoint each log message is comming from
@@ -12,22 +12,44 @@ public DoubleLock(Lock lock1, Lock lock2) throws Exception { | |||
|
|||
@Override | |||
public Locked lock() throws Exception { | |||
return new DoubleLocked(lock1.lock(), lock2.lock()); | |||
Locked l1 = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's remove this from this PR since it's unrelated
: CompletableFuture[InitializeBuildResult] = | ||
handlerRaw(checkInitialized = false) { | ||
: CompletableFuture[InitializeBuildResult] = { | ||
val logger = createLogger() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need to call createLogger()
and pass it in to every handlerRaw
? Could we instead make handlerRaw
take the sourcecode.Enclosing
and create the logger internally?
When Mill runs as a BSP server, this makes it log in a similar way as when running Mill from the command-line, with
[…]
prefixes.For example, the small BSP session run in the test added in this PR logs the following to stderr:
This helps make sense of what's going on when working on BSP-releated features, but could also help Mill BSP users in case anything goes wrong.