[
https://issues.apache.org/jira/browse/SOLR-5287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13821358#comment-13821358
]
Erick Erickson commented on SOLR-5287:
--------------------------------------
I tried running with a transient core and that works just fine. It works for
the same reason this code doesn't work if, say, schema.xml isn't well formed.
Part of getting to this handler is getting the core, which will load a
transient core but will fail if, say, the schema.xml is malformed. If the core
doesn't load, we never get a chance to replace the bad configs since the
exception is thrown before we get here.
You do get a long ugly stack trace back from the cURL command though, telling
you things like "Caused by: org.xml.sax.SAXParseException; systemId:
solrres:/schema.xml; lineNumber: 245; columnNumber: 4; The element type
"schema" must be terminated by the matching end-tag "</schema>"."
I'm not going to try to do anything about this, at least for the first cut. I'm
just going to document it. I'm envisioning this functionality as an easy way to
make tweaks. You can recover from _some_ problems, for instance declaring a
default field in solrconfig.xml that doesn't exist.
I don't see any intrinsic reason why it would be impossible to make this
functionality work even when the configs were totally messed up, but that would
require duplicating the logic in the core's classLoader/resourceLoader and
that's a place I don't want to go right now. Also, if we go to ZK being "the
one source of truth" I think the problem changes.
On to trying to make this work with ZK.
> Allow at least solrconfig.xml and schema.xml to be edited via the admin screen
> ------------------------------------------------------------------------------
>
> Key: SOLR-5287
> URL: https://issues.apache.org/jira/browse/SOLR-5287
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis, web gui
> Affects Versions: 4.5, 5.0
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Attachments: SOLR-5287.patch
>
>
> A user asking a question on the Solr list got me to thinking about editing
> the main config files from the Solr admin screen. I chatted briefly with
> [~steffkes] about the mechanics of this on the browser side, he doesn't see a
> problem on that end. His comment is there's no end point that'll write the
> file back.
> Am I missing something here or is this actually not a hard problem? I see a
> couple of issues off the bat, neither of which seem troublesome.
> 1> file permissions. I'd imagine lots of installations will get file
> permission exceptions if Solr tries to write the file out. Well, do a
> chmod/chown.
> 2> screwing up the system maliciously or not. I don't think this is an issue,
> this would be part of the admin handler after all.
> Does anyone have objections to the idea? And how does this fit into the work
> that [[email protected]] has been doing?
> I can imagine this extending to SolrCloud with a "push this to ZK" option or
> something like that, perhaps not in V1 unless it's easy.....
> Of course any pointers gratefully received. Especially ones that start with
> "Don't waste your effort, it'll never work (or be accepted)"...
> Because what scares me is this seems like such an easy thing to do that would
> be a significant ease-of-use improvement, so there _has_ to be something I'm
> missing.
> So if we go forward with this we'll make this the umbrella JIRA, the two
> immediate sub-JIRAs that spring to mind will be the UI work and the endpoints
> for the UI work to use.
> I think there are only two end-points here
> 1> list all the files in the conf (or arbitrary from <solr_home>/collection)
> directory.
> 2> write this text to this file
> Possibly later we could add "clone the configs from coreX to coreY".
> BTW, I've assigned this to myself so I don't lose it, but if anyone wants to
> take it over it won't hurt my feelings a bit....
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
