Currently we look up an implementation of ProcessEngineLookup on reception of the AfterDeploymentValidation event from the container. We have a set of implementations which are all marked @Alternative (i.e. disabled)
When using activiti-cdi, one has to "enable" one of these implementations (or provide a different one, for that matter).
There is a couple of problems with this:
Per CDI-spec, one cannot enable an @Alternative Bean Class form a different bean archive. However, the notion of bean archive is container-specific, for example, weld-servlet uses a "flat" deployment (ie. all bean archives are merged into one big bean archive, while containers like Jboss 7 use a hierarchical bean archive structure mirroring the deployment structure of the container.) The consequence is that one has to use a different strategy for enabling a ProcessEngineLookup implemenation on Tomcat than on Jboss. (for instance)
In practice, the semantics of instantiating a bean in this phase (AfterDeploymentValidation) seem not to be well defined. In particular, not all EE-contexts seem to be setup in an application server. It seems that it is too "early" or we are on the wrong Thread, to look up beans properly at that stage.
Change this in the sense, that
We use a java.util.ServiceLoader like SPI
If a client jar provides an implementation, it has to declare it in a META-INF/services/org.activiti.cdi.spi.ProcessEngineLookup file
implementations have a precedence
The LocalProcessEngineLookup implementation is activated by default.