Hi all,<br><br>I just finished going through the 2009-01-16 draft. Here's what I've got:<br><br><br>-p 5 I suggest we include @Inherited in @InterceptorBindingType example, since we recommend it later on <br><br>-p 13 same as above, but with ScopeType<br>
<br>-p 18 Should it be a DefinitionException to define a Stereotype with @Target{Type,Field} ? @Target(Parameter)? etc<br><br>-p 20 Should it be a DefinitionException to have a stereotype with transitive stereotypes with conflicting supportedScopes or requiredTypes?<br>
<br>-p 22 "implementing the Bean interface" should be extending the Bean abstract class<br><br>-p 43 doesn't specify whether @Named is @inherited or not. Seems to me like it should.<br><br>-p 43 It may be worth including a note that bindings/stereotypes/etc cannot be inherited from Interfaces <br>
<br>-p 44 extra space: " lower-priority bean , in the case"<br><br>-p 49 outdated Context api terminology: " and true as the value of the create parameter, and" <br><br>-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.<br>
<br>-p 59 "The container performs perform" has an extra "perform" in there. Twice on page.<br><br>-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...<br>
<br><br>-p 85 Should the observer search algorithm mention the caveat of @NonBinding? <br><br>-p 89 "Suppose beans A, B and Z " I'd make z upper-cased, like A and B. Not a biggie.<br><br>-p 89 referring to old Context api (true/false for create)<br>
<br>-p 92 Application context should probably be active during Asynchronous observer method invocations. <br>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.<br>
<br><br>Other things:<br><br><br>I noticed that we don't define what happens if an application tries to invoke a method on a not-fully-constructed bean yet.<br>Say for example:<br><br>@RequestScoped<br>class Foo<br>{<br>
@Current Bar bar;<br><br> @PostConstruct void init() <br> {<br> bar.doSomething();<br> }<br><br> ...<br>}<br><br>@RequestScoped<br>class Bar<br>{<br> @Current Foo foo;<br><br> @PostConstruct void init() <br>
{<br> foo.doSomethingElse();<br> }<br><br> ...<br>}<br><br>Someone here has to lose. Same type of thing can happen with @Initializer methods and constructors, I believe.<br>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. :-)<br>
<br>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?<br>
<br><br><br>@Destructor is still mentioned in a couple places throughout the spec<br><br><br><br>re: Open issue: what restrictions exist upon invoking dependencies from @PreDestroy? <br>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. <br>
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<br><br><br>re: Open issue: is the request context (and application context) active during servlet filter execution? <br>
Can we now say Request/Session/Application contexts available in servlet filters, since pluggability has been dropped?<br><br><br><br>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? <br>
<br><br><br>I should have brought this up much earlier, but I'd love to have something like this:<br><br><myapp:Config> <br> <myapp:administrators> <br> <value><br> <myapp:Admin> <br> <myapp:name>Matt Drees</myapp:firstName> <br>
<myapp:email><a href="mailto:matt.drees@gmail.com">matt.drees@gmail.com</a></myapp:lastName> <br> </myapp:Admin><br> </value><br> <value><br> <myapp:Admin> <br> <myapp:name>Gavin King</myapp:firstName> <br>
<myapp:email><a href="mailto:gavin@hibernate.org">gavin@hibernate.org</a></myapp:lastName> <br> </myapp:Admin><br> </value><br> </myapp:administrators><br></myapp:Config> <br><br>
(basically, combining List-type initial values and inline bean declarations)<br><br>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?<br>
<br><br><br>The Resource stuff and the Asynchronous events stuff look fine to me.<br><br><br>-Matt<br>