[
https://issues.apache.org/jira/browse/SOLR-17746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17946176#comment-17946176
]
Chris M. Hostetter edited comment on SOLR-17746 at 4/21/25 6:10 PM:
--------------------------------------------------------------------
{quote}... and basically it ensures that you don't forget to provide a value
for the option ...
{quote}
Strictly speaking it checks if the value of the first character is "-"
It makes sense for things like {{--port}} but it definitely doesn't make sense
for {{--jettyconfig}} or {{--jvm-opts}}
{quote}I am putting up a PR that first cleans some docs up about --jettyconfig,
and then adds a test. Can you look at it?
{quote}
Seems fine ... except the absolute path in your test might actually exist :)
... maybe better to use something like {{./BOGUS}}
FWIW: Since you can't specify {{--jettyconfig}} or {{--jvm-opts}} more then
once on the command line (w/o them overwriting -eachother- their respective
previous usages) we should probably also be be testing that you can pass a
quoted sting containing multiple "real" options and they get parsed correctly...
{noformat}
./bin/solr ... -j "--module=foobar --include-jetty-dir=/weird"
{noformat}
(but maybe that should be it's own jira?)
was (Author: hossman):
{quote}... and basically it ensures that you don't forget to provide a value
for the option ...
{quote}
Strictly speaking it checks if the value of the first character is "-"
It makes sense for things like {{--port}} but it definitely doesn't make sense
for {{\--jettyconfig}} or {{\--jvm-opts}}
bq. I am putting up a PR that first cleans some docs up about --jettyconfig,
and then adds a test. Can you look at it?
Seems fine ... except the absolute path in your test might actually exist :)
... maybe better to use something like {{./BOGUS}}
FWIW: Since you can't specify {{\--jettyconfig}} or {{\--jvm-opts}} more then
once on the command line (w/o them overwriting eachother) we should probably
also be be testing that you can pass a quoted sting containing multiple "real"
options and they get parsed correctly...
{noformat}
./bin/solr ... -j "--module=foobar --include-jetty-dir=/weird"
{noformat}
(but maybe that should be it's own jira?)
> bin/solr always fails if you attempt to use --jettyconfig (aka "-j")
> --------------------------------------------------------------------
>
> Key: SOLR-17746
> URL: https://issues.apache.org/jira/browse/SOLR-17746
> Project: Solr
> Issue Type: Bug
> Reporter: Chris M. Hostetter
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The "-jettyconfig" optiona (aka "-j") is documented as...
> {noformat}
> -j <jettyParams> Additional parameters to pass to Jetty when starting
> Solr.
> For example, to add configuration folder that jetty
> should read
> you could pass: -j
> "--include-jetty-dir=/etc/jetty/custom/server/"
> In most cases, you should wrap the additional
> parameters in double quotes.
> {noformat}
> ..but if you actually attempt to run use that example option, you will get
> an error...
> {noformat}
> ./bin/solr start ... -j "--include-jetty-dir=/etc/jetty/custom/server/"
> ERROR: Jetty config is required when using the -j option!
> {noformat}
> IIUC this is because the bash code for parsing this option requires that it
> not start with a "{{\-}}" character; but by definition any option you want to
> pass to jetty will start with "{{\--}}".
> Attempting to workaround this problem by using two sets of quotes doesn't
> seem to work -- the inner quotes are passed verbatim to jetty which seems to
> prevent jetty from recognizing it as a valid option.
> A workaround that *does* seem to work (in my limited testing) is to include a
> leading space character _inside_ the quotes...
> {noformat}
> ./bin/solr start ... -j " --include-jetty-dir=/etc/jetty/custom/server/"
> {noformat}
> ...because for some reason that does *NOT* seem to be passed verbatim.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
