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
