It seems like the huge, data driven, projects are either somehow completed, or were replaced by standard solutions. Especially in tougher times, even big enterprises are interesting in saving money and build software in more pragmatic ways.
These are actually good news. Often (almost always) you can implement the same functionality with only a fraction of the originally planned resources, patterns, architecture, with a few passionated developers.
In the same time Java EE became leaner and leaner, so that it is particularly interesting for smallest projects. In the Java EE 6 release it is hard to find a superfluous artifact. Although projects became leaner, there is still need for transactions, persistency, remoting (e.g. over REST), and concurrency. Exactly that is already addressed by EJB 3.1 + JAX-RS + JPA 2.0.
The small / smallest projects in particular, are built with plain web container - with a considerable overhead. You have to install, sometimes implement, everything by yourself, without any benefit. You could argue that the result is leaner, but you should measure the results and compare it to a full "Java EE 5/6" stack.
I was asked in the recent few months, whether it is possible to install an EJB 3.1 container inside tomcat, just for out-of-the-box management of transactions / concurrency. You will find the answer here. On the other hand developers (I also) were surprised by e.g. Glassfish v3 incremental deployment capabilities - even method signature changes were recognized correctly. I'm already curious about JBoss 5.2.0 Java EE 6 capabilities...
NEW workshop: Building HTML 5 Applications With React.js
On demand workshops: Java EE 7 Bootstrap, Effective Java EE 7, Java EE 7 Testing and NEW: Java EE 7 Microservices are available for streaming