I would not use EJBs with the stack you are proposing. HTH
On 20 Dec 2012, at 15:00, titou10 titou10 wrote: > We are in the process of redefining our development stack and we need > to do it ASAP as we have a new big project (1 year+) starting very > soon > The current dev stack is (Used in more than a dozen application > currently in production) : > - WebSphere v7.0 (+JPA2 fp) > - JSF v1.2 (JSF RI from WAS) > - JPA2 (Hibernate v3.6) > - EJB v3.0 > - Seam v2 > Our projects are split into a WAR, a JPA module, an EJB module and > sometimes a "batch" module for nightly process outside WAS (it usess > the JPA and the EJB module) > > The target is : > - WebSphere v8.5 > - JSF 2.1 (MyFaces from WAS) > - JPA2 (OpenJPA from WAS or Hibernate v4) > - CDI (OWB from WAS) > - DeltaSpike > - ? EJB v3.1 > > For starting we'll use CODI instead of DeltaSpike and update to > DeltaSpike when a stable release will be available. It seems it should > not be a big problem as DeltaSpike seems very "close" to CODI > > Now the question: EJBs or no EJBs? this is the question... > With CDI + CODI/DS extensions, the benefit of using EJBs are not > obvious and we think about not using them anymore. Here are some > points > - EJB transaction managment: @Transactional annotations seems to solve this > - EJB security : our EJB are not called remotely and we don't puts > security on EJB methods anynway > - EJB pooling: not a real arguments as our applications are not *that* > in need of very high performance > - StateFul vs Stateless : use CDI/CODI scopes instead > - Stateful timeout: CDI/CODI ConversationScoped has timeouts > - Stateful+Stateless serialisation access: Don't know if CDI is handling this > - Resources injections (@Resources..) can be easily solved > I would like to know your opinions on this. > Thx > (I hope this is the good place to ask this kind of question, this post > could have been posted to the CODI or Seam 3 mailing lists too..)
