JSF 2 and CDI – a nice combo!

In JSF 2.0 there is (optional) support for annotating JSF Managed beans, via the Faces Managed Bean Annotation Specification. Both Apache MyFaces and the SUN RI implement this specification.

With the advent of these two JSRs:

There is an ongoing discussion about the right annotation for the “JSF beans”.

I agree that a JSF 2.0 application should avoid using the @ManagedBean annotation. I prefer using the stuff that 299/330 are offering. The good news is that even Spring (in Version 3.0) does actually support the @inject specification (e.g. @Named).

Using the two specifications, a simple bean could look like:

...
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;

@Named
@RequestScoped
public class HelloWorldBean
{
...
}
...

For CDI there is a neat convenience annotation (@Model) that combines the two above (@Named and @RequestScoped)!

Too bad that Spring does not support CDI (JSR 299), so the @Model is not usable there… However, making something on your own (e.g. @SpringModelBean) is not hard, as you just have to combine the @Named and the @Scope(“request”) annotation, from Spring…

UPDATE: Enabling the CDI/299 Scopes in Spring is pretty simple.

One concern maybe that 299 is only usable inside of a fullblown Java EE 6 container, like Glassfish3. But that is not the case. The implementations of the 299 specification from Apache(OpenWebBeans) and JBoss (Weld) are offering support for Servlet Containers, like Tomcat.

I added a new (very) simple HelloWorld that combines CDI(299/330) and JSF 2.0 to my FacesGoodies project. The source is located here. For the implementations I picked Apache MyFaces 2.0 (the first alpha release is out; a beta is coming soon) and Apache OpenWebBean (which recently left the Apache Incubator). The combination of these two standards really matches very well. I will add more complex demos to FacesGoodies soon, but this (trivial) HelloWorld demo is just a starting point.
Note: Currently you have to build the OpenWebBeans stuff, to have the latest greatest fixes from the trunk (or, use the M3 release from the incubator repository).

Another benefit is, as my demo uses the JettyMavenPlugin, with CDI you can use the jetty:run goal. The annotations for the JSF managed bean facility do require jetty:run-exploded, which is kinda odd… See… another reason to use CDI with JSF 2.0 :-)

Apache offers great support for these with its MyFaces and OpenWebBeans project! Check em out!

HINT: You need to build Apache OpenWebBeans in order to run this example. Do the SVN checkout from this location. And run mvn install in its root-folder!

Running ADF on different containers

When you download JDev, your application by default runs (and deploys) agains the Weblogic container. However, the ADF framework is running on different containers as well. My colleague Shay Shmeltzer gave me a list of instructions for different containers, today.

Here it is:

* yeah, as of yesterday Glassfish 3 is out. I guess someone will write an instruction for that container in the (near) future as well …

Hope this list helps!

ADF’s Active Data Service and multiple push windows

As mentioned here, the ADS feature of ADF Faces supports “push channel sharing” since a very long time…

The first window that hits a page which contains an active component, e.g. a <af:table> that is referencing to an ActiveDataModel implementation, becames the “master” window. This window maintains a persistent connection to the ADS subsystem. In the screenshot you can see that the first window has a HTTP GET request to a wls.ads resource (this URL is representing our implementation of the AbstractAsyncServlet of Weblogic – yes on other containers this is not invoked… ;-) ).

Notice that the second window does NOT have a connection to that servlet… In fact, when the second page renders, it registers itself with the master window. Once the ADS subsystem receives a new (server-side) event, in streams the data ONLY to the master window. That window simply dispatches the payload to the components (on the right page/window).  Some more on how to talk to a different window, you can read here.

Now you may wonder what happens if you close the master window (or do a refresh/F5 there) ? You are not (totally) loosing the persistent connection. The client side engine of ADS (called Active Data Manager) notices that the master window is going away and migrates the channel to one of the slave windows. That ensures you never loose active data…

This is a pretty cool feature! To play with ADS / ADF just get a copy of JDeveloper.

ADF Faces and Server-Side-Push

Some of you already know that ADF Faces does Server-Side-Push, with its ADS (Active Data Service) facility. It is a very feature rich offering that has cool stuff, under the hood. Over the last release we also improved our documentation.

To mention only a few features, ADS supports HA/fail-over since 2008, but that is unfortunately not (yet) mentioned in the documentation.. Another cool thing is that it doesn’t waste the “open connection limitation” from some browsers, as it shares an “active channel” for the push content. Therefore only one window is “talking” with the server and it basically dispatches the streamed-up content to all registered (slave) windows.

The key concept of the ADS solution is that it is pretty much model driven right now and therefore doesn’t force the page author to do (much) sit-ups… Once you have a working implementation of our ActiveDataModel interface, you get active data for free, with our table component (<af:table value=”#{myBean.activeModelImplementation}” />), for instance. For the last release we also offered a convenience implementation, called the Active Data Proxy. That is a pretty nice option to also connect your existing model (and/or enterprise Java, like JPA) with the ADF Faces Push-Solution (meaning ADS). I will post some examples and use-cases, done with the “proxy” here soon…

By default ADS uses (HTTP) STREAMING as its transport mechanism. However the solution also supports LONG-POLLING and POLLING (periodic polling). For the last release we added the LONG-POLLING support. Before that we offered POLLING (still supported ;-) ) as an alternative transport option, as HTTP-STREAMING can have some issues with (legacy) infrastructure (e.g. HTTP 1.0 proxy-servers). A big benefit is that the used transport-option is transparent for the developer, as the ADS subsystem handles that for you. That means the <af:table> component, for instance, just receives the new data; regardless if ADS does STREAMING, LONG-POLLING or even (periodic) POLLING.

ADS (and ADF Faces, of course) has a ton of cool features. You just need to explore them ;-)

To get started, get a copy of our latest (November 2009) release of JDeveloper and read the documentation :-)

Java EE 6 – the web profile

The JSR 316 (Java EE 6) has been approved by the “Executive Committee for SE/EE”. See the vote result details here.

It is interesting to see that the Web Profile has no optional component. In fact all these guys are required:

  • Servlet 3.0
  • JavaServer Pages (JSP) 2.2
  • Expression Language (EL) 2.2
  • Debugging Support for Other Languages (JSR-45) 1.0
  • Standard Tag Library for JavaServer Pages (JSTL) 1.2
  • JavaServer Faces (JSF) 2.0
  • Common Annotations for Java Platform (JSR-250) 1.1
  • Enterprise JavaBeans (EJB) 3.1 Lite
  • Java Transaction API (JTA) 1.1
  • Java Persistence API (JPA) 2.0
  • Bean Validation 1.0
  • Managed Beans 1.0
  • Interceptors 1.1
  • JSR-299 1.0
  • JSR-330 1.0

You can find all specs (Java EE 6, Web Profile and Managed Bean) here. Looks like there are now three standards that less or more do (somehow) Dependency Injection:

  • Managed Beans
  • JSR 299
  • JSR 330

As the Managed Bean was optional for a JSF 2.0 implementation, it is now (somewhat) required to be implemented. Well Apache MyFaces did that already… And, of course, the JSF RI /Mojarra/ did that too.