On Sat, Jan 2, 2010 at 11:06 PM, Gavin King
<gavin.king@gmail.com> wrote:
On Sat, Jan 2, 2010 at 1:27 PM, Matt Drees <
matt.drees@gmail.com> wrote:
>> ++ Clarify that scope types should not have members
>>
>> The spec should mention that @ScopeType annotations should not have
>> annotation members. Perhaps this should be a definition error.
>> javax.inject.Scope already mentions this.
>
> I'm sure you meant @NormalScope.
> Can I ask what the motivation is for preventing annotation members on scope
> annotations? I could imagine some custom scopes needing some extra
> metadata, and the scope annotation seems like a handy place to put it.
Well, the thing is that our SPI provides no way for an implementation
of Context to get access to the annotation members for a certain Bean.
Bean.getScope() returns the Class, not the Annotation.
True.
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.
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.
But you didn't really answer the question. Why go out of your way to prevent annotation members?
>> ++ Clarify that interceptors/decorators don't apply to producers in
>> resolution rules
>>
>
> I don't understand. 7.2 seems to explicitly state that
> interceptors/decorators *do* apply to producer methods. Can you clarify?
They apply to the method call (but these are interceptors/decorators
that belong to the bean that declares the method, not to the method
itself). The object returned does not have interceptors/decorators
added.
Ok, thanks. Makes sense.
> So, I think it'd be very helpful to have a section devoted to cyclic
> dependencies. Some kind of cyclic dependencies are ok while others are not,
> and I think we can enumerate these.
...
> Is this maintenance release an appropriate time to address this question?
> (I haven't yet checked how Weld handles this)
Propose some language :-)
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).
> Also, I'm a little surprised your list didn't contain a ConversationManager
> API. Is this too big of a thing for a maintenance release? It seems pretty
> important to me.
I think it's quite big for the maintenance release, though I agree
that it's important.
--