elasticSearch/openSearch startup code in MoquiStart should be removed

[eigood]

Instead, it should uise the built-in ToolFactory support, so that just the existence of the component in the various runtime locations will then start up the external ES or OS daemon.

[eigood]

If the pre-baked image happened to have opensearch downloaded into it, then the only way to turn off the auto-start of it by MoquiStart would be to specify "no-run-es"; that is counter-intuitive, and the reason for this ticket.

[jonesde]

What is it that you are trying to achieve?

MoquiStart does not have any plugin mechanisms, and that would be tough since this is part of a pre app server loader that is ONLY used when moqui.war is run as an executable jar file, so it doesn't know anything about components.

All it does it look for either runtime/opensearch or runtime/elasticsearch and start them in a separate process, then stop them when the JVM terminates... unless you tell it not to with the no es parameter. This does nothing if there is not runtime/opensearch/bin directory or a runtime/elasticsearch/bin directory, and if you really must have that there but don't want MoquiStart to start it when running the WAR file as an executable JAR file, then you can use the parameter.

What is the problem, and why are you filing a bunch of issues on top of a bunch of already mostly useless issues? That makes it really difficult for me or anyone to figure out what is important, let alone actually spend limited volunteer time on important things. A better forum for collaboration or musing about ideas is the forum where there are discussions as opposed to issues that need to be tracked and managed (and submitting an issue is a request for other people to not just do something, but to track and manage doing it). Sorry for the rant, but I don't like these piling up, it's difficult enough to come even close to staying on top of things.

[eigood]

I'm filing issues in the repository that has the files with the bug(s). MoquiStart does not have a plugin mechanism, but, it loads Moqui.class, which *does*, and can use the ToolFactory as I mentioned. I initially looked at ServiceLoader, a Java platform service, before I decided to mention TF as the more moqui-centric system. TF can play better with life-cycle management of moqui. Today, I finished the alpha version of a moqui helm chart, for k8s. It uses the existing moqui/moquidemo docker hub image, attaches it to bitnami/postures and opensearch/opensearch charts. More ideas are in the pipeline, namely pre-compiling individual isolated components, to be distributed as separate OCI images. These issues I filed are not just thrown over the wall. Things are moving fast here, I can submit patches of course. Filing tickets early tho, in case someone else has already done the work, seems better. And to foster open communication. (That moqui helm chat will probably land on github mid next week).

…

On Fri, Feb 10, 2023, 6:32 PM David E. Jones ***@***.***> wrote: What is it that you are trying to achieve? MoquiStart does not have any plugin mechanisms, and that would be tough since this is part of a pre app server loader that is ONLY used when moqui.war is run as an executable jar file, so it doesn't know anything about components. All it does it look for either runtime/opensearch or runtime/elasticsearch and start them in a separate process, then stop them when the JVM terminates... unless you tell it not to with the no es parameter. This does nothing if there is not runtime/opensearch/bin directory or a runtime/elasticsearch/bin directory, and if you really must have that there but don't want MoquiStart to start it when running the WAR file as an executable JAR file, then you can use the parameter. What is the problem, and why are you filing a bunch of issues on top of a bunch of already mostly useless issues? That makes it really difficult for me or anyone to figure out what is important, let alone actually spend limited volunteer time on important things. A better forum for collaboration or musing about ideas is the forum where there are discussions as opposed to issues that need to be tracked and managed (and submitting an issue is a request for other people to not just do something, but to track and manage doing it). Sorry for the rant, but I don't like these piling up, it's difficult enough to come even close to staying on top of things. — Reply to this email directly, view it on GitHub <#570 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4YMNU4NE3OHCSRV2H5MCLWW3MYVANCNFSM6AAAAAAUYKTF64> . You are receiving this because you authored the thread.Message ID: ***@***.***>