lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-141) Errors/Exceptions should be formated by ResponseWriter
Date Wed, 13 Oct 2010 17:57:36 GMT

    [ https://issues.apache.org/jira/browse/SOLR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920692#action_12920692
] 

Hoss Man commented on SOLR-141:
-------------------------------

Frank:

bq. wouldn't it be sufficient to extend the interface QueryResponseWriter with a writeError(Writer,
HttpServletResponse, SolrResponse, SolrRequest) Method?

1) that would break back compat for anyone who already had QueryResponseWriter impl (unfortunately
it's an interface not an abstract class).
2) we don't want to introduce direct dependencies on javax.servlet.* into the core solr code
(ie: QueryResponseWriter) ... only the org.apache.solr.servlet code in Solr should have those
dependencies.

Rich:

bq. If Solr is a JEE webapp, why not just have SolrServlet use HttpServletResponse.sendError(int,
String) 

SolrServlet has been deprecated for quite some time, it's error handling is attrocious, but
was been left that way for back compat (at this point we should just remove it)

The issue here is SolrDispatchFilter which already does use HttpServletResponse.sendError
... that's the entire problem, and the goal of this issue is to change that.  By using sendError
we give hte servlet container the authority of formatting hte response, but that undermines
the users ability to select the format using the "wt" param.  SolrDispatchFilter needs to
take responsibility for formatting the response document directly in order to ensure we can
always give the user the response in the format they want.


> Errors/Exceptions should be formated by ResponseWriter
> ------------------------------------------------------
>
>                 Key: SOLR-141
>                 URL: https://issues.apache.org/jira/browse/SOLR-141
>             Project: Solr
>          Issue Type: Wish
>            Reporter: Hoss Man
>             Fix For: Next
>
>         Attachments: SOLR-141-sendError.patch, solr-exception-writer-solr-1.2.diff, solr-exception-writer-v2.diff,
solr-exception-writer-v3.diff
>
>
> Whenever possible, the Solr Dispatcher should to let the ResponseWriter format Exceptions
using the format the user expects -- this should in no way change the fact that Exceptions
currently generate non 200 HTTP status codes, nor should it prevent the Dispatcher from using
the exception message as the HTTP status message -- but clients that want the full details
of the error should be able to parse them in the format they expected based on the request.
> this would also give RequestHandlers the oportunity to return "partial" results - by
adding both whatever results they have to the Response as well as the Exception they encountered.
> situations where this can't happen are obviously:
>   * Exception thrown by ResponseWriter
>   * Exception thrown so early in the request thta the DIspather doesn't know which ResposneWriter
the client wanted.
> ...in those cases, plain text is a wise choice.
> thing that would probably need to be done to make this work:
> 1) if the Dispatcher catches an exception, it should call SolrQueryResponse.setException,
set the HTTP status code/message as it currently does, but then hand off to the ResponseWriter.
> 2) Dispatcher needs to check SolrQueryResponse.getException and set the HTTP status code/message
just like if it caught the exception itself.
> 3) all of the ResponseWriters should start looking at SolrQueryResponse.getException
if they aren't already, and formatting it in a usefull way.
> 4) if the ResponseWriter throws an exception, Dispatcher needs to return a nice plain
text error page
> extension to this idea... add a new method to ResponseWriter to generate a generic error
message in the appropriate format that Dispatcher can use if the ResponseWriter throws an
exception (as a backup before resorting to plain text)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message