[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, 11 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, 11 months
[webbeans-dev] Terminology
by Gavin King
Oracle have proposed that we remove the term "Web Bean" from the
specification. I'm therefore searching for alternative terminology.
Please let me know your opinions and suggestions.
Here's one possibility:
Web Bean -> injectable type
simple Web Bean -> injectable Java class
enterprise Web Bean -> injectable EJB
Or:
Web Bean -> contextual type
simple Web Bean -> contextual Java class
enterprise Web Bean -> contextual EJB
Note that "contextual type" already means something in the current
spec, but that thing should be easy enough to rename.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
15 years, 12 months
[webbeans-dev] maybe delay httpSession creation until needed?
by Matt Drees
Hey guys,
I noticed that webbeans is currently creating the HttpSession immediately at
the beginning of the request:
public static void beginRequest(HttpServletRequest request)
{
SessionContext.INSTANCE.setBeanMap(new
SessionBeanMap(request.getSession()));
...
}
Do you think it'd be worthwhile delaying session creation until it's
actually needed (i.e. when a session-scoped bean is first created)? Some
people may wish to avoid creating a session until a user logs in, for
example.
I don't know how many people actually do this.
For what it's worth, Seam tries to create sessions lazily, so it'd probably
be good to follow suit.
-Matt
15 years, 12 months
[webbeans-dev] Re: Removal of pluggability contracts
by Gavin King
On Sun, Dec 21, 2008 at 3:03 PM, Gavin King <gavin(a)hibernate.org> wrote:
> SFSBs with no web bean remove method
> ================================
> We have an open issue w.r.t destruction of SFSBs which have no web
> bean remove method. Now that the requirement for pluggability is gone,
> I think we should simply say that in this case, the container must
> destroy the SFSB when its context ends *without* calling any remove
> method.
>
> I will go ahead and make that change unless there is someone who
> objects to this.
Alternatively, we could actually go further than this and simply
eliminate the concept of the "Web Bean remove method" and the
@Destructor annotation. @Remove methods are really intended to be
called by clients, not by the container - and if you just want a
callback, we already have @PreDestroy. I'm not sure that @Destructor
is really adding any additional value.
The more I think about this, the more I think this is the right way to
go (and it simplifies the spec).
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
15 years, 12 months
[webbeans-dev] Automatically adding WebBeans configuration on JBoss 5
by Pete Muir
The idea here is that a Web Beans RI app requires certain
configuration applied by default (see below), and we should try to
provide this configuration by default when in JBoss 5. The user can
still override this configuration using the relevant XML. We've talked
about this before, but never done anything with it :-)
Here are the rules
1) ejb-jar.xml
If web-beans.xml is present in the ejb module's META-INF,
automatically add the Web Beans RI SessionBeanInterceptor (see
attached ejb-jar.xml for how we currently configure it). The user
can't disable this interceptor.
2) jboss-app.xml
If web-beans.xml is present in the ejb-module's META-INF,
automatically enable classloader isolation. Any settings in jboss-
app.xml override. Is it possible to explicitly disable classloader
isolation? Is this change from the jboss default too confusing?
Another option is to disable if a jboss-app.xml is present.
3) jboss-web.xml
If web-beans.xml is present in the war's WEB-INF or META-INF,
automatically enable classloader isolation. Any settings in jboss-
web.xml override. Is it possible to explicitly disable classloader
isolation? Is this change from the jboss default too confusing?
Another option is to disable if a jboss-app.xml is present.
4) web.xml
If web-beans.xml is present in the war's WEB-INF or META-INF or
the ejb module's META-INF automatically add the WebBeansListener
servlet listener
And one for the JSF2 deployer
5) if faces-config.xml is present, automatically add the FacesServlet,
it's mapping to the .jsf extension.
15 years, 12 months
[webbeans-dev] Bean.getInjectionPoints()
by Gavin King
The spec requires that injection points be validated at init time for
any Bean (for XxxxxDependencyException).
Nick from the RI team has noticed that for this to be implementable,
we need to add metadata about the injection points of a bean to the
Bean interface.
I propose:
public abstract class Bean<X> {
...
Set<InjectionPoint> getInjectionPoints();
}
Since we already have the following interface that describes injection points:
public interface InjectionPoint {
public Type getType();
public Set<Annotation> getBindingTypes();
public Object getInstance();
public Bean<?> getBean();
public Member getMember();
public <T extends Annotation> T getAnnotation(Class<T> annotationType);
public Annotation[] getAnnotations();
public boolean isAnnotationPresent(Class<? extends Annotation> annotationType);
}
I will make this change to the spec, unless anyone speaks up with any objection.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
16 years
