[JIRA] (GLAZEDLISTS-484) CompositeList.addMemberList doesn't handle reentrancy

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[JIRA] (GLAZEDLISTS-484) CompositeList.addMemberList doesn't handle reentrancy

JIRA jira-no-reply@java.net

    [ https://java.net/jira/browse/GLAZEDLISTS-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=393411#comment-393411 ]

Tuupertunut commented on GLAZEDLISTS-484:

I just recently stumbled upon this bug. Thought I would share my test case for this. It is a runnable Java class and displays a pretty simple use case where this occurs.

When a CollectionList's getChildren method returns a CompositeList, the CompositeList will always be empty for every new parent element to the CollectionList.


> CompositeList.addMemberList doesn't handle reentrancy
> -----------------------------------------------------
>                 Key: GLAZEDLISTS-484
>                 URL: https://java.net/jira/browse/GLAZEDLISTS-484
>             Project: glazedlists
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 0.9.1
>         Environment: Operating System: All
> Platform: All
>            Reporter: trumpetinc
>            Assignee: jessewilson
>             Fix For: milestone 1
>         Attachments: CompositeListTest.java
> If addMemberList is called on CompositeList as part of a list event response,
> the change to the CompositeList is dropped.
> Demonstrating this issue involves a fairly complex list pipeline.  I've prepared
> a unit test that demonstrates the issue.
> As near as I can tell, the dropped event occurs because of two things in
> SequenceDependenciesEventPublisher.fireEvent():
> 1.  the loop that checks for subjects (the first for loop in the method) does
> not find any entries for the addMemberList event (maybe a listener isn't getting
> registered properly??)
> 2.  reentrantFireEventCount is equal to 2 during the addMemberList event
> handler, so processing delegates to the stack (but because of #1, nothing gets
> added for the stack to handle)

This message was sent by Atlassian JIRA