Packing and booting activiti-cdi in an EAR

[actnewbie]

Hello!

i try to get activiti-cdi in an ear (a war, some ejbs, a pu jar and some libs) up and running and i seem to struggle with it.

What i tried first was to define dependencies in my wars pom and all activiti-cdi dependencies was therefore placed in the wars lib folder. The issue there was that it did not find the wars /WEB-INF/classes/META-INF/services/org.activiti.cdi.spi.ProcessEngineLookup and my implementation of the service interface. And, the service provided by activiti-cdi.jar was not found either. I found out that activiti-cdi is initialized using the ears classloader and therefore the wars libs and classes were not visible and thus the engine was not initialized.
The next attempt was to place activiti-cdi into the libs folder of the ear, there the engine was initialized, but due to the fact that the engine was initialized using cdi i was not able to hand in an EntityManagerFactory using a jndi lookup in the Spring based activiti.cfg.xml. The jndi context (the wars persistence-unit-ref) is not available in this phase where i can get a EntityManagerFactory. Using the jpaPersistenceUnitName property does not lead to the containers EntityManagerFactory to be used.
The next attempt, to initialize the engine programmatically using an ejb where i can use the PersistenceUnit annotation to get the EntityManagerFactory and set the other settings and build the engine resulted in an exception of the ActivitiExtension complaining that it could not initialize an engine because it does not find one. Yes, i did not place an META-INF/service or activiti.cfg.xml because i wanted to boot it programmatically. Is activiti-cdi simply not usable when the engine is initialized programmatically? And if the engine could be
initialized programmatically, how i can add it to cdi so that injection works? I thought of using ActivitiServices which can be injected because its ApplicationScoped to my ActivitiBooterEJB and set my constructed engine there to be in place when the Producer needs it.

Maybe somebody has some experience with Activiti initialization in an ear context where the webapp is jsf based and wants to use the comfort of cdi in combination with Activiti? There are already a lot of postings around explaining various deployment scenarios, but all of them are only a vew line of code or xml snippets and none covers the or a 'big picture'. And it seems my experiences are not so deep that i can apply those snippets to my environment successfully.

And, additionally, how about timer events? In what context are they fired? Is cdi usable there as well? If i imagine that the job executor of Activiti is run by a ThreadPool, i think cdi can not be available when a Activiti job is executed there. Till now i was only play with the basic samples where none of the JEE features mixed up things.

Thank u for some insights.

[meyerd]

Hi actNewbie,

thank you for your detailed report on your experience with EAR deployment.
I think your suggestion of providing the engine "manually" by using a setter on the ActivitiServices Bean is valid.

I wanted to factor out the bootstrapping of the process engine for some time now, this seams like a valid usecase.

Would you be willing to open a Jira?

And, additionally, how about timer events? In what context are they fired? Is cdi usable there as well? If i imagine that the job executor of Activiti is run by a ThreadPool, i think cdi can not be available when a Activiti job is executed there. Till now i was only play with the basic samples where none of the JEE features mixed up things.

Correct. If you use activiti cdi in an EE environment, the job executor will use a Java SE ThreadPool and threads will not be "EE threads", in the sense that they will not be decorated with the necessary context. Some consequences of this is that you cannot use @RequestScoped beans, since the thread has no concept of "Request". You might also not be able to use injection of EE-Resources like a PersistenceContext, EJBs…

BTW: The clean way of integrating the Job Executor with EE is to weite a JCA Connector and delegate to @MessageDriven Beans. We do this in camunda fox. We also offer consulting about how to use JSF with activiti and CDI.

[actnewbie]

Hi Daniel,

thanks for your reply. As you suggested i created an issue in Jira, although i was not sure what to write there
But i think with the reference to this thread you will remember what you meant with factore out the bootstrapping
of Activiti. http://jira.codehaus.org/browse/ACT-1275

And regarding the job executor, in fact all things which are done by a timer boundary event: Yes, from my experience
none of the nice and shiny features of JEE6 are usable there, which leads to a rather poor usability of timer events in
a JEE context, and the process design and especially the implementation needs to be fully aware of it.

If i understood correct what you meant with the JCA Connector and message driven beans: i can not use service tasks
which i implemented to be used in activiti:expressions which rely on Activitis CDI integration when such tasks are
triggered by a timer event? Instead i need to implement message driven beans and from that i can delegate to the
"CDI enabled" service tasks again?

Fortunately i have no problems using Activiti with CDI and JSF once the engine is up and running, the problems starts
when i start to user timer events. I thought EJB timers might be a possibility when starting processes, but they are
not very comfortable then using timer boundary events…

[naag]

Hi actNewbie,

did you find any solution to using CDI from timer events that you would like to share? I just ran into the same situation but have no clue yet as to what might be a possible solution (never worked on JCA before). For some reasons I do not want to switch to fox platform but would prefer to stick to a pure JBoss AS 7.

Regards,
Peter