Java EE 6 is already supported by Glassfish 3 and partially by JBoss 6.0 and Geronimo.

The adoption is harder to estimate - but it seems like Java EE 5 (6 is too early) and EJB 3 are gaining momentum. The w-jax conference is over - it was interesting to observe some indicators:

The first time ever there was an EJB 3 / Java EE 6 day. More important: it was very well attended.

Our EJB 3 / Java EE 6 table during the ballroom night (a kind of openspace) was (over)crowded. We already thought about occupying the JRuby table near us :-). All attendees had already EJB 3 experience. The participants introduced interesting projects from the biometric area, over health care system, to route planing and automation. This really surprised me.

Several projects are going to migrate their existing EJB 2 infrastructure to EJB 3. I had two conversations about migration from Spring to EJB 3. The reasons, however, were strategic and not technology driven.

Speakers signalized their interests as well. We had a really nice hall conversations about the EJB 3 programming model and its lightweight nature. I didn't expected it either. Even a Tomcat committer is starting to investigate EJB 3 :-).

My interactive hacking session (60 minutes - with Java EE 6) was attended by ~ 200 people in a room with 180 capacity :-). Btw. the average deployment time took <10ms (Glassfishv3b70 and NetBeans 6.8beta). This caused some interesting discussions afterwards.

At the very last day - I gave a workshop with the title "Java EE Patterns - Rethinking Best Practices" with 55 attendees (a new record). The majority of the attendees had already EJB 3 / Java EE 5 experience. I got really good questions about modularization, transactions, caching and performance during the day. My general observation is: developers, who already used EJB 3, really like it.

See also my tweets. The w-jax conference this year was very well attended (subjectively: more than last year). The conference was well organized with excellent food and location (Westin Grand Hotel in Munich...).

About modularization:
Is it right to say that modularization is easier to achieve in OSGi ?
OSGi hides everything unless you export the packages which should be exposed.
Additionally,OSGi 4.2 spec was introducing transaction API and distributed services. Is it possible that OSGi will replace EJB in the long term ?

I think it's easier to deploy OSGi applications on different OSGi platforms (Equinox, Felix, Knopflerfish) than deploying ejb applications on different application servers (Glassfish, JBoss, Geronimo) because of the JAR-hell.

"Is it right to say that modularization is easier to achieve in OSGi ?"

It depends: for technical applications like Eclipse - yes, for business applications it is not that easy.

"Additionally,OSGi 4.2 spec was introducing transaction API and distributed services. Is it possible that OSGi will replace EJB in the long term ?"

Sure. If it becomes as easy and convenient to use as EJB 3 / Java EE 5 it can really happen.

"I think it's easier to deploy OSGi applications on different OSGi platforms (Equinox, Felix, Knopflerfish) than deploying ejb applications on different application servers (Glassfish, JBoss, Geronimo) because of the JAR-hell."

There is no JAR-hell, except you are exaggerating with modularization... Java EE 5/6 is working pretty well. It really depends, whether you are needing dynamic or only static behavior. JDK 7 could change the game again...

This article really did turn the light on for me personally as far as this specific subject goes. Nonetheless there is one particular issue I am not necessarily too comfortable with so while I attempt to reconcile that with the actual main idea of the point, permit me see just what the rest of the subscribers have to say. Well done.