[
https://issues.apache.org/jira/browse/SOLR-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3628:
---------------------------
Fix Version/s: 4.0
I seem to recall more then a few discussions in the past about how "defensive"
APIs like this should be with respect to user provided collections and arrays
-- the trade off being GC overhead (if the client code and the solrj code both
make defensive copies, we've doubled the number of shot lived objects)
Either way: before 4.0 we should either commit this patch, or significantly
improve the docs for SolrInputDocument and SolrInputField to make it clear that
no copying is done and the code may modify the underlying Objects addded as
fields
> SolrDocument uses user-provided collections unsafely
> ----------------------------------------------------
>
> Key: SOLR-3628
> URL: https://issues.apache.org/jira/browse/SOLR-3628
> Project: Solr
> Issue Type: Bug
> Components: clients - java
> Affects Versions: 3.6, 4.0-ALPHA
> Environment: Mac OS X 10.7.4, Java 6
> Reporter: Tom Switzer
> Fix For: 4.0
>
> Attachments: solrdoc-ro-list-bug.patch
>
>
> Adding a RO Collection as the value of a field (ie. SolrDocument or
> SolrInputField) will result in an UnsupportedOperationException later on when
> adding more values to that field.
> This happens because no defensive copy of collections are made. Instead, if a
> collection is given first, then it becomes the backing collection for the
> field. This can cause problems if the collection is modified after the fact
> or if a read-only collection is given (eg. Collection.unmodifiableList(...)).
> It can be reproduced with:
> SolrDocument doc = new SolrDocument()
> doc.addField("v", Collections.unmodifiableList(new ArrayList<Object>()))
> doc.addField("v", "a")
> I've created a patch that includes a fix and a test with, essentially, the
> above. The patch just ensures that SolrDocument and SolrInputField always use
> a Collection they created as the value, rather than relying on what was given
> to them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
