[
https://issues.apache.org/jira/browse/SOLR-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3628:
---------------------------
Attachment: SOLR-3628.patch
updated patch to include a test that the field really is backed by the
collection (since we now explicitly document it)
will commit a soon as full test run finishes
> 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
> Assignee: Hoss Man
> Fix For: 4.0
>
> Attachments: SOLR-3628.patch, solrdoc-ro-list-bug-comp.patch,
> 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
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]