Hi all,
I just finished going through the 2009-01-16 draft. Here's what I've got:
-p 5 I suggest we include @Inherited in @InterceptorBindingType example, since we recommend it later on
-p 13 same as above, but with ScopeType
-p 18 Should it be a DefinitionException to define a Stereotype with @Target{Type,Field} ? @Target(Parameter)? etc
-p 20 Should it be a DefinitionException to have a stereotype with transitive stereotypes with conflicting supportedScopes or requiredTypes?
-p 22 "implementing the Bean interface" should be extending the Bean abstract class
-p 43 doesn't specify whether @Named is @inherited or not. Seems to me like it should.
-p 43 It may be worth including a note that bindings/stereotypes/etc cannot be inherited from Interfaces
-p 44 extra space: " lower-priority bean , in the case"
-p 49 outdated Context api terminology: " and true as the value of the create parameter, and"
-p 56 I think Instance.get() should throw an exception if no such bean exists, not return null, since some beans are nullable, and some apps may use null to mean something special.
-p 59 "The container performs perform" has an extra "perform" in there. Twice on page.
-p 63 Is there a reason for tying IllegalProductExceptions for null producer results to non-@Dependent scopes instead of normal scopes? Other pseudo-scopes may want to support null objects...
-p 85 Should the observer search algorithm mention the caveat of @NonBinding?
-p 89 "Suppose beans A, B and Z " I'd make z upper-cased, like A and B. Not a biggie.
-p 89 referring to old Context api (true/false for create)
-p 92 Application context should probably be active during Asynchronous observer method invocations.
Side question (and sorry if this has already been asked): Why can't the application context always be active? I anticipate creating threads time to time, and it'd be obnoxious to not be able to access the application context from them.
Other things:
I noticed that we don't define what happens if an application tries to invoke a method on a not-fully-constructed bean yet.
Say for example:
@RequestScoped
class Foo
{
@Current Bar bar;
@PostConstruct void init()
{
bar.doSomething();
}
...
}
@RequestScoped
class Bar
{
@Current Foo foo;
@PostConstruct void init()
{
foo.doSomethingElse();
}
...
}
Someone here has to lose. Same type of thing can happen with @Initializer methods and constructors, I believe.
Perhaps this needs to be specified for Context objects. If the two-param get() method is invoked for a bean that is currently being created by a different two-param get() invocation, then throw a BeanNotConstructed exception? Though, that doesn't quite work, because sometimes you need to hand out references to unconstructed objects. So maybe introduce a getFullyConstructed() method on Context that potentially throws a BeanNotConstructed exception, and client proxies call this method? It's late; maybe I'm speaking nonsense. :-)
It struck me that ejb 3.1 @Singleton session beans might have this problem, too, but it didn't look to me like the ejb 3.1 PR spec deals with this. I was hoping we could behave the same way that spec behaves. Oh well. How do most ejb impls behave?
@Destructor is still mentioned in a couple places throughout the spec
re: Open issue: what restrictions exist upon invoking dependencies from @PreDestroy?
Can we say that that beans within a Context are destroyed in the opposite sequence of their construction? This would help deter (though not prevent) beans from invoking destroyed beans.
If we had more time, I wonder if it'd be worth adding a @FullyConstructed annotation to specify a dependency must be constructed before, and destroyed after, this bean
re: Open issue: is the request context (and application context) active during servlet filter execution?
Can we now say Request/Session/Application contexts available in servlet filters, since pluggability has been dropped?
If someone has a @Obtains Instance<Calculator> field, where Calculator is a @Dependent bean, they may feel confused when they try to invoke instance.get() in a business method and get a ContextNotActiveException. How would you feel about letting the @Dependent context be active during Instance.get() invocations?
I should have brought this up much earlier, but I'd love to have something like this:
<myapp:Config>
<myapp:administrators>
<value>
<myapp:Admin>
<myapp:name>Matt Drees</myapp:firstName>
<myapp:email>matt.drees@gmail.com</myapp:lastName>
</myapp:Admin>
</value>
<value>
<myapp:Admin>
<myapp:name>Gavin King</myapp:firstName>
<myapp:email>gavin@hibernate.org</myapp:lastName>
</myapp:Admin>
</value>
</myapp:administrators>
</myapp:Config>
(basically, combining List-type initial values and inline bean declarations)
I'm sure it's too late for this version now, but this seems doable, and I hope we at least implement this in the RI. I don't see anything in the spec that explicitly forbids this sort of thing, right?
The Resource stuff and the Asynchronous events stuff look fine to me.
-Matt