: /update and /update/ could go to two different places. I'm not sure
: why web.xml has update mapped to /update/*
why would /update and /update/ be treated differently? dispatch filter
will take them both and give them to XmlUpdateRequestHandler because it
does prefix matching right?
nope, it is a map lookup, so it needs to be an exact match or it moves on.
http://localhost:8983/solr/update/csv 400 missing contentStream
http://localhost:8983/solr/update/csv/ 405 from the update servlet
I don't like prefix check because it leads you to things like:
/update/asgdasgda works just fine
We should strip trailing '/' from anything that gets registered and
when you pull stuff out of the registry, that would fix this problem.
I will file a JIRA issue for that.
i don't think we should do this: 1) it changes things under the covers for
existing users; 2) people are probably going to use one URL structure or
ok. alternativly,
perhaps we should add something to solrconfig that would achieve the
same thing, this way the example solrconfig.xml could get people used
to having an error code when errors occur.
I can't stress enough how important this is for new people and people
writing clients - it is so easy to have errors go unnoticed when they
have a 200 response.
: All of these are useful to people getting started with solr and
: helpful debugging tools. I've convinced a bunch of people to use solr
I personally don't think we need to wait on any new functionality -- this
release will already be fairly significant given what's already been
commited (and that it's post incubation so all of hte release steps need
to be re-sanity checked).
If its a question of *need*, i agree - I was answering what i would
*like* to see.
: The one thing i can think of is that it would be nice to solidify the
: "handler" package as the place that request handlers go. How do you
: feel about deprecating o.a.s.request.StandardRequestHandler and moving
: it to o.a.s.handler.StandardRequestHandler -- same for
: DisMaxRequestHandler
adding some package.html files clarifying what *should* be in each package
definitely makes sense ... moving the existing request handlers is
definitely a lower priority (especially since even if we move them, we'll
need the placeholder subclasses for people currently subclassing them)
agreed, but if we hope to move them eventually, why not start the ball
rolling? If your fine with skipping the placeholder subclass in the
future and making people update their code, there is no need to do it
now. I just thought we should put the warning out now.
ryan
