<br><br><div class="gmail_quote">On Wed, May 27, 2009 at 3:34 PM, Gavin King <span dir="ltr"><<a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
well,<br>
<br>
(1) an Observer could be registered multiple times with diff event bindings<br>
</blockquote><div><br>Ah, I thought it couldn't, because BeanManager.addObserver took no binding information. I now see that Event.addOberver() uses the bindings of the event itself. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(2) adding a type variable doesn't help you, since it just gets erased<br>
at runtime </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
You can't do T.class in Java :-)<br>
<div><div></div><div class="h5"></div></div></blockquote><div><br>Good point. Is the parameterization of addObserver just to ensure that Observer<T> is registered for Class<T>?<br><br>So if an observer can be added for an event with different bindings, why shouldn't it be possible to remove it from observing the event with a specific binding? I presume that's what Event.resumeObserver() does, i.e. removes that observer for the Event's bindings. It seems reasonable to want to do that independent of whether you have an event, through the BeanManager.<br>
<br>-Clint<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="h5"><br>
On Wed, May 27, 2009 at 1:06 PM, Clint Popetz <<a href="mailto:cpopetz@gmail.com">cpopetz@gmail.com</a>> wrote:<br>
> Now that I'm thinking about it, I wrote "the observer should be removed for<br>
> all events for which it is registered" but because addObserver() is typed to<br>
> Observer<T>, and because you can't implement the same interface twice (even<br>
> with different parameterizations) any given instance can only be registered<br>
> once. Well, it could be registered more than once, but the implementation<br>
> (and possibly the spec) could prohibit that, because it's meaningless.<br>
><br>
> In that case, I have no problem with the semantics of removeObserver. But<br>
> the <?> means I'd have to rewrite a lot of observer storage/lookup code, and<br>
> it's not symmetric with addObserver(), so I wonder what the advantage of the<br>
> wildcard is.<br>
><br>
> -Clint<br>
><br>
><br>
> On Wed, May 27, 2009 at 2:35 PM, Gavin King <<a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a>> wrote:<br>
>><br>
>> yes, that's what it means, though I must admit that when I made that<br>
>> change it was not totally clear to me that it was the right thing to<br>
>> do :-/<br>
>><br>
>> Probably needs a bit more discussion...<br>
>><br>
>> On Wed, May 27, 2009 at 11:59 AM, Clint Popetz <<a href="mailto:cpopetz@gmail.com">cpopetz@gmail.com</a>> wrote:<br>
>> > Hi,<br>
>> ><br>
>> > The spec defines BeanManager.removeObserver to have a wildcard type:<br>
>> ><br>
>> > public void removeObserver(Observer<?> observer);<br>
>> ><br>
>> > and says "The container must stop sending event notifications to the<br>
>> > deregistered observer." Does that sentence, taken with the wildcard<br>
>> > type,<br>
>> > imply that the observer should be removed for all events for which it is<br>
>> > registered? Currently ManagerImpl implements storage of observers as a<br>
>> > map<br>
>> > from EventType -> Observer, which means removal of an observer without<br>
>> > knowing its event type would be linear in # observers, unless I change<br>
>> > the<br>
>> > implementation.<br>
>> ><br>
>> > Thanks,<br>
>> > -Clint<br>
>> ><br>
>> ><br>
>> > --<br>
>> > Clint Popetz<br>
>> > <a href="http://42lines.net" target="_blank">http://42lines.net</a><br>
>> > Scalable Web Application Development<br>
>> ><br>
>> > _______________________________________________<br>
>> > webbeans-dev mailing list<br>
>> > <a href="mailto:webbeans-dev@lists.jboss.org">webbeans-dev@lists.jboss.org</a><br>
>> > <a href="https://lists.jboss.org/mailman/listinfo/webbeans-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/webbeans-dev</a><br>
>> ><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Gavin King<br>
>> <a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a><br>
>> <a href="http://in.relation.to/Bloggers/Gavin" target="_blank">http://in.relation.to/Bloggers/Gavin</a><br>
>> <a href="http://hibernate.org" target="_blank">http://hibernate.org</a><br>
>> <a href="http://seamframework.org" target="_blank">http://seamframework.org</a><br>
><br>
><br>
><br>
> --<br>
> Clint Popetz<br>
> <a href="http://42lines.net" target="_blank">http://42lines.net</a><br>
> Scalable Web Application Development<br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<div><div></div><div class="h5">Gavin King<br>
<a href="mailto:gavin.king@gmail.com">gavin.king@gmail.com</a><br>
<a href="http://in.relation.to/Bloggers/Gavin" target="_blank">http://in.relation.to/Bloggers/Gavin</a><br>
<a href="http://hibernate.org" target="_blank">http://hibernate.org</a><br>
<a href="http://seamframework.org" target="_blank">http://seamframework.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Clint Popetz<br><a href="http://42lines.net">http://42lines.net</a><br>Scalable Web Application Development<br>