[jdom-interest] JDOM 2 list of elements, remove nulls out entries and fails to remove?

[Rolf Lear]

Please send the code.... put a comment in it where you think the failure 
is..... Under no condition should JDOM return a null value...

Rolf

On 11/05/2012 9:45 PM, David Wall wrote:
> Thanks, Rolf. No, it's definitely not a threading issue. If you saw my
> second posting, it all works as expected if I create my own
> LinkedList<Element> from the list returned by getChildren().
>
> If you think it's still a possible issue, I can attached the actual
> source code and the sample XML data I was parsing. I'm not familiar with
> JDOM's internals, but if I remove one Element, does that cause a shift
> for all subsequent elements? I ask this because I am actually creating
> two lists, one is the main object, and the second is an associated
> "version" object (the main object can have multiple versions associated
> with it). In the XML, they are ordered like OBJ, OBJVERSION, OBJ,
> OBJVERSION, OBJ, OBJVERSION.
>
> When I created to the two lists (one of OBJ and the other of
> OBJVERSION), I noted that as soon as I deleted the OBJ from the first
> list, the second list already showed a 'null' element at the end of its
> list. It made me think that the elements are shifting in the live lists
> from JDOM and thus I'm no longer working on the originally retrieved lists.
>
> So, if that's all it is and my usage scenario was bogus before, I'm good
> since I've changed to create my own lists now. But if you think it could
> still be an issue, I'm happy to send the code and XML to you (it's open
> source code anyway).
>
> Thanks,
> David
>
>
> On 5/11/2012 6:14 PM, Rolf Lear wrote:
>> Hi David.
>>
>> This problem you describe is very concerning, and should not, in
>> 'supported' usage ever happen....
>>
>> I am wracking my brains to figure out what it could be, but, the only
>> think I can think is that you are accessing the JDOM objects from
>> different threads.... JDOM is *not* thread safe.
>>
>> If this is happening in a single-threaded mechanism, would it be
>> possible to put together a failing 'test case', any code that shows
>> the problem?
>>
>> I have to admit that I thought he iteration/remove/add/etc. type code
>> is very well tested, and I would be *very* suprised if there is a
>> problem like this.... in fact, I know that there are test cases that
>> cover this basic condition that you describe... and they never fail....
>>
>> so, if you can confirm this is all happening in one thread.... and
>> preferably if you can put together an example of the problem, I would
>> look in to it immediately....
>>
>> Rolf
>>
>> On 11/05/2012 8:42 PM, David Wall wrote:
>>> I believe I've run into a problem that I don't think I had with JDOM
>>> 1.1.3 before I upgraded to 2.0.1.
>>>
>>> I create a list of elements of a selected element using:
>>>
>>> List<?> documentVersionElements =
>>> rootElement.getChildren("DocumentVersion", ns);
>>>
>>> I see that I have 6 elements as expected in my list. None are null.
>>>
>>> I am basically then trying to find a matching related element id in
>>> that list using something like:
>>>
>>> Element found = null;
>>> ListIterator<?> iter = documentVersionElements .listIterator();
>>> while( iter.hasNext() ) {
>>> Element checkElement = (Element)iter.next();
>>> EsfUUID evParentId = new
>>> EsfUUID(checkElement.getChildText("documentId", ns));
>>> if ( evParentId.equals(id) ) {
>>> found = checkElement;
>>> break;
>>> }
>>> }
>>>
>>> Then, assuming I find it (found != null), I process it as expected.
>>> But I then want to remove the found element from the element list so
>>> it cannot be found again, so I use this:
>>>
>>> documentVersionElements.remove(found);
>>>
>>> Most of the time, this seems to work as expected, and the
>>> documentVersionElements list is then shorter by 1. But there are
>>> times when a list of 6 elements remains 6 elements after the remove
>>> (and remove() returns false), with 4 of them now null (not removed,
>>> but actually a null element), so in when I return to the
>>> listIterator() above and get my next() element, the element is null.
>>>
>>> It's as if my Element objects are not unique in the list in terms of
>>> equals/hashCode as my elements should never be nulled out.
>>>
>>> I am not sure why an element I find by iterating cannot then be
>>> removed. How could it fail to remove? Why would it change other list
>>> elements to NULL instead? Is this not a valid usage pattern?
>>>
>>> Thanks,
>>> David
>>> _______________________________________________
>>> To control your jdom-interest membership:
>>> http://www.jdom.org/mailman/options/jdom-interest/youraddr@yourhost.com
>>>
>>
>