2019-10-21 04:33:02 +02:00
|
|
|
/*
|
|
|
|
|
* sbt
|
|
|
|
|
* Copyright 2011 - 2018, Lightbend, Inc.
|
|
|
|
|
* Copyright 2008 - 2010, Mark Harrah
|
|
|
|
|
* Licensed under Apache License 2.0 (see LICENSE)
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
package testpkg
|
|
|
|
|
|
|
|
|
|
import scala.concurrent.duration._
|
|
|
|
|
|
|
|
|
|
// starts svr using server-test/response and perform custom server tests
|
|
|
|
|
object ResponseTest extends AbstractServerTest {
|
|
|
|
|
override val testDirectory: String = "response"
|
|
|
|
|
|
|
|
|
|
test("response from a command") { _ =>
|
|
|
|
|
svr.sendJsonRpc(
|
|
|
|
|
"""{ "jsonrpc": "2.0", "id": "10", "method": "foo/export", "params": {} }"""
|
|
|
|
|
)
|
|
|
|
|
assert(svr.waitForString(10.seconds) { s =>
|
Add multi-client ui to server
This commit makes it possible for the sbt server to render the same ui
to multiple clients. The network client ui should look nearly identical
to the console ui except for the log messages about the experimental
client.
The way that it works is that it associates a ui thread with each
terminal. Whenever a command starts or completes, callbacks are invoked
on the various channels to update their ui state. For example, if there
are two clients and one of them runs compile, then the prompt is changed
from AskUser to Running for the terminal that initiated the command
while the other client remains in the AskUser state. Whenever the client
changes uses ui states, the existing thread is terminated if it is
running and a new thread is begun.
The UITask formalizes this process. It is based on the AskUser class
from older versions of sbt. In fact, there is an AskUserTask which is
very similar. It uses jline to read input from the terminal (which could
be a network terminal). When it gets a line, it submits it to the
CommandExchange and exits. Once the next command is run (which may or
may not be the command it submitted), the ui state will be reset.
The debug, info, warn and error commands should work with the multi
client ui. When run, they set the log level globally, not just for the
client that set the level.
2019-12-18 19:24:32 +01:00
|
|
|
if (!s.contains("systemOut")) println(s)
|
2019-10-21 04:33:02 +02:00
|
|
|
(s contains """"id":"10"""") &&
|
|
|
|
|
(s contains "scala-library.jar")
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test("response from a task") { _ =>
|
|
|
|
|
svr.sendJsonRpc(
|
|
|
|
|
"""{ "jsonrpc": "2.0", "id": "11", "method": "foo/rootClasspath", "params": {} }"""
|
|
|
|
|
)
|
|
|
|
|
assert(svr.waitForString(10.seconds) { s =>
|
Add multi-client ui to server
This commit makes it possible for the sbt server to render the same ui
to multiple clients. The network client ui should look nearly identical
to the console ui except for the log messages about the experimental
client.
The way that it works is that it associates a ui thread with each
terminal. Whenever a command starts or completes, callbacks are invoked
on the various channels to update their ui state. For example, if there
are two clients and one of them runs compile, then the prompt is changed
from AskUser to Running for the terminal that initiated the command
while the other client remains in the AskUser state. Whenever the client
changes uses ui states, the existing thread is terminated if it is
running and a new thread is begun.
The UITask formalizes this process. It is based on the AskUser class
from older versions of sbt. In fact, there is an AskUserTask which is
very similar. It uses jline to read input from the terminal (which could
be a network terminal). When it gets a line, it submits it to the
CommandExchange and exits. Once the next command is run (which may or
may not be the command it submitted), the ui state will be reset.
The debug, info, warn and error commands should work with the multi
client ui. When run, they set the log level globally, not just for the
client that set the level.
2019-12-18 19:24:32 +01:00
|
|
|
if (!s.contains("systemOut")) println(s)
|
2019-10-21 04:33:02 +02:00
|
|
|
(s contains """"id":"11"""") &&
|
|
|
|
|
(s contains "scala-library.jar")
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test("a command failure") { _ =>
|
|
|
|
|
svr.sendJsonRpc(
|
|
|
|
|
"""{ "jsonrpc": "2.0", "id": "12", "method": "foo/fail", "params": {} }"""
|
|
|
|
|
)
|
|
|
|
|
assert(svr.waitForString(10.seconds) { s =>
|
Add multi-client ui to server
This commit makes it possible for the sbt server to render the same ui
to multiple clients. The network client ui should look nearly identical
to the console ui except for the log messages about the experimental
client.
The way that it works is that it associates a ui thread with each
terminal. Whenever a command starts or completes, callbacks are invoked
on the various channels to update their ui state. For example, if there
are two clients and one of them runs compile, then the prompt is changed
from AskUser to Running for the terminal that initiated the command
while the other client remains in the AskUser state. Whenever the client
changes uses ui states, the existing thread is terminated if it is
running and a new thread is begun.
The UITask formalizes this process. It is based on the AskUser class
from older versions of sbt. In fact, there is an AskUserTask which is
very similar. It uses jline to read input from the terminal (which could
be a network terminal). When it gets a line, it submits it to the
CommandExchange and exits. Once the next command is run (which may or
may not be the command it submitted), the ui state will be reset.
The debug, info, warn and error commands should work with the multi
client ui. When run, they set the log level globally, not just for the
client that set the level.
2019-12-18 19:24:32 +01:00
|
|
|
if (!s.contains("systemOut")) println(s)
|
2019-10-21 04:33:02 +02:00
|
|
|
(s contains """"error":{"code":-33000,"message":"fail message"""")
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test("a command failure with custom code") { _ =>
|
|
|
|
|
svr.sendJsonRpc(
|
|
|
|
|
"""{ "jsonrpc": "2.0", "id": "13", "method": "foo/customfail", "params": {} }"""
|
|
|
|
|
)
|
|
|
|
|
assert(svr.waitForString(10.seconds) { s =>
|
Add multi-client ui to server
This commit makes it possible for the sbt server to render the same ui
to multiple clients. The network client ui should look nearly identical
to the console ui except for the log messages about the experimental
client.
The way that it works is that it associates a ui thread with each
terminal. Whenever a command starts or completes, callbacks are invoked
on the various channels to update their ui state. For example, if there
are two clients and one of them runs compile, then the prompt is changed
from AskUser to Running for the terminal that initiated the command
while the other client remains in the AskUser state. Whenever the client
changes uses ui states, the existing thread is terminated if it is
running and a new thread is begun.
The UITask formalizes this process. It is based on the AskUser class
from older versions of sbt. In fact, there is an AskUserTask which is
very similar. It uses jline to read input from the terminal (which could
be a network terminal). When it gets a line, it submits it to the
CommandExchange and exits. Once the next command is run (which may or
may not be the command it submitted), the ui state will be reset.
The debug, info, warn and error commands should work with the multi
client ui. When run, they set the log level globally, not just for the
client that set the level.
2019-12-18 19:24:32 +01:00
|
|
|
if (!s.contains("systemOut")) println(s)
|
2019-10-21 04:33:02 +02:00
|
|
|
(s contains """"error":{"code":500,"message":"some error"""")
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test("a command with a notification") { _ =>
|
|
|
|
|
svr.sendJsonRpc(
|
|
|
|
|
"""{ "jsonrpc": "2.0", "id": "14", "method": "foo/notification", "params": {} }"""
|
|
|
|
|
)
|
|
|
|
|
assert(svr.waitForString(10.seconds) { s =>
|
Add multi-client ui to server
This commit makes it possible for the sbt server to render the same ui
to multiple clients. The network client ui should look nearly identical
to the console ui except for the log messages about the experimental
client.
The way that it works is that it associates a ui thread with each
terminal. Whenever a command starts or completes, callbacks are invoked
on the various channels to update their ui state. For example, if there
are two clients and one of them runs compile, then the prompt is changed
from AskUser to Running for the terminal that initiated the command
while the other client remains in the AskUser state. Whenever the client
changes uses ui states, the existing thread is terminated if it is
running and a new thread is begun.
The UITask formalizes this process. It is based on the AskUser class
from older versions of sbt. In fact, there is an AskUserTask which is
very similar. It uses jline to read input from the terminal (which could
be a network terminal). When it gets a line, it submits it to the
CommandExchange and exits. Once the next command is run (which may or
may not be the command it submitted), the ui state will be reset.
The debug, info, warn and error commands should work with the multi
client ui. When run, they set the log level globally, not just for the
client that set the level.
2019-12-18 19:24:32 +01:00
|
|
|
if (!s.contains("systemOut")) println(s)
|
2019-10-21 04:33:02 +02:00
|
|
|
(s contains """{"jsonrpc":"2.0","method":"foo/something","params":"something"}""")
|
|
|
|
|
})
|
|
|
|
|
}
|
2020-05-12 09:00:44 +02:00
|
|
|
|
|
|
|
|
test("respond concurrently from a task and the handler") { _ =>
|
|
|
|
|
svr.sendJsonRpc(
|
|
|
|
|
"""{ "jsonrpc": "2.0", "id": "15", "method": "foo/respondTwice", "params": {} }"""
|
|
|
|
|
)
|
|
|
|
|
assert {
|
2020-06-28 22:34:18 +02:00
|
|
|
svr.waitForString(10.seconds) { s =>
|
Add multi-client ui to server
This commit makes it possible for the sbt server to render the same ui
to multiple clients. The network client ui should look nearly identical
to the console ui except for the log messages about the experimental
client.
The way that it works is that it associates a ui thread with each
terminal. Whenever a command starts or completes, callbacks are invoked
on the various channels to update their ui state. For example, if there
are two clients and one of them runs compile, then the prompt is changed
from AskUser to Running for the terminal that initiated the command
while the other client remains in the AskUser state. Whenever the client
changes uses ui states, the existing thread is terminated if it is
running and a new thread is begun.
The UITask formalizes this process. It is based on the AskUser class
from older versions of sbt. In fact, there is an AskUserTask which is
very similar. It uses jline to read input from the terminal (which could
be a network terminal). When it gets a line, it submits it to the
CommandExchange and exits. Once the next command is run (which may or
may not be the command it submitted), the ui state will be reset.
The debug, info, warn and error commands should work with the multi
client ui. When run, they set the log level globally, not just for the
client that set the level.
2019-12-18 19:24:32 +01:00
|
|
|
if (!s.contains("systemOut")) println(s)
|
2020-05-12 09:00:44 +02:00
|
|
|
s contains "\"id\":\"15\""
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
assert {
|
|
|
|
|
// the second response should never be sent
|
|
|
|
|
svr.neverReceive(500.milliseconds) { s =>
|
Add multi-client ui to server
This commit makes it possible for the sbt server to render the same ui
to multiple clients. The network client ui should look nearly identical
to the console ui except for the log messages about the experimental
client.
The way that it works is that it associates a ui thread with each
terminal. Whenever a command starts or completes, callbacks are invoked
on the various channels to update their ui state. For example, if there
are two clients and one of them runs compile, then the prompt is changed
from AskUser to Running for the terminal that initiated the command
while the other client remains in the AskUser state. Whenever the client
changes uses ui states, the existing thread is terminated if it is
running and a new thread is begun.
The UITask formalizes this process. It is based on the AskUser class
from older versions of sbt. In fact, there is an AskUserTask which is
very similar. It uses jline to read input from the terminal (which could
be a network terminal). When it gets a line, it submits it to the
CommandExchange and exits. Once the next command is run (which may or
may not be the command it submitted), the ui state will be reset.
The debug, info, warn and error commands should work with the multi
client ui. When run, they set the log level globally, not just for the
client that set the level.
2019-12-18 19:24:32 +01:00
|
|
|
if (!s.contains("systemOut")) println(s)
|
2020-05-12 09:00:44 +02:00
|
|
|
s contains "\"id\":\"15\""
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test("concurrent result and error") { _ =>
|
|
|
|
|
svr.sendJsonRpc(
|
|
|
|
|
"""{ "jsonrpc": "2.0", "id": "16", "method": "foo/resultAndError", "params": {} }"""
|
|
|
|
|
)
|
|
|
|
|
assert {
|
2020-06-28 22:34:18 +02:00
|
|
|
svr.waitForString(10.seconds) { s =>
|
Add multi-client ui to server
This commit makes it possible for the sbt server to render the same ui
to multiple clients. The network client ui should look nearly identical
to the console ui except for the log messages about the experimental
client.
The way that it works is that it associates a ui thread with each
terminal. Whenever a command starts or completes, callbacks are invoked
on the various channels to update their ui state. For example, if there
are two clients and one of them runs compile, then the prompt is changed
from AskUser to Running for the terminal that initiated the command
while the other client remains in the AskUser state. Whenever the client
changes uses ui states, the existing thread is terminated if it is
running and a new thread is begun.
The UITask formalizes this process. It is based on the AskUser class
from older versions of sbt. In fact, there is an AskUserTask which is
very similar. It uses jline to read input from the terminal (which could
be a network terminal). When it gets a line, it submits it to the
CommandExchange and exits. Once the next command is run (which may or
may not be the command it submitted), the ui state will be reset.
The debug, info, warn and error commands should work with the multi
client ui. When run, they set the log level globally, not just for the
client that set the level.
2019-12-18 19:24:32 +01:00
|
|
|
if (!s.contains("systemOut")) println(s)
|
2020-05-12 09:00:44 +02:00
|
|
|
s contains "\"id\":\"16\""
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
assert {
|
|
|
|
|
// the second response (result or error) should never be sent
|
|
|
|
|
svr.neverReceive(500.milliseconds) { s =>
|
Add multi-client ui to server
This commit makes it possible for the sbt server to render the same ui
to multiple clients. The network client ui should look nearly identical
to the console ui except for the log messages about the experimental
client.
The way that it works is that it associates a ui thread with each
terminal. Whenever a command starts or completes, callbacks are invoked
on the various channels to update their ui state. For example, if there
are two clients and one of them runs compile, then the prompt is changed
from AskUser to Running for the terminal that initiated the command
while the other client remains in the AskUser state. Whenever the client
changes uses ui states, the existing thread is terminated if it is
running and a new thread is begun.
The UITask formalizes this process. It is based on the AskUser class
from older versions of sbt. In fact, there is an AskUserTask which is
very similar. It uses jline to read input from the terminal (which could
be a network terminal). When it gets a line, it submits it to the
CommandExchange and exits. Once the next command is run (which may or
may not be the command it submitted), the ui state will be reset.
The debug, info, warn and error commands should work with the multi
client ui. When run, they set the log level globally, not just for the
client that set the level.
2019-12-18 19:24:32 +01:00
|
|
|
if (!s.contains("systemOut")) println(s)
|
2020-05-12 09:00:44 +02:00
|
|
|
s contains "\"id\":\"16\""
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
test("response to a notification should not be sent") { _ =>
|
|
|
|
|
svr.sendJsonRpc(
|
|
|
|
|
"""{ "jsonrpc": "2.0", "method": "foo/customNotification", "params": {} }"""
|
|
|
|
|
)
|
|
|
|
|
assert {
|
|
|
|
|
svr.neverReceive(500.milliseconds) { s =>
|
Add multi-client ui to server
This commit makes it possible for the sbt server to render the same ui
to multiple clients. The network client ui should look nearly identical
to the console ui except for the log messages about the experimental
client.
The way that it works is that it associates a ui thread with each
terminal. Whenever a command starts or completes, callbacks are invoked
on the various channels to update their ui state. For example, if there
are two clients and one of them runs compile, then the prompt is changed
from AskUser to Running for the terminal that initiated the command
while the other client remains in the AskUser state. Whenever the client
changes uses ui states, the existing thread is terminated if it is
running and a new thread is begun.
The UITask formalizes this process. It is based on the AskUser class
from older versions of sbt. In fact, there is an AskUserTask which is
very similar. It uses jline to read input from the terminal (which could
be a network terminal). When it gets a line, it submits it to the
CommandExchange and exits. Once the next command is run (which may or
may not be the command it submitted), the ui state will be reset.
The debug, info, warn and error commands should work with the multi
client ui. When run, they set the log level globally, not just for the
client that set the level.
2019-12-18 19:24:32 +01:00
|
|
|
if (!s.contains("systemOut")) println(s)
|
2020-05-12 09:00:44 +02:00
|
|
|
s contains "\"result\":\"notification result\""
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-10-21 04:33:02 +02:00
|
|
|
}
|