Just wondering the trend of JEE5 projects these days w.r.t to application framework. With the EntityManager interface , JEE5 itself is easily configurable for persistence.
Also the annotations has made life simple with EJB3.0. Is there a need to go for Hibernate+Spring IOC if JEE5 provides these capabilities.?
With the EntityManager interface , JEE5 itself is easily configurable for persistence
Yep. Persistence Unit and annotated POJOs are the equivalent to Hibernate config files and BOs, EntityManager takes the place of the Hibernate session. In fact, most of the classes in the javax.persistence package are annotations. But keep in mind that annotations are compiled, and config files are not. I would say that annotations are OK from the developer POV, but config files are better from the integration/test POV.
Is there a need to go for Hibernate+Spring IOC if JEE5 provides these capabilities.?
As usual, it depends on your needs...
Afaik, JEE5 injection (@PersistenceContext, @EJB...) works only in container managed classes (EJB, servlet...), so if you want to inject JEE dependencies in other types of resources, frameworks such as Spring are still usefull, and especially whith the Spring 2.5 JEE namespace: you can declare a local/remote ejb from a business interface in one line of XML.
With respect to persistence, you'll have to use a JPA engine (essentially the one of your AS), so if you use JBoss 5 AS, you're in fact using Hibernate for JPA under the hood (Glassfish uses EclipseLink...)
I would say stick with the JEE norm whenever you can, more importantly if your client want a full Sun (soon to be Oracle) JEE stack (code your application against JPA and not Hibernate).
Agreed, JPA 1.0 lacks some interesting features found in Hibernate (notably the Criteria API), but JPA 2.0 and JEE6 are not far and will address this.
EJB 3 is certainly a handsome improvement from the past, but it doesn't exclude the need for a good framework like Spring.
I typically recommend JSF, EJB3 and Seam as a development platform, framework and philosophy. It's an easy sell to an architecture review board on a bank or insurance company. Smaller implementations might prefer something even more lightweight as there is a point where you get to 'framework-bloat.'