» Demise of POJOs ?

As a comment to Adam Bien's "demise of POJOs", as his blog doesn't allow more then 1000 characters in comments :) I have other gripes with EJB than their weight (or lack thereof). To me, as a developer of frameworks and more or less generic components used by many developer teams, the JEE spec lacks a great amount of stuff once you go beyond the usual business logic + some database type of application. Clustering ? Not even mentioned in the JEE spec. Cluster membership (have a cluster node uniquely identify itself), sending messages to all cluster nodes (have to resort to proprietary replicated JMX), etc... Execute initialization/warmup code at startup ? Still have to resort to the servlet trick, or use proprietary mechanisms. AOP ? Dependency Injection ? only very lightly supported in EJB 3.0, clearly not sufficient for more complex approaches. Security ? JAAS ? ouch. To me EJB is a great facade technology for remoting, EJB 3 is a nice managed component model for applications where it fits... business logic, JDBC, web or Swing UI, but nothing more advanced (from a purely technical point of view) where you need a lot of flexibility or cluster awareness. And yes, while Spring doesn't help wrt clustering, it provides a much more flexible and fine-grained model to manage beans. I mean, this isn't theoretical or fanboyism, I clearly encounter situations where a fine-grained control is needed, every single day. So while EJB can be a good approach for business application level developers, especially when you need to fence them into a scarce technical frame, it just doesn't provide enough features nor flexibility for frameworks or components that need a fine grained control over lifecycle/deployment, cross-cutting concerns (security, audit logging, ...), clustering, etc.