re: Related subjects, listeners and lists with out-of-pipeline dependencies

Following up on this.  I *think* that the crux of the problem was a mis-understanding of how to properly specify dependencies using setRelatedListener.

 

I've done some instrumentation of SequenceDependenciesListEventPublisher, and I'm beginning to gain some visibility into what's going on - I'll post again after I get my head around it.  I think that this may be an area that could use a big explanation in either the Javadocs or the Wiki.

 

It would be very, very useful to be able to instrument the event publisher without having to hack into it's source code like I'm doing now.  If anyone has any thoughts on how best to approach that, I'd love to hear them.  From my work so far, the most important thing is gaining read-only access to the subjectsAndListeners list.  I realize that this is highly implementation specific, so maybe the sort of instrumentation I'm looking for would be an instrumentable interface specific to each publisher?

 

For example, we could have the following public interface:

 

public interface InstrumentedSequenceDependenciesListEventPublisher{

    SequenceDependenciesListEventPublisherInstrumentation getInstrumentation();

}

 

and

 

public class SequenceDependenciesListEventPublisher{

    ... implementation specific methods ...

    List<SubjectAndListenerPair> getSubjectsAndListenersList(){...}

}

 

 

This would allow the publisher to not expose the instrumentation in it's interface, but we could cast the publisher to obtain the instrumentation method, if desired.

 

Thoughts?

 

- K

 

I think that my knowedlge of the GL event publisher has finally hit a wall.

 

We have a list pipeline/graph that has the following 3 players:

 

List 'source'

 

List 'child' - FunctionList(source)

 

List 'parent' - FunctionList(source, new Function(child))

 

So we have direct dependancy between source and both child and parent lists.  But there's the additional dependency introduced by the fact that the Function for list Parent is also dependant on source.  It seems like the update mechanism needs to ensure the following ordering:  source, child, parent.  But we often find updated occuring as: source, parent, child

 

 

 

Is the setRelatedListener method the correct way to solve this?  So far, all attempts at blindly using combinations of setRelatedListener have not been successful (I am still very uncertain on exactly what setRelatedListener and Subject do...  I understand what a listener is, but what's a subject?  The thing being listened to?)  If I'm thinking about it correctly, what I need to say is that the 'parent' listener is dependent on subject 'child', so I'd think that the following call would suffice:

 

publisher.setRelatedListener(parent, child)

 

To paraphrase the javadoc, this would make it so "Child's dependencies are satisfied before Parent is notified"

 

but when I specify this, I get an exception on the next source list mutation:

 

java.lang.UnsupportedOperationException
 at ca.odell.glazedlists.event.SequenceDependenciesEventPublisher$NoOpEventFormat.fire(SequenceDependenciesEventPublisher.java:406)
 at ca.odell.glazedlists.event.SequenceDependenciesEventPublisher$SubjectAndListener.firePendingEvent(SequenceDependenciesEventPublisher.java:445)
 at ca.odell.glazedlists.event.SequenceDependenciesEventPublisher.fireEvent(SequenceDependenciesEventPublisher.java:344)
 at ca.odell.glazedlists.event.ListEventAssembler.commitEvent(ListEventAssembler.java:316)
 at ca.odell.glazedlists.BasicEventList.add(BasicEventList.java:140)

I'm attaching a test case that creates the exception (see results from testItRelatedListnerA2B).  Note that in this test case, the event ordering just happens to work correctly, so it's not good at showing the original dependency issue (although testItRelatedListnerB2A does show the problem that results if events are fired out of order).

 

 

If anyone can point out what I might be doing wrong, I'd really appreciate it.

 

 

 

Thanks in advance,

 

- Kevin

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...