Hi all,
See comments below.
On Tue, Dec 29, 2009 at 3:44 PM, Gavin King <gavin.king(a)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