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