[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795346#action_12795346
]
Chris A. Mattmann edited comment on SOLR-1602 at 12/30/09 4:34 PM:
-------------------------------------------------------------------
Hi Ryan:
Thanks.
bq. Sounds fine... except for the back compatibility issues - especially for
people upgrading with the same solrconfig.xml
There are 8 response writers defined by default in solrconfig.xml. That doesn't
seem too unwieldy a job for find/replace as far as configuration upgrades for
someone moving from SOLR x.y to SOLR 1.5.
As for code, yes, unfortunately users will have to recompile their response
writers and update a few package names/imports per response writer which they'd
probably want/have to do anyways on an upgrade regardless.
bq. When we moved all the handlers to a new package o.a.solr.handler, it left a
bunch of deprecated calsses in o.a.solr.request.
You could certainly do this, and I've done it before in other projects. The
tradeoff is, what type of message from the Java compiler do you want to notify
you as a consumer of the SOLR java classes:
# A deprecation (that could easily get swallowed if someone compiles with
deprecation notifications off)
# A compiler error, forcing the user to perform the small amount of legwork to
update package refs
I'm a fan of number 2, and I'd venture to guess the work wouldn't be too bad in
this case since most of the ReponseWriters aren't friendly to user extension or
sub-classing.
bq. Also, if we make a 'response' package, seems SolrQueryResponse.java should
go there.
Agreed, the patch I attached should move it there.
was (Author: chrismattmann):
Hi Ryan:
Thanks.
bq. Sounds fine... except for the back compatibility issues - especially for
people upgrading with the same solrconfig.xml
There are 8 response writers defined by default in solrconfig.xml. That doesn't
seem too unwieldy a job for find/replace as far as configuration upgrades for
someone moving from SOLR x.y to SOLR 1.5.
As for code, yes, unfortunately users will have to recompile their response
writers and update a few package names/imports per response writer which they'd
probably want/have to do anyways on an upgrade regardless.
bq. When we moved all the handlers to a new package o.a.solr.handler, it left a
bunch of deprecated calsses in o.a.solr.request.
You could certainly do this, and I've done it before in other projects. The
tradeoff is, what type of message from the Java compiler do you want to notify
you as a consumer of the SOLR java classes:
# A deprecation (that could easily get swallowed if someone compiles with
deprecation notifications off
# A compiler error, forcing the user to perform the small amount of legwork to
update package refs
I'm a fan of number 2, and I'd venture to guess the work wouldn't be too bad in
this case since most of the ReponseWriters aren't friendly to user extension or
sub-classing.
bq. Also, if we make a 'response' package, seems SolrQueryResponse.java should
go there.
Agreed, the patch I attached should move it there.
> Refactor SOLR package structure to include o.a.solr.response and move
> QueryResponseWriters in there
> ---------------------------------------------------------------------------------------------------
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
> Issue Type: Improvement
> Components: Response Writers
> Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
> Reporter: Chris A. Mattmann
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt,
> SOLR-1602.Mattmann.112509_02.patch.txt
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are
> curiously located in the o.a.solr.request package. Not only is this package
> getting big (30+ classes), a lot of them are misplaced. There should be a
> first-class o.a.solr.response package, and the response related classes
> should be given a home there. Patch forthcoming.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
