Create server launcher to replace mcserver #2
Comments
|
I think this may be 2 separate issues.
For the daemon, Apache Commons Daemon might be a good choice. It appears widely used, small overhead, with cross-platform capability and native integrations for both Windows and *nix. For the setup, jpackage appears to be officially supported from OpenJDK 16. While it appears rudimentary, it does have native support for Windows and *nix. |
We could look into using the distributions backend used by SDKMAN to choose a JVM. |
I think those are actually 3 issues.
I intended for this issue to only cover the first of those 3.
Personally, I'd prefer good documentation over trying to do too much. I.e., in the setup guide: Down the road if we want to include a separate tool to assist with acquiring a java runtime, I think that's a separate feature request. In the near term, using SDKMAN itself could be one of the suggestions in the help article. |
|
@tonygermano can you explain why you'd want/need a wrapper to run in the foreground? and why that should be different than the daemon launcher? i look at the engine as something that should only be ran as a service - os, docker, whatever. and running in the foreground is simply a feature used for troubleshooting.
can you elaborate on this? i assumed this meant an installer. |
|
@ssrowe I'm using mirth lingo here as it exists in 4.5.2. Mirth has always offered two ways to start the server, In modern systems, I am proposing that for this issue we only recreate Docker shouldn't use a daemon process because you typically would not want to launch a background process inside the container that you need to manage. If you want to stop the server, you should just need to stop the container and not need to mess around inside of it. To further that point, the NextGen docker containers run Systemd only requires a .service unit file to create a service on Linux systems. This has already been shown to work with |
|
@tonygermano i think we’re saying essentially the same thing. The “double-click” thing threw me off. i agree we only need a server component that runs in the foreground and that is ran from the CLI interactively or from systemd, docker, or similar. Essentially a bootstrapper. while Windows is more unique, there appears to be some differences between other platforms as well. with a very simple interface, we can leverage the Apache Commons Daemon (don’t let the name confuse things). It’s simple a set of platform native binaries that give us more control over class loading and config than a shell scripts which diff between platforms. It does have some overlap with systemd, that we can simply ignore. this appears to be battle-tested code that would allow us to simplify things. Thoughts? |
|
I made a crack parsing vmoptions in bash in #101 which I expect might apply for *nix platforms. I'm of the opinion that any non-trivial server app should be running in a container, these days, but assuming the bash version is acceptable I'm happy to produce a windows equivalent that runs as an NT Service. Systemd, too. Beyond whether the quick-and-dirty vmoptions support is sufficient, I'd need clarification re:
|
@mgaffigan I have already created a clojure program that does what I intended when I opened this issue, but I do not like how it needs to be deployed and run. See #61 I was thinking about rewriting it in Go as that should not be difficult to do, and it should then more easily compile to platform native executables. My priorities needed to shift elsewhere before I could get around to doing that, and we are using install4j in the near-term to be able to get a release out for people to be able to install and test the application. An alternative that I considered was rather than having a tool that launched java as a child process, it could just generate and return the full command to start java with the appropriate args after processing the vmoptions files. Then the output could be executed by a shell or used to create a service. One of the things I really like that I added, and which is not supported by install4j, is the The other things I implemented with environment variable substitution, recursive includes, and classpath manipulation are all described here https://www.ej-technologies.com/resources/install4j/help/doc/concepts/vmParameters.html
The only thing that must be on the classpath at this time is
It was moved to |
|
Thanks for the clarification, @tonygermano. Here's my understanding to confirm:
From this, bash seems sufficient for Linux/Mac/Docker. I translated the Clojure to Python for my own sake, but was able to minimally edit the bash script I put together previously to meet the above requirements. I was able to simplify things a bit by execl-ing into the new process, rather than creating a subprocess. Windows requires something dedicated given the NT Service interaction. If you are using Install4J for the windows installer, I would presume that would also be used for the NT Service. If you want to avoid Install4J for windows, then Wix + a small C# program would be easiest. Thoughts? |
|
Thinking a bit further on this, is anyone running production servers on Mac OS? I understand using servers running on Mac OS for development and test - but is start-at-boot actually a requirement when OS X Server is out-of-support for at least three years? Theoretical deployment story::
In all cases, the client would be installed by the platform's typical means. Working through the use cases:
With super users having the escape hatch of compiling from source easily, or from doing something magic off of tgz artifacts. The above does presuppose that we can merge in-tree a client launcher, but I think all of this would be pretty clean: clean build pipeline, clean deployment story without signing secrets, and most importantly a clean onboarding for a mirth naïve user. While this would be a departure from the historical deployment pattern, I think the changes to deliver this would be relatively achievable:
|
This script is the main launcher for the Open Integration Engine (OIE)
server. It prepares the Java environment and executes the server launcher
JAR file.
The script automatically finds a compatible Java runtime (version 17+ by
default) by searching for a valid executable in the following priority order:
1. The OIE_JAVA_PATH environment variable.
2. The -java-cmd directive in the oieserver.vmoptions file or included
.vmoptions files. Must specify the path to the 'java' executable.
This is the preferred way to declare the desired version for running
the server and can be overridden by OIE_JAVA_PATH. Can be a relative
path from the location of this script.
3. The JAVA_HOME environment variable.
4. The 'java' command available in the system's PATH.
It also parses the 'oieserver.vmoptions' file to configure JVM options,
system properties (-D...), and classpath modifications.
Signed-off-by: Tony Germano <tony@germano.name>
Co-authored-by: Mitch Gaffigan <mitch.gaffigan@comcast.net>
Issue: OpenIntegrationEngine#2
This script is the main launcher for the Open Integration Engine (OIE)
server. It prepares the Java environment and executes the server launcher
JAR file.
The script automatically finds a compatible Java runtime (version 17+ by
default) by searching for a valid executable in the following priority order:
1. The OIE_JAVA_PATH environment variable.
2. The -java-cmd directive in the oieserver.vmoptions file or included
.vmoptions files. Must specify the path to the 'java' executable.
This is the preferred way to declare the desired version for running
the server and can be overridden by OIE_JAVA_PATH. Can be a relative
path from the location of this script.
3. The JAVA_HOME environment variable.
4. The 'java' command available in the system's PATH.
It also parses the 'oieserver.vmoptions' file to configure JVM options,
system properties (-D...), and classpath modifications.
Signed-off-by: Tony Germano <tony@germano.name>
Co-authored-by: Mitch Gaffigan <mitch.gaffigan@comcast.net>
Issue: OpenIntegrationEngine#2
Uh oh!
There was an error while loading. Please reload this page.
mcserver was created by install4j, and the configuration was not open source. I don't believe that a replacement for mcservice is required, as each platform has a preferred way to run a service, and they should all work with a simple launcher.
needs:
nice-to-haves:
Platform support (check as completed):
The text was updated successfully, but these errors were encountered: