jsreport/jsreport-dotnet#18

user was reporting (via email) that he started jsreport's windows service using:

node server install –-httpPort=4998

and server started on 4998 normally, but after a reboot the server was not using that port (i guess jsreport used the default port 5488). this is due to not preserving the original instance configuration when creating the windows service (we should check that custom args are preserved too).

i see two solutions for this:

• before creating the windows service, initialize a jsreport instance and read the configuration in there, then pass those configuration values as ENV vars to the windows service (also ensuring that custom args are being recognized by nssm), that will ensure that when restarting the service the initial configuration will be applied.

• pass new --config path/to/current-config arg to windows service (also ensuring that custom args are being recognized by nssm)

i prefer the first one because it ensures all exact configuration is applied (because it will have all config parsed by nconf)

using:

nssm set [serviceName] AppStdout \path\to\service.out.log
nssm set [serviceName] AppStderr \path\to\service.err.log

can be a nice feature when testing.

The socket files are currently stored in the home directory of the current user.
Unfortunately IIS default user has no access to its home directory so the jsreport exe doesn't work there.

There needs to be at least a configurable way to store the sockets somewhere else, perhaps in temp directory.

before node 8.8.0, child processes (detached) on windows generated a new cmd window, this was annoying for background tasks. so for our case we had to build silent-spawn to support older versions. in jsreport v2 is likely that we just use windowsHide instead of silent-spawn, we just need to test that windowsHide works normally.

The output of the jsreport init is crucial when analyzing the reason of failing jsreport render --keepAlive

right now the error contains a lot of information coming from the stack trace which makes reading the message very difficult. we should have a better error formatter that clean up stack trace.

example of a current error message:

https://user-images.githubusercontent.com/26387399/38352160-ef028394-38ba-11e8-96cb-64c316d28efa.png

Currently we open and close web server every time render command is called.
This slows the things down. We should start web server only if required by keepAlive.

When installing globally via npm install jsreport-cli -g I get the following warnings:

npm WARN deprecated [email protected]: Use uuid module instead
npm WARN deprecated [email protected]: ReDoS vulnerability parsing Set-Cookie https://nodesecurity.io/advisories/130

Not really a huge issue, but it states that the event loop can block for a long periods of time under certain regular expressions in tough-cookie, and node-uuid is deprecated.

Especially the license key, the background process crashes and no info is provided.

some ideas taken from internal discussion about future improvements of jsreport help config

• jsreport help config [subsection of config] -> prints only relevant schema for the subsection

• what do to do when the generated schema output is too long? one idea is to just save the output in one file so user can read it normally in some editor without limitations of command line window

The current unit tests takes too much time, it is too disturbing to run them during the development.
Also the windows service tests doesn't work on my local.

It would be probably better to have two collections of tests. One light and fast which we run on local and one heavy which can run only in the CI.

if multiple jsreport render --keepAlive ... are being done at the same time and the background process is not initialized then just one of calls will complete the other will fail with error ..seems like there is already a server running in port 5488. when the background process is initialized all calls will just complete normally, the problem is only visible when the background process is not initialized and multiple calls are being done.

we see two solutions for this:

• implement some kind of lock
• add retry when the command fails because specific error about port used

the second one looks more easy to do

I would like enable some features of debug extension in render command. This is normally done using options prop in request. However it seems render command doesn't parse it.

c:\Users\janbl\...>jsreport render --template.content=test.html --template.recipe=phantom-pdf --template.engine=none --options.debug.logsToResponse=true --out=out.html
render command error:
Unknown argument: options
type jsreport render -h to get help about usage and available options

I would like that the caller is able to read somewhere the response meta which we normally send through http headers like logs, numberOfPages, contentType....

Proposed format is like this:
jsreport render .... --out-meta=meta.json

However we need to think this through before implementing it....