[
https://issues.apache.org/jira/browse/SOLR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854690#action_12854690
]
Frank Wesemann commented on SOLR-141:
-------------------------------------
{quote}
1) more smarts in SolrCore.getErrorResponseWriter to be able to deal with the
possibility that the ResponseWriter is also an ErrorResponseWriter - that way
people wouldn't have to register a dual purpose impl twice
{quote}
wouldn't it be sufficient to extend the interface QueryResponseWriter with a
writeError(Writer, HttpServletResponse, SolrResponse, SolrRequest) Method?
The DispatchFilter may set the last caught exception on SolrResponse and call
it in the sendError() method.
The ResponseWriter impl may than do something like:
{code}
public void writeError(Writer out, HttpServletResponse res, SolrResponse
solrRes, SolrRequest solrReq) {
Throwable th = solrRes.getException();
res.setStatus(code);
res.setContentType( getContentType() );
myTextResponseWriterImpl.writeInt( code );
myTextResponseWriterImpl.writeStr( th.getMessage );
if ( ! th instanceof QueryResponseWritingExecption ) {
try {
myTextResponseWriterImpl.writeResponse();
} catch ( Exception e) {
myTextResonseWriterIml.writeStr("an additionalError in writing the
result occured: " + e.getMessage() );
}
}
//... do what else you need to.
}
{code}
> 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: 1.5
>
> Attachments: 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.
