Please excuse me if this is not the right place to ask this.
I pulled a trial download of the Ignition tool to see if this could be viable on a proprietary o/s. I am now on a timer to see if this trial analysis can work. The destination o/s supports JVM and most Posix tools. It is not Linux, but often an x86 distro of software for JVM will execute on platform.
It appears that the ignition-gateway wrapper is a binary executable. I have 2/3 questions:
0) Am I correct in my assumption that ignition-gateway is a binary executable made for Linux x86 (in my example)?
- Is this required? Is there any other way to start the ignition environment for eval/testing without executing this binary or to build a native wrapper/bootstrap to initiate the ignition tool suite?
- Has anyone ever "ported" this software to odd platforms like legacy proprietary Unix, Z-OS or other? I see other platforms described in the ignition-secrets-tool.sh script. It makes me thing that this is an option somehow.
Thanks for any thoughts on this.
The bulk of the gateway is not the executable, but Java / JAR files. The executable you see is the Java Service Wrapper component.
There's a few other binaries / native libraries, like for licensing, that would be a hurdle you probably can't clear. Maybe leased licensing would be a way around that... not sure.
Thanks. So, the bottom line here is that for a proprietary o/s that has a proprietary binary file format I cannot launch the rest of the jar files. And there is no work-around for launching them? Or no way to get source to build that initial wrapper component to make it native to the exotic o/s.
That is what it looks like to me. So I am check here to be sure. Thanks again.
In theory, you could launch directly without going through the service wrapper, if you assemble the classpath correctly and don't mind giving up all the things the wrapper gives you. And, again, bypassing the licensing and other native lib concerns for now.
What you're trying to accomplish is not something we support in any official capacity.
Whether it's possible or not, I can't say for sure, you're welcome to try. You'll have to lead the effort though.
If it helps to clarify why I am interested, this o/s does not "need" a service wrapper. The instances would be monitored by the o/s itself as part of the way the o/s works. I am not trying to be mysterious abut the o/s. Sorry about that. The o/s is HPE Nonstop. Typically, users do not use a wrapper on this o/s. They run the jar files as native o/s services. It is a different paradigm. And, in this case makes it incompatable. 