[webbeans-dev] Redefinition of @New / clarification of injection for non-contextual instances
by Gavin King
There's one important thing that is not especially well-defined in the
spec today and that has been bothering me for a while. It's to do with
injection into non-contextual bean instances.
There are a couple of cases where the spec supports injection into
non-contextual bean instances:
* session beans obtained using JNDI lookup or direct injection using @EJB
* @New
In each of these cases you get an instance of a bean which is *not*
bound to the scope declared by the bean. However, the spec still
requires injection into the bean instance.
However, there may be multiple "beans" (i.e. instances of Bean) of the
given type:
* one defined using only annotations
* others defined using XML
and each "bean" may have different dependencies defined.
So the question naturally arises: when I obtain this instance from
JNDI or using @New or @EJB, exactly *which* "bean" is it an instance
of? i.e. which set of bean metadata should be used?
I've not found any completely satisfying answer to this question - but
there's only one possibility that is truly well-defined:
* it is the one defined using annotations ... even if that bean has a
disabled deployment type!
I've been thinking about how best to characterize this in the spec,
and I think the answer is slightly surprising.
We should say that for each bean type, there is one extra "bean", so
we now have:
* the one defined using only annotations
* one that is exactly the same, but with scope @Dependent, binding
@New and deployment type @Standard
* the others defined using XML
We can now characterize session beans obtained using JNDI lookup or
@EJB as instances of the bean with binding @New, removing the
ambiguity.
This approach lets me eliminate section 3.10 (yay!), since there is no
longer anything special/magical about @New, and replace it with some
shorter notes in 3.2/3.3.
Even better, you'll no longer have to use the concrete type of the
bean when you inject using @New. This is especially useful for session
beans with no bean class local view.
So this turns out to be simultaneously a simplification, enhancement
and clarification of the spec, and it's also easier to implement!
Does that make sense to everybody?
Anyway, I guess I will write this up so you guys can see what it looks
like in the spec.
--
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] Distributed event channels
by Gavin King
IBM has raised the issue of event processing in a distributed
environment, and we (Red Hat) have promised to address this issue in
the revised public draft.
The Web Beans event bus provides a very nice way for stateful
components to synchronize their state (transactionally) with changes
that take place in the application. Event processing is *much* more
important in an environment with stateful object such as SFSBs than it
is in an environment with only stateless objects such as SLSBs or
Spring beans. Furthermore, event processing must be aware of the
transaction completion lifecycle (many applications today have bugs
when transaction rollbacks occur). Therefore, I believe that event
processing is an essential feature of Web Beans.
However, the event bus we have today is a purely local construct and
does not help when the application is distributed across multiple
cluster nodes or multiple physical tiers.
Designing a distributed event bus would potentially be a very
difficult undertaking, with so many issues to think about: QoS,
asynchronicity, transactionality, routing, etc. Fortunately, JMS
already has the features we need, and is what is sometimes used today
to solve the problems we're talking about:
* asynchronous, distributed semantics
* a notion of both 1-of-N and N-of-N semantics (queues and topics)
* a notion of logical channels (to allow routing of events between
tiers and applications)
* support for a range of QoS semantics
* transactionality
Furthermore, JMS is well-understood and well-supported.
If the spec simply defines that events were distributed via JMS,
absolutely nothing would stop vendors from also supporting alternative
distribution mechanisms as proprietary extensions (for example, in
JBoss we could provide support for JGroups).
And when EE finally gets a WorkManager API, a future version of Web
Beans could also define that distribution of local asynchronous events
is via the WorkManager.
The application developer would not be exposed to the JMS APIs. The
actual interaction with JMS would be handled by the container. All the
developer would need to do is specify that events with a specific type
and binding types would be distributed by a certain queue or topic.
(web-beans.xml would be the right place to specify this mapping.)
What I'm thinking is the following:
(1) Event observers may specify that they receive events asynchronously:
void invalidateCache(@Observes @Asynchronously @Created Product
product) { ... }
or even:
void invalidateCache(@Observes(ASYNCHRONOUSLY) @Created Product
product) { ... }
By default, an asynchronous observer is a purely local construct.
However, unlike synchronous observers, an asynchronous observer is
called in a different set of web beans contexts to the contexts in
which the event was fired.
(2) A topic or queue declaration may specify a set of events which are
distributed via that queue/topic:
<Topic>
<destination>java:comp/env/jms/CacheInvalidationEvents</destination>
<connectionFactory>java:comp/env/jms/TopicConnectionFactory</connectionFactory>
<events>
<myapp:Product>
<myapp:Created/>
</myapp:Product>
</events>
</Topic>
This declaration means that any event that is "assignable" to the
specified type and binding types is a distributed event, distributed
by the named JMS topic.
(3) The Web Bean manager would validate that all observers for any
event distributed via JMS are declared to be asynchronous observers,
and throw an exception if there are any synchronous observers for the
event.
(4) We need to think carefully about the concept of an asynchronous
transaction completion event observer. The following combinations are
semantically correct, and need to be supported, even for the distributed
case:
@Observes @Asynchronously @AfterTransactionCompletion
@Observes @Asynchronously @AfterTransactionSuccess
@Observes @Asynchronously @AfterTransactionFailue
However, this combination is not meaningful:
@Observes @Asynchronously @BeforeTransactionCompletion
(5) Finally, since JMS is a transactional medium, we could support a
further setting which writes the event transactionally to the queue/topic.
However, this setting needs to be a global setting for the event type.
Perhaps an @Transactional annotation for the event type?
WDYT?
15 years, 3 months
New deployment lifecycle (Was: [webbeans-dev] Re: Bean.getInjectionPoints())
by Gavin King
OK, I've fixed this problem by:
* changing when the @Initialized event occurs
* introducing a new @Deployed event at the end of the deployment
* removing the validate() method from Manager (no longer needed)
Take a look at chapter 12, esp. 12.1 and 12.5.
On Fri, Jan 2, 2009 at 4:33 PM, Gavin King <gavin(a)hibernate.org> wrote:
> But the problem is that it doesn't know *when* to validate. Validation
> can't be performed until *all* Beans have been registered.
>
> Hum, I now see that there's a problem with the current definition of
> the @Initialized Manager event - it actually needs to happen *before*
> deployment problems are validated and thrown. Or perhaps there should
> be two events? @Initialized Manager and @Deployed Manager.
>
> Lucky we didn't let that slip through!
--
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] Bean.isProxyable()
by Pete Muir
I think that Bean needs an isProxyable() method to allow
Manager.validate() to check whether a bean in a normal scope can be
proxied, and if not throw the UnproxyableDependencyException.
WDYT?
15 years, 3 months
[webbeans-dev] Licensing for WB bundle
by Pete Muir
I want to use the JBoss Embeddable EJB 3.1 container for tests, but
this is licensed under LGPL. I don't need to link against LGPL APIs in
the testsuite, but I do need to bundle the JBoss EJB 3.1 Embeddable
container.
So, this raises the question, does the whole WB bundle need to be ASL
(deps, examples, docs etc as well as source/webbeans-ri.jar) or just
the source? (Hopefully the latter)
Pete
15 years, 3 months
[webbeans-dev] XML configuration format
by Gavin King
I would like to open up a discussion about the XML format defined in chapter 10.
Mike is concerned that the XML format is different to the style used
in other Java EE specifications, where class/method names are
generally specified as strings in the body of XML elements, and that
the XML format may turn out to be confusing to users.
On the other hand, the format currently defined by the specification
is typesafe, allowing tooling to provide validation and
auto-completion of all class/method names, and is also less verbose.
It's also consistent with the approach used by existing solutions in
the spec (Spring, Seam).
I've recently discovered that it's possible to write a Java 6
Processor that would generate the XML schema for a package containing
web beans as part of the compilation process. (This is an awesome new
feature of javac, that used to be provided by the APT plugin.)
One possible path to take would be to use hyphenated names in the XML
(i.e. <foo-bar> instead of <FooBar>) to make the XML more visually
consistent with other EE descriptors.
I would like to get everyone's thoughts on this issue:
Do you like the existing format?
Do you find it confusing? In what way?
Have you used this approach in Spring or Seam? If so, how did it compare?
How important is typesafety?
--
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] Re: Injection point metadata API
by Gavin King
Upon further consideration, I think we should not add the
getInstance() method to InjectionPoint. First, because:
* it can't return a value when constructor injection is happening,
* it always returns an object in an undefined state,
* I have not been able to think of a compelling usecase,
* it places subtle restrictions on implementations of Bean, and
* we're starting to use InjectionPoint as a *static* metadata API so
it would have to be moved anyway.
Does anyone disagree with this decision?
On Wed, Dec 24, 2008 at 5:40 PM, Gavin King <gavin(a)hibernate.org> wrote:
> ---------- Forwarded message ----------
> From: Matt Drees <matt.drees(a)gmail.com>
> Date: Sun, Nov 16, 2008 at 4:25 PM
> Subject: Injection point metadata API
> To: Gavin King <gavin(a)hibernate.org>, Java Community Process JSR #299
> Expert List <JSR-299-EG(a)jcp.org>
>
>
> I really really liked the feature Gavin talked about here:
> http://relation.to/Bloggers/InjectionPointMetadataAPIForWebBeans
> I think there are some very cool possibilities this opens up for
> framework developers and application utility libraries. IMO, this is
> a low-cost, high yield feature.
>
> Two other thought about this.
> First, I think it'd be nice to add a method to Manager:
> public interface Manager {
> public <T> T getInstance(Bean<T> bean, InjectionPoint injectionPoint);
> ...
> }
>
> This way if a framework ever has to manually inject objects into a
> non-WebBean, a @Current InjectionPoint can be made available to the
> injected object.
>
> Second, maybe the InjectionPoint could also be made available to the
> Context during a lookup? This way custom pseudo-scopes can be much
> more interesting. I haven't thought about this enough, but it sounds
> cool. :-)
> What do you think?
>
> -Matt
>
>
>
> --
> 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
15 years, 3 months
