[
https://issues.apache.org/jira/browse/SOLR-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15244514#comment-15244514
]
Shawn Heisey edited comment on SOLR-9000 at 4/17/16 3:09 AM:
-------------------------------------------------------------
TL;DR warning. Sorry, couldn't get my mind to shut up.
If the old admin UI works with an alternate context path, then it must be
possible for the javascript to figure out what the path should be ... but I
suspect that it will require special work (java system property set from an
environment variable probably) to make the bin/solr script aware of the context
path passed to Jetty.
While I understand the desire to make things as flexible as possible, each bit
that is easily configurable is another variable that must be tracked and
handled in multiple places, and another potential source of bugs.
I think it is prudent to keep using /solr as the first part of all URL paths,
no matter what happens with future efforts to pull the networking layer into
Solr. SOLR-8029 changes the landscape a bit, but until that becomes a feature
in released code, we must decide whether we want Solr to work with a
user-defined context path. I do not think we should try to support that.
was (Author: elyograg):
TL;DR warning. Sorry, couldn't get my mind to shut up.
If the old admin UI works with an alternate context path, then it must be
possible for the javascript to figure out what the path should be ... but I
suspect that it will require special work (java system property set from an
environment variable probably) to make the bin/solr script aware of the context
path passed to Jetty.
While I understand the desire to make things as flexible as possible, each bit
that is easily configurable is another variable that must be tracked and
handled in multiple places, and another potential source of bugs.
A tangent on the possibility of dropping /solr entirely:
I think it is prudent to keep using /solr as the first part of all URL paths,
no matter what happens with future efforts to pull the networking layer into
Solr. SOLR-8029 changes the landscape a bit, but until that becomes a feature
in released code, we must decide whether we want Solr to work with a
user-defined context path. I do not think we should try to support that.
> New Admin UI hardcodes /solr context and fails when it changes
> --------------------------------------------------------------
>
> Key: SOLR-9000
> URL: https://issues.apache.org/jira/browse/SOLR-9000
> Project: Solr
> Issue Type: Bug
> Components: UI
> Affects Versions: 6.0
> Reporter: Alexandre Rafalovitch
> Attachments: solr-wrong-urls-screenshot.png
>
>
> If the solr context is changed from */solr* to any other value (e.g.
> */solr6_0/instance/solr1*), the new Admin UI does not work as it still tries
> to load resources from */solr* prefix:
> The context is changed by editing server/contexts/solr-jetty-context.xml:
> bq. <Set name="contextPath"><Property name="hostContext"
> default="/solr6_0/instance/solr1"/></Set>
> and by changing redirect in the server/etc/jetty.xml
> {quote}
> <New class="org.eclipse.jetty.rewrite.handler.RedirectRegexRule">
> <Set name="regex">^/$</Set>
> <Set name="replacement">/solr6_0/instance/solr1/</Set>
> </New>
> {quote}
> This affects New Admin UI, as well as both links between the UIs.
> The old Admin UI seems to work with the changed context, once it is manually
> loaded.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
