[jira] [Updated] (SOLR-3628) SolrDocument uses user-provided collections unsafely

["Hoss Man (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man updated SOLR-3628:
---------------------------

    Assignee: Hoss Man

bq. Perhaps a less contentious solution would be to make addValue/addField ALWAYS defensively copy collections, but keep the current setValue/setField behaviour. If I am setting a value to a collection, then I can see how a defensive copy may not be done. However, if I am "adding" a collection, it would seem I am appending the value to an already existing set

That sounds like a good approach ... assigning to myself to remind me to do a more thorough review of your patch and try to get this into 4.0
                
> 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: 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org