JSF @ManagedBean vs CDI @Named

There is a lot of discussions regarding differences between @ManagedBean and @Named annotations.  It appears that pretty much everyone is suggesting @Named as a best solution. As you can read, people say often that "...the presence of JSF 2 annotations is only to enable those on top of a Servlet containers ...".


I think this is not the whole truth.

Annotations from th package "javax.faces.bean" are provided for JSF managed beans where CDI annotations are helpers for CDI managed beans. Why I wrote JSF managed beans and CDI managed beans? Cause from the technical point of view JSF beans and CDI beans are completely separate entities. Managed bean is an object that it's life cycle is managed by a container. When JSF managed beans are managed by JSF container, CDI beans are managed by CDI container, and finally other types of beans (by example EJB) are managed by separate containers (by example EJB container) and so on.

Each container works independently. You could think about every container as a an independent process, which starts when server starts, scans loaded classes, gather and store some metadata about them, then when you need an object of a class at runtime they will give you instances of those classes and after finishing the job, they will destroy them.

So. We have different types of mananeged beans, and different types of managed bean containers. But which is "better" for typical JSF application?

The JSF managed beans are the part of JSF specifitacion from early 1.0 version, while the CDI container was introduced to the Java EE version 6.0 as a default, platform wide, managed beans framework. From this point of view you should use CDI where it is possible. CDI beans are far more advanced and flexible than simple JSF managed beans. With CDI you can use interceptors, conversation scope, events, type safe injection, decorators, stereotypes, producer methods and so on. In short words: as many says CDI is preferred over plain JSF because CDI allows for JavaEE-wide dependency injection. Of course if you need all this stuff.

But. There isn't any JSF managed beans advantage over CDI beans?

There are two simple issues which comes to my mind:

1. View Scope managed beans is a compelling reason to stick with JSF @ManagedBean - especially when you use a lot of AJAX requests. There is no standard replacement for this in CDI.
2. Efficiency is the next reason worth to consider. Especially if you work with Servlet container and CDI would be installed as an addition.

Webcenter Content UCM-CS-000001 java.io.IOException: !csUnableToFinishReadingStreamWithLength

As I noticed in one of our UCM instances, for some time has been steadily increasing the count of exceptions:

<2013-02-15 10:33:40 CET> <Error> <oracle.ucm.idccs> <UCM-CS-000001> <wyjątek ogólny
java.io.IOException: !csUnableToFinishReadingStreamWithLength,
default/repo_ucm/ucm_cluster/weblayout/groups/public/documents/doc/mdaw/mde2/~edisp/016565.pdf,
696043,936043!csUnableToFinishedReadingBytesBeingWritten!$socket write error: Connection reset by peer.
 at intradoc.common.DataStreamWrapperUtils.copyInStreamToOutputStream(DataStreamWrapperUtils.java:126)
 at intradoc.server.ServiceHttpImplementor.sendStreamResponse(ServiceHttpImplementor.java:2296)
 at intradoc.server.Service.doResponse(Service.java:2081)
 at intradoc.server.FileService.doResponse(FileService.java:1469)
 at intradoc.server.ServiceRequestImplementor.doRequest(ServiceRequestImplementor.java:802)
 at intradoc.server.Service.doRequest(Service.java:1890)
 at intradoc.server.ServiceManager.processCommand(ServiceManager.java:435)
 at intradoc.server.IdcServerThread.processRequest(IdcServerThread.java:265)
 at intradoc.server.IdcServerThread.run(IdcServerThread.java:160)
 at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
Caused By: java.net.SocketException: socket write error: Connection reset by peer.
 at jrockit.net.SocketNativeIO.writeBytesPinned(Native Method)
 at jrockit.net.SocketNativeIO.socketWrite(SocketNativeIO.java:46)
 at java.net.SocketOutputStream.socketWrite0(SocketOutputStream.java)
 at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
 at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
 at intradoc.common.DataStreamWrapperUtils.copyInStreamToOutputStream(DataStreamWrapperUtils.java:74)
 at intradoc.server.ServiceHttpImplementor.sendStreamResponse(ServiceHttpImplementor.java:2296)
 at intradoc.server.Service.doResponse(Service.java:2081)
 at intradoc.server.FileService.doResponse(FileService.java:1469)
 at intradoc.server.ServiceRequestImplementor.doRequest(ServiceRequestImplementor.java:802)
 at intradoc.server.Service.doRequest(Service.java:1890)
 at intradoc.server.ServiceManager.processCommand(ServiceManager.java:435)
 at intradoc.server.IdcServerThread.processRequest(IdcServerThread.java:265)
 at intradoc.server.IdcServerThread.run(IdcServerThread.java:160)
 at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
 at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
 at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
>

As I found with a small help of google above exception is a "typical" UCM broken pipe error, which is most often caused by the following:

• The network drops while the content server is attempting to communicate.
• The user cancels the request.
• The database is down or refuses a connection.

In the first reaction I thought:

In my cause it looks like TCP RST error when transferring data to the client application. The remote server can sent a RST packet to indicate an immediate dropping of the connection. This occurs when a packet is sent from UCM end of the connection but the other end does not recognize the connection. It will send back a packet with the RST bit set in order to forcibly close the connection. This can happen if the other side crashes and then comes back up, or if it calls close() on the socket while there is data from UCM in transit. Finally it is an indication that some of the data that are previously sent by UCM may not have been received.

After verifying the logs and code of my client applications I returned to start point of investigation. Client applications did not report any errors. There is also immposible that client side permemently drops connections.

I can't suspect network errors, cause client apps and UCM are running on the same physical machine.

Thereby I come up against a brick wall ...

Preview: JSF Components Wizard Beta will appear in early March

I would like to inform you that we are approaching the beta release of our new project: JSF Components Wizard. Although the current version of the product is prepared to release, we are still developing the project website. 

If nothing unexpected wouldn't happen, we will be ready in early March.