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