@EJB vs @Inject ?

Today, I dig into the internet about this question :

Should  I link my EJB Services to DAO / EJB persistance layer with
a) @EJB
OR
b) @Inject / à la CDI ?

THE source : Gavin King himself explains in that thread the detailed answer :

https://community.jboss.org/thread/179388#comment107817

It's amazing how Gavin is clear. Read the post fully : you'll have no doubt about the detailed answer :

@EJB is completely eliminated for local EJBs (except for backward compatibility). There are lots and lots of examples in the CDI spec and Weld documentation of using @Inject to inject local EJBs. And lots of times where I've explained that we strongly recommend the use of @Inject instead of @EJB to inject local EJBs. How could you possibly have missed that? Because you were too busy posting questions and brain-dead criticism instead of actually reading what is already out there?

Considering this excerpt, Gavin is touching the real problem here : I think I should improve the way I'm looking for answers ;)

On your side, I just hope that you didn't waste too much time on this question before finding this link. The noise on Stackoverflow  becomes anoying, hiding the real answers.

Setting up Activiti-CDI

If you follow the 'offical' user guide

http://www.activiti.org/userguide/#cdiintegration

You may be stuck on the following issue

org.activiti.engine.ActivitiException: Could not find an implementation of the org.activiti.cdi.spi.ProcessEngineLookup service returning a non-null processEngine. Giving up. at org.activiti.cdi.impl.ActivitiExtension.lookupProcessEngine(ActivitiExtension.java:106) at org.activiti.cdi.impl.ActivitiExtension.afterDeploymentValidation(ActivitiExtension.java:68)

And find many friends on the Internet with posts describing the same issue :

http://forums.activiti.org/content/activiti-cdi-exception
http://forums.activiti.org/content/issue-activiti-cdi-libraries

So we not just feeling alone; that is a good point ;)

Actually you may produce the Activiti Engine instance with a 'programatic' CDI OR a Spring activiti.cfg.xml. 
This is the complete JBoss setup on BitBucket :

https://bitbucket.org/meyerd/activiti-cdi-jbossas7.1.1-setup

The activiti user guide doesn't not explain clearly the two possibilities. Here there are :

(1) Default CDI producer starts up with org.activiti.cdi.impl.LocalProcessEngineLookup
   -> This is supposed to load the activiti.cfg.xml using Spring-context.
   -> You need to add /META-INF/beans.xml as usual for CDI.

(2) You may overload that default CDI producer writing your own (so that you get a chance to quit Spring some day).
    -> Provide a class that implements ProcessEngineLookup (see bitbucket resource).
    -> Define classname in /META-INF/services/org.activiti.cdi.spi.ProcessEngineLookup

Checking with the bitbucket sample code, (2) is OK, so what is wrong with (1) ?

The cause is contained within the first lines of the complete stacktrace : a NoClassDefFoundError (!)

Caused by: java.lang.NoClassDefFoundError: org/springframework/core/env/EnvironmentCapable

So actually, this is just a springframework version mismatch (!) The user guides still asks for adding spring-context3.0.3.RELEASE.
BUT currently, Activiti 5.12.1 defines spring 3.1.2...

With the correct version, activiti-CDI is stating as a charm !
These are the dependencies I used :

   

... Shall this post save your time ;)