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

[Kevin Day]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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@...

[Kevin Day]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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

 

----------------------- Original Message -----------------------

  

From: Kevin Day kevin@...

To: Glazed Lists users@...

Cc: 

Date: Thu, 21 May 2009 13:24:45 -0700

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

  

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@...

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

[Holger Brands]

Hey Kevin,

>[snip]
> 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"

I'd say, your interpretation is correct. I'd have tried the same...

>
> 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)
> [snip]
> If anyone can point out what I might be doing wrong, I'd really
> appreciate it.

I guess the problem in your case is, that "child" (the second parameter
to method setRelatedListener(...)) is not only a pure ListEventListener, but
also a producer of ListEvents.
(The current usages of setRelatedListener in the GL code base only
deal with pure listeners as second parameter.)
So this appears to be a shortcoming of the current implementation in GL,
rather than a mistake on your side.

Jesse, James please correct me if I'm wrong...;-)

Holger
____________________________________________________________
Text: GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de


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

[Kevin Day]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Holger-

 

Thanks for the response.  As I dig deeper, I think that I'm actually OK - I just need to bring myself to a point where I really, really understand how the event publisher manages depedencies.  Instrumenting the publisher and obtaining the actual ordered dependency list has been extremely instructive for this.

 

I will post again once I truly get my head around it (probably with a patch that allows instrumentation of the publisher without it impacting the API - hopefully it will be accepted, as it makes this sort of thing much, much easier to understand).

 

 

In the current case, I believe that the reason the exception was being thrown is that I was adding an 'additional' dependency for a subject that wasn't already in the dependency list.

 

I basically made the following mistake:

 

For the following:

 

ListA -> ListB -> ListC -> ListD

 

 

My additional dependency is, strictly speaking, on ListC.  But I made the assumption that if ListB's dependencies were all met, then that implied that ListC was fully refreshed.  As my instrumentation (finally) showed me, this is very much not the case (I was thinking about list refreshes instead of listener dependencies).

 

I still don't have it completely nailed down, but the next time I post, I should have a good enough picture of what's going on to where we can really pick things apart.

 

Thanks,

 

- K

 

 

----------------------- Original Message -----------------------

  

From: Holger Brands hbrands@...

To: users@...

Cc: 

Date: Sun, 24 May 2009 18:33:29 +0200

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

  

Hey Kevin,

>[snip]
> 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"

I'd say, your interpretation is correct. I'd have tried the same...

>
> 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)
> [snip]
> If anyone can point out what I might be doing wrong, I'd really
> appreciate it.

I guess the problem in your case is, tha t "child" (the second parameter
to method setRelatedListener(...)) is not only a pure ListEventListener, but
also a producer of ListEvents.
(The current usages of setRelatedListener in the GL code base only
deal with pure listeners as second parameter.)
So this appears to be a shortcoming of the current implementation in GL,
rather than a mistake on your side.

Jesse, James please correct me if I'm wrong...;-)

Holger
____________________________________________________________
Text: GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de


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

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