On Tue, Dec 29, 2009 at 3:44 PM, Gavin King <gavin.king@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.

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

++ Producers and beans that are under construction

I think we need the spec to say something about cases where an
injection point of a bean resolves to a producer method of the same
bean. The implementation should detect that this is a definition
error. It shouldn't try to call a producer method on a
non-fully-initialized bean.

This is good, but I think we should be able to say something more general. We'd also want to outlaw this:

class Foo {
@Inject @BarProduct Baz;

@Produces @FooProduct Baz produceBaz() { ... }
}

class Bar {
@Inject @FooProduct Baz;

@Produces @BarProduct Baz produceBaz() { ... }
}

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.

On a related note, I had asked once about how this is handled:

@RequestScoped
class Foo {
   @Inject Bar bar;

   @PostConstruct void init() {
      bar.doSomething();
   }
   ...
}

@RequestScoped
class Bar
{
   @Inject Foo foo;

   @PostConstruct void init() {
      foo.doSomethingElse();
   }
   ...
}

Is this maintenance release an appropriate time to address this question?
(I haven't yet checked how Weld handles this)

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.
And even if we can't address it for the MR, maybe we can at least start a discussion to nail down the API. Sooner is better than later, I think.

Thanks,
-Matt

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