On Mar 24, 2008, at 8:50 PM, Erik Hatcher wrote:
On Mar 24, 2008, at 6:23 PM, Chris Hostetter wrote:
: Going to /solr/admin/stats.jsp, it was intercepting and
forwarding to
: /admin/stats.jsp which is a 404. _info.jsp can leverage a
default core in a
: multicore configuration and let the old (non-core prefixed)
paths work fine,
: but the forwarding wasn't taking into account /solr being mapped
via web.xml
: rather than a webapps/solr.war application root context.
Hmmm... I see, yeah this makes sense - the crux of the issue being
that it
really doesn't make sense for pathPrefix to work as currently
advertised
-- whatever prefix the filter is mapped to really needs to be
theparent of the "admin" directory in case it has to forward
(either that or
we need a seperate init-param to tell the filter where to forward
requests to)
Your comment about the parent of the admin directory doesn't make
sense to me, sorry. The path-prefix could be "/whatever". /app/
whatever/coreName/admin/stats.jsp would be fit this case and work
just fine, forwarding to /whatever/admin/stats.jsp as expected
(within the app context).
Nevermind.... I understand what you mean by the parent now quite
clearly :) And yes, if you want to nest Solr into a web-app and
mount it as /whatever, for the admin JSPs to work as you'd expect,
you'd create:
.war
whatever
admin
stats.jsp
... // The rest of admin JSPs
My one-line change was right, but explaining it was tough :)
Now if we could just refactor those darn JSPs out to pure request
handlers.....
Erik
