[webbeans-dev] 2009-01-16 draft feedback

[Matt Drees]

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- at 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 at gmail.com</myapp:lastName>
   </myapp:Admin>
  </value>
  <value>
   <myapp:Admin>
    <myapp:name>Gavin King</myapp:firstName>
    <myapp:email>gavin at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20090119/3d04159b/attachment.html