[
https://issues.apache.org/jira/browse/SOLR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467787
]
Ryan McKinley commented on SOLR-104:
------------------------------------
Ok, I just uploaded (hopefully) a final version. It takes care of (most)
everything you suggest.
> - SolrUpdateServlet used HttpServletRequest.getReader, the new
> UpdateRequestHandler uses an InputStreamReader arround
> HttpServletRequest.getInputStream() ... this seems bad for legacy
> update support from a char encoding standpoint.
Can you check: XmlUpdateRequestHandler.handleRequestBody();
I added a check for charset, but am not totally confident in the method.
> - StandardRequestParser can't assume that a POST which isn't
> multipart/* should be handled by a RawRequestParser ... if the
> content type is "application/x-www-form-urlencoded" then
> SimpleRequestParser should be used (so all params from query string
> and body are included)
done.
> - What should the expectations of
> ContentStream.getInputStream().close() be? Should the Dispatcher
> iterate over any Iterable streams when writing the output and try
> to close them, ignoring any Exceptions?
Each handler is responsible to make sure they are closed. Since it is an
Iterable<ContentStream> - I don't think it is OK to iterate a *second* time.
If we make it a Collection<> then that would be a reasonable behavior.
>
> Things in the current patch that aren't strictly neccessary
> for the current issue and can (should?) be commited seperately...
>
> - are we definitely deprecating SolrQueryResponse.getException ?
I took it out. we can commit it separately.
> - StandardRequestHandler and DisMaxRequestHandler have only been
> changed to subclass the new base class.
I left it in. You can ignore changes to StandardRequestHandler and DisMax if
that makes more sense.
> - doFilter should call parsers.parse( path, req ) as soon as it has
> the path, and then delegate to a helper method that doesn't have
> access to the HttpServletRequest ... this reduces both the
> complexity of the method, and the likelyhood of
> someone inadvertently introducing an error (mangling the POST body)
> when making future changes in the long deep method.
> The one thing to watch out for is forcing POST in legacy
> update. (assuming legacy update stays in the Filter)
I removed the legacy handling from SolrDispatchFilter - this simplifies it
greatly, so i'm not sure if you still think this is necessary.
> - it's not clear to me why the interface for SolrRequestParser is...
> public SolrParams parseParamsAndFillStreams(
> final HttpServletRequest, ArrayList<ContentStream>)
> ...instead of just...
> public SolrQueryRequest(final HttpServletRequest)
> ...with the param parsing loops in
> SolrRequestParsers.buildRequestFrom
> in static utility methods (in case a RequestParser doesn't want to
> support STREAM_URL or STREAM_BODY)
>
I left it as is for now. Since it is a private interface, we should feel free
to clean it up / change it as we see fit. But now I go to sleep!
> Update Plugins
> --------------
>
> Key: SOLR-104
> URL: https://issues.apache.org/jira/browse/SOLR-104
> Project: Solr
> Issue Type: Improvement
> Components: update
> Affects Versions: 1.2
> Reporter: Ryan McKinley
> Fix For: 1.2
>
> Attachments: commons-fileupload-20070107.jar, commons-io-1.2.jar,
> DispatchFilter.patch, DispatchFilter.patch, DispatchFilter.patch,
> DispatchFilter.patch, DispatchFilter.patch, DispatchFilter.patch,
> DispatchFilter.patch, HandlerRefactoring-DRAFT-SRC.zip,
> HandlerRefactoring-DRAFT-SRC.zip, HandlerRefactoring.DRAFT.patch,
> HandlerRefactoring.DRAFT.patch, HandlerRefactoring.DRAFT.zip
>
>
> The plugin framework should work for 'update' actions in addition to 'search'
> actions.
> For more discussion on this, see:
> http://www.nabble.com/Re%3A-Handling-disparate-data-sources-in-Solr-tf2918621.html#a8305828
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
