search

moqui / moqui-framework

Use Moqui Framework to build enterprise applications based on Java. It includes tools for databases (relational, graph, document), local and web services, web and other UI with screens and forms, security, file/resource access, scripts, templates, l10n, caching, logging, search, rules, workflow, multi-instance, and integration.
http://www.moqui.org
Other
279 stars 200 forks source link

elasticSearch/openSearch startup code in MoquiStart should be removed #570

Open eigood opened 1 year ago

eigood commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 https://github.com/moqui/moqui-framework/issues/570#issuecomment-1426531799, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA4YMNU4NE3OHCSRV2H5MCLWW3MYVANCNFSM6AAAAAAUYKTF64 . You are receiving this because you authored the thread.Message ID: @.***>