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

[Matt Drees]

On Sat, Jan 2, 2010 at 11:06 PM, Gavin King <gavin.king at gmail.com> wrote:

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

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.
>
>
>
> --
> Gavin King
> gavin.king at gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20100102/c7fb3f07/attachment.html