You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shawn Heisey (JIRA)" <ji...@apache.org> on 2016/04/17 05:10:25 UTC
[jira] [Comment Edited] (SOLR-9000) New Admin UI hardcodes /solr
context and fails when it changes
[ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org