[
https://issues.apache.org/jira/browse/SOLR-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17719696#comment-17719696
]
Shawn Heisey commented on SOLR-7871:
------------------------------------
What I am intending is to put almost all of bin/solr into a java program that
also includes functionality from SolrCLI. That Java program will then fork off
processes using the java executable for start, stop, and anything else that
needs it. Last time I went looking, I couldn't find "chdir" in Java, but that
was back when Java 8 was new. I want to avoid multiple switches between
scripts and Java, and I definitely don't want to bring in another language.
I am still bikeshedding about the jar name to use for the new program. Right
now it's "solrcli.jar". I have some ideas, and I am open to suggestions.
I have a new shell script that finds Java, makes sure it works, and runs the
new jar, sending all the command-line options to it. That script is pretty
much complete, now I am working on the Java program. The script exports
JAVA_HOME and JAVA_BIN at the moment, but it might be better to have it set
sysprops instead. I think for the Windows script, powershell is probably a
better choice than cmd.
At the moment the Java program implements the "start" and "zk" subcommands, but
those subcommands are not yet complete. I'm putting more work into the zk
subcommand than start because zk is fairly complex. I've got quite a lot of
work left, and I am collecting questions to ask the picocli project. At this
time, I just plan to re-implement the existing command structure. Down the
road we can think about changing it if we find a better way.
I also need to find way for the new program and Solr to communicate – some kind
of cross-platform IPC. A very simplistic idea that might actually work is to
have Solr communicate with the control program via its exit code. I need to do
some testing to decide whether the exit code is enough or whether it needs
something more sophisticated and/or bidirectional.
I like the idea of bin/solr-example.
Ultimately I would also like to embed jetty so we run solr.jar instead of
jetty's stock start.jar, but that's a whole independent project.
Do we want to convert fully to systemd? I think we can make the service more
robust if we do. It does mean dropping support for some operating systems,
particularly older versions. I don't have a good sense about whether there are
any widely used modern systems that are still using sysvinit.
> Platform independent config file instead of solr.in.sh and solr.in.cmd
> ----------------------------------------------------------------------
>
> Key: SOLR-7871
> URL: https://issues.apache.org/jira/browse/SOLR-7871
> Project: Solr
> Issue Type: Improvement
> Components: scripts and tools
> Affects Versions: 5.2.1
> Reporter: Jan Høydahl
> Priority: Major
> Labels: bin/solr
> Attachments: SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch,
> SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch,
> SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch,
> SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch, SOLR-7871.patch
>
>
> Spinoff from SOLR-7043
> The config files {{solr.in.sh}} and {{solr.in.cmd}} are currently executable
> batch files, but all they do is to set environment variables for the start
> scripts on the format {{key=value}}
> Suggest to instead have one central platform independent config file e.g.
> {{bin/solr.yml}} or {{bin/solrstart.properties}} which is parsed by
> {{SolrCLI.java}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
