Ken Krugler wrote:
If you are running a single webapp, you can just put the jsp files in
there. I'm guessing that isn't what you mean though.
Well, ultimately we're heading towards a single webapp with multiple
embedded Solr cores. In that case, could the .jsp-based GUI/admin
functionality peacefully co-exist with our use of the embedded cores?
yes, this is how the multi-core support in trunk works.
There are a bunch of admin request handlers that do many of the things
from the /admin/ jsp files without the nice interface. The one major
missing component was analysis.jsp, but grant just added:
https://issues.apache.org/jira/browse/SOLR-477
Is there a description of the roadmap for the Solr GUI? For example, I'm
assuming the .jsp files will still exist going forward, but will become
much more of just a GUI layer on top of the new/beefed up admin request
handlers - yes?
Or is the plan to eventually get to just Javascript on HTML using JSON
responses from these request handlers?
No formal description -- my hope is to remove as much scriptlet code as
possible and make the jsp a simple GUI layer. I briefly thought
changing most admin pages to handler+xslt was a good idea. But the
flexibility to use jsp is nice.
ryan
Thanks,
-- Ken
Ken Krugler wrote:
Hi all,
We're moving towards embedding multiple Solr cores, versus using
multiple Solr webapps, as a way of simplifying our build/deploy and
also getting more control over the startup/update process.
But I'd hate to lose that handy GUI for inspecting the schema and
(most importantly) trying out queries with explain turned on.
Has anybody tried this dual-mode method of operation? Thoughts on
whether it's workable, and what the issues would be?
I've taken a quick look at the .jsp and supporting Java code, and
have some ideas on what would be needed, but I'm hoping there's an
easy(er) approach than just whacking at the admin support code.
Thanks,
-- Ken
