You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2007/02/05 06:47:05 UTC
[jira] Created: (SOLR-141) Errors/Exceptions should be formated by
ResponseWriter
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
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.
[jira] Updated: (SOLR-141) Errors/Exceptions should be formated by
ResponseWriter
Posted by "Daniel Naber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Naber updated SOLR-141:
------------------------------
Attachment: solr-exception-writer-v3.diff
New version with two differences: includes an example in solrconfig.xml (commented out); sets the http status code according to the exception or 500 if it's not a SolrException.
> 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
> 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.
[jira] Updated: (SOLR-141) Errors/Exceptions should be formated by
ResponseWriter
Posted by "Daniel Naber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Naber updated SOLR-141:
------------------------------
Attachment: (was: solr-exception-writer.diff)
> 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
> Attachments: solr-exception-writer-solr-1.2.diff, solr-exception-writer-v2.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.
[jira] Commented: (SOLR-141) Errors/Exceptions should be formated
by ResponseWriter
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689572#action_12689572 ]
Hoss Man commented on SOLR-141:
-------------------------------
Jogged by an email today, i took a quick glance at this patch and wanted to post some brief notes for anyone who might be interested.
on the whole this looks good, the few things that seem to be missing to me are...
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
2) giving the ErrorResponseWRiter's access to the SolrQueryResponse in case they want to try and output "partial" results along with the error message
3) the RepestDispatcher should still be using the status code from the Exception -- or at the very least asking the ErrorResponseWriter which status code to use.
4) i don't see the Content-Type getting specified anywhere
5) test cases.
> 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
> 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.
[jira] Commented: (SOLR-141) Errors/Exceptions should be formated
by ResponseWriter
Posted by "Daniel Naber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532967 ]
Daniel Naber commented on SOLR-141:
-----------------------------------
I've attached a patch that adds an ErrorResponseWriter, similar to QueryResponseWriter. The default behaviour is unmodified, i.e. the error is returned with an http error code and text. It's now possible, however, to configure the new XMLErrorResponseWriter so that the error is returned as an XML page (http code 200, the original error code is in the XML).
I didn't modify SolrServlet because it's deprecated anyway. There's a FIXME because the XML doesn't contain the stacktrace yet.
The patch against 1.2 is attached just in case someone might find it useful (SolrServlet is modified in this version).
> 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
> Attachments: solr-exception-writer-solr-1.2.diff, solr-exception-writer.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.
[jira] Updated: (SOLR-141) Errors/Exceptions should be formated by
ResponseWriter
Posted by "Daniel Naber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Naber updated SOLR-141:
------------------------------
Attachment: solr-exception-writer-v2.diff
same as before, but now also shows stacktrace
> 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
> Attachments: solr-exception-writer-solr-1.2.diff, solr-exception-writer-v2.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.
[jira] Updated: (SOLR-141) Errors/Exceptions should be formated by
ResponseWriter
Posted by "Daniel Naber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Naber updated SOLR-141:
------------------------------
Attachment: solr-exception-writer-solr-1.2.diff
almost the same patch but for Solr 1.2.0, just for reference
> 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
> Attachments: solr-exception-writer-solr-1.2.diff, solr-exception-writer.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.
[jira] Updated: (SOLR-141) Errors/Exceptions should be formated by
ResponseWriter
Posted by "Shalin Shekhar Mangar (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shalin Shekhar Mangar updated SOLR-141:
---------------------------------------
Fix Version/s: 1.5
> 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.
[jira] Updated: (SOLR-141) Errors/Exceptions should be formated by
ResponseWriter
Posted by "Daniel Naber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Naber updated SOLR-141:
------------------------------
Attachment: solr-exception-writer.diff
> 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
> Attachments: solr-exception-writer.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.