[webbeans-dev] numberguess example
by Pete Muir
I think I've committed a fully working version of this - check out the
readme.txt in the examples dir for instructions on how to install
webbeans to JBoss 5 and for how to deploy the example.
16 years
[webbeans-dev] [Number-guess example]
by Gurkan Erdogdu
Hi;
In the number guess example, the @Initializer annotated constructor of the Game is defined as not public modifier. Is there any requirement for Constructor's modifier ?
Thanks;
Gurkan Erdogdu
16 years
[webbeans-dev] XML Annotation Configurations
by Gurkan Erdogdu
Hi;
While parsing the XML file for Binding annotations, we get class files for binding annotation in hand, but we are not able to instantiate Annotation object from this file . But when resolving injection points, the API expects Annotation array in the Manager API.
For example; in XML injection point decleration, such as Initializer method
<myapp:setPaymentProcessor>
<Initializer/>
<myapp:PaymentProcessor>
<myapp:PayBy>CHEQUE</myapp:PayBy>
</myapp:PaymentProcessor>
<myfwk:Logger/>
</myapp:setPaymentProcessor>
PayBy is a binding type but we can get just class name of this binding type with Class.forName(""). How could create the Annotation object from this class file to input into the Manager resolution methods to resolve parameters?
Or this definition means that, setPaymentProcessor method has already PaymentProcessor type parameter with PayBy annotation and we just care this annotation not other binding annotations (i.o.w binding type that is configured in the XML has to be declared in the method ?) , for example;
In class;
....
{
public void setPaymentProcessor(@PayBy(CHEQUE) @OtherBinding param1){} --> We just care about @PayBy?
}
So we can get Annotation with using method.getGenericParameterTypes()?
Thanks;
Gurkan
16 years
[webbeans-dev] Embedded EJB 3.1 support in Web Beans testsuite
by Pete Muir
I've added Carlo's first alpha release of JBoss Embedded EJB 3.1 to
the web beans test suite. Post any feedback on the EJB3 forum about
the embedded container.
To use it, extend AbstractEjbEmbeddableTest rather than AbstractTest,
as this will boot and shutdown the container around all tests in that
class. Note, we still need to do the discovery impl of EJBs for
Embedded (populate EJBDescriptors) so for now we can't test that much
with it. Once Andy has done the EJB discovery for AS we'll try to port
it to the test suite/embedded.
16 years
[webbeans-dev] Dynamic lookup
by Gavin King
An issue that Bill brought up on the last concall, and that has been
bothering me for a while is that we have a few different cases where
the application wants to perform a dynamic lookup:
(1) when binding types vary at runtime
(2) when the dependency is optional
(3) when you want to obtain an object that belongs to a child manager
But the only way we let you do this is by injecting the Manager
object, which has really evolved into an SPI-type integration point
and has a whole bundle of operations that should not really be in the
view of the application. Furthermore, it requires use of
AnnotationLiteral for all binding types, which is pretty nasty.
So I think we need to provide a different API, one that is more
appropriate to usage by the application.
Other solutions do have sugar for this: Guice has an injectable
Provider<T> interface, Spring let's you write an abstract method which
is implemented by the container.
I think we should model a lookup interface on what we have for event
firing. Analogous to:
@Observable @SomeBinding Event<SomeEventType> someEvent;
We should let you inject:
@Obtainable @SomeBinding Instance<SomeType> someInstance;
Which would let you call someInstance.get() to obtain an instance of
the SomeType with SomeBinding.
This would involve the following new interface:
public interface Instance<T> {
public T get(Annotation... bindings);
public boolean isSatisfied(Annotation... bindings);
}
This is a *much* simpler API to use.
The isDefined() method would let you determine if any Web Bean exists
that satisfies the API type and bindings.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
[webbeans-dev] Dynamic lookup
by Gavin King
An issue that Bill brought up on the last concall, and that has been
bothering me for a while is that we have a few different cases where
the application wants to perform a dynamic lookup:
(1) when binding types vary at runtime
(2) when the dependency is optional
(3) when you want to obtain an object that belongs to a child manager
But the only way we let you do this is by injecting the Manager
object, which has really evolved into an SPI-type integration point
and has a whole bundle of operations that should not really be in the
view of the application. Furthermore, it requires use of
AnnotationLiteral for all binding types, which is pretty nasty.
So I think we need to provide a different API, one that is more
appropriate to usage by the application.
Other solutions do have sugar for this: Guice has an injectable
Provider<T> interface, Spring let's you write an abstract method which
is implemented by the container.
I think we should model a lookup interface on what we have for event
firing. Analogous to:
@Observable @SomeBinding Event<SomeEventType> someEvent;
We should let you inject:
@Obtainable @SomeBinding Instance<SomeType> someInstance;
Which would let you call someInstance.get() to obtain an instance of
the SomeType with SomeBinding.
This would involve the following new interface:
public interface Instance<T> {
public T get(Annotation... bindings);
public boolean isSatisfied(Annotation... bindings);
}
This is a *much* simpler API to use.
The isDefined() method would let you determine if any Web Bean exists
that satisfies the API type and bindings.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
[webbeans-dev] Drop pluggability
by Gavin King
I'm getting a bunch of feedback to the effect that the Web Beans spec
should drop the notion of a pluggable Web Bean manager.
I'm prepared to go down this path on the condition that we reach
agreement with the EE group that Web Beans will be a required part of
the Java EE 6 web profile, which is something that has not yet been
agreed (however, I believe that agreement will eventually be
achieved).
This would be a major simplifying change to the spec:
* it would immediately close off most of the open issues mentioned in
the Public Draft
* we could stop talking about a "Web Bean manager", and simply talk
about the "container", where "container" would be defined to refer to
either the Java EE container, or the embedded EJB Lite container in
the SE case
* we could remove several special cases where functionality "is not
required when a plugin Web Bean manager runs in a Java EE 5
environment"
* it would help avoid giving the impression that web beans is a
separate component model with a separate container
Of course, the downside of this change is that implementations of 299
would no longer be pluggable in different EE environments. This simply
doesn't seem like much of a big deal to me - at least not unless Web
Beans is an optional feature of EE6, in which case the pluggability
contracts are required for people to even be able to use Web Beans in
EE when their vendor does not support the optional feature.
I would like to know if anyone here is especially attached to
pluggability and would be upset by the removal of this feature. I
would especially like to know if this would affect anyone's plans to
*implement* 299.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
