[
https://issues.apache.org/jira/browse/SOLR-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13083897#comment-13083897
]
Chris Male commented on SOLR-2708:
----------------------------------
Hi,
As suggested in SOLR-2446, I think a good first step is to provide an
abstraction for DocumentObjectBinder (DOB) so people can provide their own
implementations. We can then look further into how DOB works.
{quote}
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.
{quote}
I've bumped into this problem many times myself. Much like with JPA
annotations though, the SolrJ annotations convey some metadata about the bean
properties (especially if we expand the annotations supported). So for me
ideally it'd be great to be able to have those annotations still in, without
needing the full solrj dependency. Thats probably something we can look into
longer term.
{quote}
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.)
{quote}
Would simply making the API extensible by moving some of the logic to template
methods, be sufficient?
{quote}
allow externalized (xml) configuration
{quote}
With the simple support for beans we have today, I feel this might be
introducing a lot of complexity for little gain. If we eventually support
composite / embedded beans, this may be useful, but then I think it would exist
as another implementation of the DOB abstraction.
{quote}
allow detecting all fields, annotated or not (off by default)
{quote}
Seems reasonable. Perhaps its worth while having an extension point where
fields are checked to see if they are properties to use.
> 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
