There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
When running `embark blockchain` followed by `embark run` previously, logs generated in the standalone `embark blockchain` process were black boxed and not accessible to the main Embark process.
This is fixed by creating a client IPC connection in the `embark blockchain` process that connects to the IPC server connection running in `embark run`. The connection is made by way of polling `ipc.connect` and continues polling even after a connection is made in case `embark run` is killed and restarted without restarting `embark blockchain`.
`LogHandler` was introduced to extrapolate functionality used in `ProcessLauncher` that needed to also be used in the standalone blockchain process. It also caps the number of logs that are stored in memory per process by a constant value defined in `constants.json`.
A `blockchain_listener` was module was created (and run inside of `embark run`) that listens for logs emitted by the `embark blockchain` client IPC and runs them through the `LogHandler`. Additionally, this module registers the API endpoints needed to handle requests for blockchain process logs in the cockpit (which were 404’ing before).
# Conflicts:
# lib/modules/blockchain_process/blockchain.js
*Console.js*
- Moved `DEFAULT_PROCESS` const to outside of the `Console` class (but inside the module).
- Removed `(` and `)` from `.filter` in `getProcessLogs()`.
- Updated comments
*logger.js*
- Moved `dateFormat` and `logRegex` to constants outside of `Logger` class
- Moved the `parseLogFile` method inside of the `Logger` class (ES6 style)
- Added a log limit to the `parseLogFile` method
- Added the log path to the constants file and used inside of `Logger`
*cmd_controller.js*
- Defaulted `this.context` to `[constants.context.any]` in the constructor.
- Changed `’embark’` to split modules`coreProcess` and `loggerApi`.
*engine.js*
- Changed `’embark’` to split modules`coreProcess` and `loggerApi`.
The embark log file is being overwritten each time embark is run. There is a separate log file for each context, so that running, for example, `embark run` then `embark console` doesn’t get the `run` log overwritten with the `console` log.
- Created an “embark” module so that an “embark” process could be registered in the correct way. This service is only used on `embark run` (can be extended to other commands if needed).
- extracted “embark” to a const `DEFAULT_PROCESS` param in the `Console` component.
- extracted commands result rendering to it’s own function to keep the `renderTabs` function from getting cluttered
- Added sorting of logs by timestamp
- Added milliseconds to the log file data (which helps in sorting log messages).
We've introduced a regression in 6d75a4c6c4 where running
`embark run` breaks due to webserver options not being defined.
The reason this happened is because in the mentioned commit, we're checking given
webserver options with an identity check against `null` and only set dedicated
options, if that condition is true.
E.g.:
```
if (options.runWebserver !== null) {
webServerConfig.enabled = options.runWebserver;
}
```
Unfortunately, due to one of JavaScript design flaws, this condition behaves totally
different when no identity check is done, which causes Embark to break.
Meaning that in JavaScript:
```
undefined != null // false
undefined !== null // true
```
In other words, after the mentioned commit, the condition is true, resulting
in several webserver configurations to be set to `undefined`.
This conflicts at runtime when we compose webserver configurations out of user input
and Embark's defaults here: dc5de7c1b4/lib/core/config.js (L392)
In other words, since webserver config options are already set to `undefined`,
they don't get overridden by our config algorithm.
This commit ensures that webserver config values are not set when their values
are either `null` or `undefined`.
Prior to this commit `$ embark build --contracts` spinned up a blockchain node
which is not necessary as `--contracts` can be seen as a "compile only" option.
This commit ensures we don't start any web3 services with `--contracts` is used.
This is the first step of refactoring Embark's pipeline abstraction into
dedicated plugin modules that take advantage of Embark's event system.
With this commit we're moving `Pipeline` into `lib/modules/pipeline` and
introduce a new command handler `pipeline:build`. Embark's engine now
requests builds via this command handler.
Notice that `Watch` still lives in `lib/pipeline` as this is a step-by-step
refactoring to reduce chances of introducing regressions.
Add optional --output argument to graph generator. The argument allows
to specify a filepath for graph output. Default filepath is ./diagram.svg
if the argument is not specified.
Refs: https://github.com/embark-framework/embark/issues/944
emizzle
Jonathan Rainville
Richard Ramos
Pascal Precht
Subramanian Venkatesan
hodlbank
Michael Bradley, Jr
Cryptomental
Anthony Laibe
Iuri Matias