[webbeans-dev] [TCK] Bean<T>#create() reference in the Spec?
by Mark Struberg
Hi!
I tried to run the TCK tests, e.g.
DependentContextTest#testContextIsActiveDuringBeanCreation()
and have a question regarding the call
FoxRun foxRun = foxRunBean.create();
I read through the Spec dated 20090116 and I cannot find any create() with no argument for a Bean<T>.
Section
> 3.11. The Bean object for a bean
references to
> 6.1. The Contextual interface
> public interface Contextual<T> {
> public T create(CreationalContext<T> creationalContext);
> public void destroy(T instance);
> }
and there is no non-arg create() function but only one with a CreationalContext. Otoh you reference the Contextual.create() a few times in section 6.2. I interpreted this as short form for the method with CreationalContext but after I read the TCK I'm slightly confused.
Am I missing something?
txs and LieGrue,
strub
15 years, 3 months
[webbeans-dev] 2009-01-16 draft feedback
by 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-@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(a)gmail.com</myapp:lastName>
</myapp:Admin>
</value>
<value>
<myapp:Admin>
<myapp:name>Gavin King</myapp:firstName>
<myapp:email>gavin(a)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
15 years, 3 months
[webbeans-dev] Last Spec.Section 9.1
by Gurkan Erdogdu
Hi;
In the last specification section 9.1, Context interface *get* methods does not take *create* boolean parameter. Is it correct ?
public <T> T get(Contextual<T> bean);
public <T> T get(Contextual<T> bean, CreationalContext<T> creationalContext);
Thanks;
/Gurkan
15 years, 3 months
[webbeans-dev] Section 6.1 [The Contextual Interface]
by Gurkan Erdogdu
Hi;
In section 6.1, the contents of the CreationalContext is written as follows;
public interface CreationalContext<T>
{
void push(T incompleteInstance);
}
Is it applicable to change it as
public void push(Bean<T> bean, T incompleteInstance);
and also add another method to pop this incomplete instance from the creational context;
public T pop(Bean<T> bean)
/Gurkan
Thanks;
15 years, 3 months
[webbeans-dev] TCK status
by Pete Muir
We now have started to put the TCK infrastructure in place:
* TCK porting package APIs to allow the TCK to request the RI do stuff
like create a SimpleBean from a class
* implementation of these APIs for RI
* Start TCK run and view output (testng format)
We're now running the TCK (all 5 tests which have been ported so far)
as part of WB testsuite - currently a single WB RI test is responsible
for kicking off the TCK run. If the TCK run fails, then that test will
fail. You won't see a merged testrun total on when you run mvn test,
however Hudson is correctly reporting the merged totals.
This perhaps isn't the ideal situation, and I'm thinking about how to
improve it (perhaps run the TCK as another module, rather than as part
of the RI testsuite, and keep that for RI unit tests).
David and Shane have also started work on porting the spec tests from
the RI unit test suite to the TCK.
15 years, 3 months
[webbeans-dev] Constructor Parameter Injection
by Gurkan Erdogdu
Hi;
In today, as far as I understand from the XML chapter of the specification , there is no support for the primitive/wrapper injection into the constructor parameter via XML decleration like this.
<myapp : BeanTest>
<lang:Integer>42</lang:Integer>
</myapp:BeanTest>
for bean class
class BeanTest
{
private int param;
public BeanTest(int param)
{
this.param = param;
}
}
For example, when the bean is instantiated by the container, it injects the *param* parameter as 42. Currently there is only way to the this via @Initializer method.
I think this is important, because lots of old codes may be benefited from the webbeans without touching their codes.
/Gurkan
15 years, 3 months
[webbeans-dev] New draft with terminology update
by Gavin King
OK, here's a draft with the following terminology:
Web Bean -> bean
enterprise Web Bean -> session bean
simple Web Bean -> simple bean
Web Bean instance -> contextual instance (of a bean)
There's also a bit more rewriting, especially in chapter 1, and also
an overall refresh of various terminology for consistency.
This was a lot of work, and it still needs a much better proofread,
since I may have broken some things.
There's also a couple of other changes in this draft:
* prohibition of public fields on web beans with normal scope
* addition of Bean.getInjectionPoints()
Please read this over and let me know how you feel about it.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
15 years, 3 months
[webbeans-dev] CreationalContext
by Gavin King
Folks, I would like to go ahead and write up this change, unless anyone objects.
It's a hole that needs fixing.
On Fri, Jan 2, 2009 at 4:19 PM, Gavin King <gavin(a)hibernate.org> wrote:
> The alternate solution is something like:
>
> interface CreationalContext {
> <X> void add(Bean<X> bean, X instance); //registers an "incomplete" instance
> }
>
> interface Contextual<T> {
> public abstract T create(CreationalContext ctx);
> ...
> }
>
> interface Context {
> public <T> T get(Contextual<T> bean); //get any existing instance
> public <T> T get(Contextual<T> bean, CreationalContext ctx);
> //get or create an instance
>
> public Class<? extends Annotation> getScopeType();
> boolean isActive();
> }
>
> interface Manager {
> Object getInstanceToInject(CreationalContext ctx,
> InjectionPoint ij, Type type, Annotation... bindings);
> ...
> }
>
> And getInstanceToInject() would be smart enough to return any object
> that had already been registered with the CreationalContext.
>
> Note that this solution addresses the problem of circular references,
> and also fixes a hole in how the Manager knows about the InjectionPoint.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
15 years, 3 months
[webbeans-dev] Rough draft proposal for resource injection
by Gavin King
Everyone, please take a look at section 3.6 of this spec draft, which
defines a proposal for EE resource injection.
Basically, what I've proposed is that web beans would let you rewrite
the following:
@Resource(mappedName="customerDatabase") Datasource ds;
as:
@CustomerDatabase Datasource ds;
<javaxsql:Datasource>
<Resource>
<mappedName>customerDatabase</mappedName>
</Resource>
<myapp:CustomerDatabase/>
</javaxsql:Datasource>
and:
@EJB(ejbLink="somejar#Foo") Foo foo;
as:
@Current Foo foo;
<myapp:Foo>
<EJB>
<ejbLink>somejar#Foo</ejbLink>
</EJB>
</myapp:Foo>
and:
@WebServiceRef(name="barbar", wsdlLocation="barbarbar") Bar bar;
as:
@Current Bar bar;
<myapp:Bar>
<WebServiceRef>
<name>barbar</name>
<wsdlLocation>barbarbar</wsdLocation>
</WebServiceRef>
</myapp:Bar>
So this proposal is just basically an indirection around the
pre-existing semantics of Java EE injection, that gives you all the
nice Web Beans typesafety.
This seems a really nice, easy way to define this stuff, and I love
how the XML looks.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
15 years, 3 months
