[weld-dev] [jsr-299-eg] Maintenance release

Gavin King gavin.king at gmail.com
Sat Jan 2 23:06:48 EST 2010


On Sat, Jan 2, 2010 at 1:27 PM, Matt Drees <matt.drees at 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.

Yes.

> 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.

>> ++ 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.

> 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 :-)

> 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.



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



More information about the weld-dev mailing list