Return-Path: Delivered-To: apmail-lucene-solr-user-archive@locus.apache.org Received: (qmail 35172 invoked from network); 18 Feb 2008 16:14:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Feb 2008 16:14:31 -0000 Received: (qmail 10770 invoked by uid 500); 18 Feb 2008 16:14:20 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 10747 invoked by uid 500); 18 Feb 2008 16:14:20 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 10735 invoked by uid 99); 18 Feb 2008 16:14:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Feb 2008 08:14:20 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [207.5.72.226] (HELO EXHUB016-3.exch016.msoutlookonline.net) (207.5.72.226) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Feb 2008 16:13:47 +0000 Received: from [192.168.50.96] (63.200.72.123) by SMTPX16.msoutlookonline.net (207.5.72.190) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 18 Feb 2008 08:13:54 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <47B71F5A.9040801@gmail.com> References: <47B71F5A.9040801@gmail.com> Date: Mon, 18 Feb 2008 07:53:55 -0800 To: solr-user@lucene.apache.org From: Ken Krugler Subject: Re: Using embedded Solr with admin GUI Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Checked: Checked by ClamAV on apache.org >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? >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? 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 -- Ken Krugler Krugle, Inc. +1 530-210-6378 "If you can't find it, you can't fix it"