[
https://issues.apache.org/jira/browse/SOLR-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083957#comment-13083957
]
Bozhidar Bozhanov commented on SOLR-2708:
-----------------------------------------
Yes, making the API extensible would be sufficient.
As for the xml and the "all fields" option - both of them can be implemented as
extensions (when the API becomes extensible). Solrj can provide the "all
fields" extension, and omit the xml one - if someone needs it, it will be
trivial to write.
> Allow customizable bean mapping for QueryResponse.getBeans(..)
> --------------------------------------------------------------
>
> Key: SOLR-2708
> URL: https://issues.apache.org/jira/browse/SOLR-2708
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
> Affects Versions: 1.4, 3.1
> Reporter: Bozhidar Bozhanov
>
> The mechanism for getting beans is rather limited - only classes
> @Field-annotated fields.
> Imaging the following subprojects:
> - common
> - search
> And you want to reuse a class from common as a result from a solr search. You
> should either duplicate the structure or make common depend on solrj. Neither
> are desirable.
> So, my suggestion:
> - introduce a pluggable mechanism for bean resolution. Currently it is
> impossible - it uses private methods and private inner classes. (This will be
> useful for custom conversions, because the existing one fails in some cases
> where BeanUtils.copyProperties works.)
> - allow externalized (xml) configuration
> - allow detecting all fields, annotated or not (off by default)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
