You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Chris Hostetter <ho...@fucit.org> on 2007/12/11 08:04:41 UTC
multicore and admin pages?
I notice this in the MultiCore wiki...
>> To access the admin pages for each core visit:
>> http://localhost:8983/solr/admin/?core=core0
>> http://localhost:8983/solr/admin/?core=core1
...trying this out using the example multicore setup didn't seem to work
(the admin screen said core0 even for the second URL) -- but in general
i'm curious if there's a specific desire for the admin pages to work with
URLs like this (the core name as a URL param) instead of the having the
core in the path like for the rest of the URLs?
Sure the admin pages are (mostly) JSPs, but before the Dispatcher forwards
the request/response up the chain, it could pull the core name out of the
path and include it as a request attribute right?
-Hoss
Re: multicore and admin pages?
Posted by Ryan McKinley <ry...@gmail.com>.
I just committed a simple fix for the admin pages (rev 603269)
?core=core1 will work for /admin pages, but not for handleres.
Assuming we go with the route saying "if multi-core support is
avaliable, all requests must include the core name" It would make sense
to have:
http://localhost:8983/solr/core0/admin/analysis.jsp
http://localhost:8983/solr/core1/admin/analysis.jsp
we should be able to do that by stripping the core from the request path
and calling:
req.getRequestDispatcher( path ).forward( request, response );
---
I don't quite follow Stu's comment "so that there is the possibility of
querying multiple cores simultaneously." I'm missing what you gain. An
logical operations on the multiple cores can be done in RequestHandlers
- they should not be done in the request dispatcher. If you want to
query multiple cores, use a custom RequestHandler that can access any
core.
ryan
Henrib wrote:
>
> To be honest, I am not a big fan of the '/@corename' syntax ; I feel the
> '?core=corename' syntax carries less surprise and may be extended more
> easily (Stu's comment in solr-350).
> I've uploaded a small patch to solr-350 (solr-350.patch) so the core as a
> request parameter works again (& passes the core as a request attribute
> after it has been resolved).
>
>
>
> hossman wrote:
>>
>> I notice this in the MultiCore wiki...
>>
>>>> To access the admin pages for each core visit:
>>>> http://localhost:8983/solr/admin/?core=core0
>>>> http://localhost:8983/solr/admin/?core=core1
>> ...trying this out using the example multicore setup didn't seem to work
>> (the admin screen said core0 even for the second URL) -- but in general
>> i'm curious if there's a specific desire for the admin pages to work with
>> URLs like this (the core name as a URL param) instead of the having the
>> core in the path like for the rest of the URLs?
>>
>> Sure the admin pages are (mostly) JSPs, but before the Dispatcher forwards
>> the request/response up the chain, it could pull the core name out of the
>> path and include it as a request attribute right?
>>
>>
>>
>>
>> -Hoss
>>
>>
>>
>
Re: multicore and admin pages?
Posted by Ryan McKinley <ry...@gmail.com>.
The @ is used to say "the next thing is a core name"
If we require a the core name for every request (when MultiCore is
enabled) then this would go away.
I get the feeling this is the best way to go.
ryan
Noble Paul ??????? ?????? wrote:
> I cannot see the value add of the /@<corename? over /<corename>
> And '@' is not a friendly URL character
> --Noble
>
> On Dec 11, 2007 8:05 PM, Ryan McKinley <ry...@gmail.com> wrote:
>> Henrib wrote:
>>> To be honest, I am not a big fan of the '/@corename' syntax ; I feel the
>>> '?core=corename' syntax carries less surprise and may be extended more
>>> easily (Stu's comment in solr-350).
>>> I've uploaded a small patch to solr-350 (solr-350.patch) so the core as a
>>> request parameter works again (& passes the core as a request attribute
>>> after it has been resolved).
>>>
>> There are two problems with ?core=xxx
>>
>> 1. For some requests (multipart?), calling req.getReqeustParameter(
>> "core" ) mucks up the whole request
>>
>> 2. Philosophically, there is something off about having different paths
>> available based on a request parameter. Consider core0 with a handler
>> registered at /path but core1 does not:
>>
>> http://host/path?core=core0 [200 OK]
>> http://host/path?core=core1 [404 Not Found]
>>
>>
>> ryan
>>
>
>
>
Re: multicore and admin pages?
Posted by Noble Paul നോബിള് नोब्ळ् <no...@gmail.com>.
I cannot see the value add of the /@<corename? over /<corename>
And '@' is not a friendly URL character
--Noble
On Dec 11, 2007 8:05 PM, Ryan McKinley <ry...@gmail.com> wrote:
> Henrib wrote:
> >
> > To be honest, I am not a big fan of the '/@corename' syntax ; I feel the
> > '?core=corename' syntax carries less surprise and may be extended more
> > easily (Stu's comment in solr-350).
> > I've uploaded a small patch to solr-350 (solr-350.patch) so the core as a
> > request parameter works again (& passes the core as a request attribute
> > after it has been resolved).
> >
>
> There are two problems with ?core=xxx
>
> 1. For some requests (multipart?), calling req.getReqeustParameter(
> "core" ) mucks up the whole request
>
> 2. Philosophically, there is something off about having different paths
> available based on a request parameter. Consider core0 with a handler
> registered at /path but core1 does not:
>
> http://host/path?core=core0 [200 OK]
> http://host/path?core=core1 [404 Not Found]
>
>
> ryan
>
--
--Noble Paul
Re: multicore and admin pages?
Posted by Ryan McKinley <ry...@gmail.com>.
Henrib wrote:
>
> To be honest, I am not a big fan of the '/@corename' syntax ; I feel the
> '?core=corename' syntax carries less surprise and may be extended more
> easily (Stu's comment in solr-350).
> I've uploaded a small patch to solr-350 (solr-350.patch) so the core as a
> request parameter works again (& passes the core as a request attribute
> after it has been resolved).
>
There are two problems with ?core=xxx
1. For some requests (multipart?), calling req.getReqeustParameter(
"core" ) mucks up the whole request
2. Philosophically, there is something off about having different paths
available based on a request parameter. Consider core0 with a handler
registered at /path but core1 does not:
http://host/path?core=core0 [200 OK]
http://host/path?core=core1 [404 Not Found]
ryan
Re: multicore and admin pages?
Posted by Henrib <hb...@gmail.com>.
To be honest, I am not a big fan of the '/@corename' syntax ; I feel the
'?core=corename' syntax carries less surprise and may be extended more
easily (Stu's comment in solr-350).
I've uploaded a small patch to solr-350 (solr-350.patch) so the core as a
request parameter works again (& passes the core as a request attribute
after it has been resolved).
hossman wrote:
>
>
> I notice this in the MultiCore wiki...
>
>>> To access the admin pages for each core visit:
>>> http://localhost:8983/solr/admin/?core=core0
>>> http://localhost:8983/solr/admin/?core=core1
>
> ...trying this out using the example multicore setup didn't seem to work
> (the admin screen said core0 even for the second URL) -- but in general
> i'm curious if there's a specific desire for the admin pages to work with
> URLs like this (the core name as a URL param) instead of the having the
> core in the path like for the rest of the URLs?
>
> Sure the admin pages are (mostly) JSPs, but before the Dispatcher forwards
> the request/response up the chain, it could pull the core name out of the
> path and include it as a request attribute right?
>
>
>
>
> -Hoss
>
>
>
--
View this message in context: http://www.nabble.com/multicore-and-admin-pages--tp14268867p14275004.html
Sent from the Solr - Dev mailing list archive at Nabble.com.