concerning the "seenOuterMostDocIterator", Is it the case that there can be only one DocList in the update request?
My reading of JavaBinUpdateRequestCodec is yes, there is only one list. the marshal method takes in an updateRequest, and then writes all the documents in that updateRequest as a single Iterator to the output stream using a custom javaBinCodec that treats the doclist special – but it doesn't change anything about any other iteratros or iterables that may be field values in the DocList, so JavaBinCodec.marshal happily writes then out successfully.
I'll i've done is update JavaBinUpdateRequestCodec.unmarshal so it only applies it's special logic to this one special top-level iterator – and will now delegate to JavaBinCodec.unmarshal for any other Iterators or Iterables.
Even if the same InputStream/OutputStream is reused for multiple updateRequest objects using multiple marshal/unmarshal calls (something i don't think is supported in the calling code, the "seenOuterMostDocIterator" is an instance variable inside the unmarshal method, so it will be reset for each call.
Hoss , the fix is good. Treating all collections as type ARR instead of just collection.
Moreover we do not need to support Iterable.
I'm confused – it seems like you are in favor of my patch, but you also say we do not need to support Iterable ... Iterable (and Iterator) are already supported by the marshalling method w/o any errors or warnings, i didn't add that, all i did was make sure Iterable (and Iterator) would be supported on the unmarshalling side as well.
If it was never intended for the JavaBinCodec to support Iterator/Iterable except in the special case "streaming" situations like what JavaBinUpdateRequestCodec does then that's fine, but in that case we should change JavaBinCodec so it errors during marshalling – the client shouldn't be able to successfully serialize some data if the server is then going to complain that it's an incorrect format.