The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

PeteTh (4) [Avatar] Offline
Hi Chris / Anyone,

We are using EJB3 and therefore I'm interested in being able to inject dependencies to other POJOs into our @Stateless EJB3 Beans.

The options seem to be :-

1) As in your book 'Exposing Spring beans via JNDI' page 393' using the @Resource, but this looks quite involved.

2) Your blog entry 'Migrating to Spring 2: Part 3 - injecting dependencies into entities'
this uses AspectJ to intercept calls using @Configurable annotation - probably using load time weaving.

3) In 'Spring and EJB 3.0 in Harmony' the author illustrates (see ) another approach, this I understand uses the combination of a JBoss spring deployer and custom Spring Interceptor.

The interceptor (I think) can be used in one of two ways :-
- Using JBoss AOP, where a new aspect picks up on a new @Spring annotations in the EJB3 Stateless Bean (a JBoss specific approach)
- Using EJB3 standard @Interceptors tag can be used (works with any EJB3 container).

Anyway, having read all three of these I'm now unsure what is the best approach !

We are using JBoss so a JBoss specific approach is ok, but I guess if the approach is portable it useful for future projects

Any thoughts appreciated
ceracm (113) [Avatar] Offline
Re: Inject POJOs into EJB3 @Stateless Beans using Spring - best approach ?

None of these approaches are ideal. I would do a quick proof of concept with each of them and see which one you like the most (or dislike the least smilie ).

If you really need to DI POJOs into your facades I would consider simplifying your application using real POJOs+Spring TxnManagement instead of EJB3 session beans.

Unless, of course, EJB3 session beans provide a some feature that essential to your application such as support for distributed transactions initiated by a remote client.