>>>>> On Tue, 24 Jul 2012 11:06:04 -0700, Blake Sullivan said:
B> Is this just for completeness, or are customers actually seeing this?
B> If customers are seeing this, then whether we want to do this, depends
B> on whether we think that their use case is valid. If the uses cases are
B> valid (and these kinds of use cases often are), then the appropriate
B> thing to do would be to use a CopyOnWriteArrayList as the implementation
B> (even though we don't need the thread safety) and document the behavior
B> as vaguely as we desire. The only question is whether we would
B> guarantee that a listener added or removed would not be called during
B> the current event delivery (which is what using a CopyOnWriteArrayList
B> would give us) or whether we would want to be less definite and say that
B> the listener might be called. That decision comes down to whether our
B> desire for implementation flexibility outweighs the pain-in-the-ass
B> factor of the listener author needing to deal with the case where the
B> listener may be called.
>>>>> On Wed, 25 Jul 2012 17:59:52 +0200, Frank Caputo said:
FC> the CopyOnWriteArrayList solution sounds nice. I can imagine use
FC> cases where I add new listeners from another event listener for
FC> later use, though I never did so.
Blake, this would just be for completeness. Our implementation team
lead, Manfred Riem, filed JAVASERVERFACES-2053 [1] and this is the spec
counterpart.
M jsf-api/src/main/java/javax/faces/application/Application.java
- Add this text to
public void subscribeToEvent(java.lang.Class<? extends SystemEvent> systemEventClass,
java.lang.Class<?> sourceClass,
SystemEventListener listener)
It is valid to call this method during the processing of an event
which was subscribed to by a previous call to this method.
- In all other variants of subscribeToEvent() and
unsubscribeFromEvent(), refer to the preceding text.
[1]
http://java.net/jira/browse/JAVASERVERFACES-2053
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/