I should clarify that I realize that the same Observer<T> will observe events for all event types represented by T.  But it's still the same instance, which we register once, and which the new BeanManager implementation will store multiple times in the Type -> EventObserver map, once for each type represented by T.

-Clint

On Wed, May 27, 2009 at 3:06 PM, Clint Popetz <cpopetz@gmail.com> wrote:
Now that I'm thinking about it, I wrote "the observer should be removed for all events for which it is registered" but because addObserver() is typed to Observer<T>, and because you can't implement the same interface twice (even with different parameterizations) any given instance can only be registered once.   Well, it could be registered more than once, but the implementation (and possibly the spec) could prohibit that, because it's meaningless.

In that case, I have no problem with the semantics of removeObserver.  But the <?> means I'd have to rewrite a lot of observer storage/lookup code, and it's not symmetric with addObserver(), so I wonder what the advantage of the wildcard is.

-Clint



On Wed, May 27, 2009 at 2:35 PM, Gavin King <gavin.king@gmail.com> wrote:
yes, that's what it means, though I must admit that when I made that
change it was not totally clear to me that it was the right thing to
do :-/

Probably needs a bit more discussion...

On Wed, May 27, 2009 at 11:59 AM, Clint Popetz <cpopetz@gmail.com> wrote:
> Hi,
>
> The spec defines BeanManager.removeObserver to have a wildcard type:
>
> public void removeObserver(Observer<?> observer);
>
> and says "The container must stop sending event notifications to the
> deregistered observer."  Does that sentence, taken with the wildcard type,
> imply that the observer should be removed for all events for which it is
> registered?  Currently ManagerImpl implements storage of observers as a map
> from EventType -> Observer, which means removal of an observer without
> knowing its event type would be linear in # observers, unless I change the
> implementation.
>
> Thanks,
> -Clint
>
>
> --
> Clint Popetz
> http://42lines.net
> Scalable Web Application Development
>
> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev
>
>



--
Gavin King
gavin.king@gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org



--
Clint Popetz
http://42lines.net
Scalable Web Application Development



--
Clint Popetz
http://42lines.net
Scalable Web Application Development