4:01 a.m.
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