lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Updated] (SOLR-3628) SolrDocument uses user-provided collections unsafely
Date Sat, 08 Sep 2012 00:19:07 GMT


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:
>             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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message