<br><br><div class="gmail_quote">On Sat, Jan 2, 2010 at 11:06 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;">
<div class="im">On Sat, Jan 2, 2010 at 1:27 PM, Matt Drees <<a href="mailto:matt.drees@gmail.com">matt.drees@gmail.com</a>> wrote:<br>
<br>
>> ++ Clarify that scope types should not have members<br>
>><br>
>> The spec should mention that @ScopeType annotations should not have<br>
>> annotation members. Perhaps this should be a definition error.<br>
>> javax.inject.Scope already mentions this.<br>
><br>
> I'm sure you meant @NormalScope.<br>
<br>
</div>Yes.<br>
<div class="im"><br>
> Can I ask what the motivation is for preventing annotation members on scope<br>
> annotations? I could imagine some custom scopes needing some extra<br>
> metadata, and the scope annotation seems like a handy place to put it.<br>
<br>
</div>Well, the thing is that our SPI provides no way for an implementation<br>
of Context to get access to the annotation members for a certain Bean.<br>
Bean.getScope() returns the Class, not the Annotation.<br></blockquote><div><br>True. <br>So, if someone needs metadata on a bean for a custom context, they'll have no choice but to require that an annotation be available from bean.getBeanClass() or bean.getStereotypes(). I think in practice people can live with this.<br>
But when they do, this restriction would require them to use 2 annotations everywhere. I predict people will complain. If we have to live with that, then we have to.<br><br>But you didn't really answer the question. Why go out of your way to prevent annotation members?<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 class="im"><br>
>> ++ Clarify that interceptors/decorators don't apply to producers in<br>
>> resolution rules<br>
>><br>
><br>
> I don't understand. 7.2 seems to explicitly state that<br>
> interceptors/decorators *do* apply to producer methods. Can you clarify?<br>
<br>
</div>They apply to the method call (but these are interceptors/decorators<br>
that belong to the bean that declares the method, not to the method<br>
itself). The object returned does not have interceptors/decorators<br>
added.<br></blockquote><div><br>Ok, thanks. Makes sense.<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 class="im"><br>
> So, I think it'd be very helpful to have a section devoted to cyclic<br>
> dependencies. Some kind of cyclic dependencies are ok while others are not,<br>
> and I think we can enumerate these.<br>
</div><div class="im">...<br>
> Is this maintenance release an appropriate time to address this question?<br>
> (I haven't yet checked how Weld handles this)<br>
<br>
</div>Propose some language :-)<br></blockquote><div><br>Ok, will work on this. Sounds like you're implying that this MR is an appropriate time for this question (provided the language works out).<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 class="im"><br>
> Also, I'm a little surprised your list didn't contain a ConversationManager<br>
> API. Is this too big of a thing for a maintenance release? It seems pretty<br>
> important to me.<br>
<br>
</div>I think it's quite big for the maintenance release, though I agree<br>
that it's important.<br>
<font color="#888888"><br>
<br>
<br>
--<br>
</font><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>