CDI problem in WebLogic

[petter_f]

Hi all,

We are currently trying to refactor our Activiti module into using CDI and I've run into a number of problems. Now, reverting back to step 1 I get the following error:

weblogic.management.DeploymentException: 
   at weblogic.application.internal.BaseDeployment.throwAppException(BaseDeployment.java:123)
   at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:239)
   at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:61)
   at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:158)
   at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
   at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:207)
   at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:96)
   at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:229)
   at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:747)
   at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1216)
   at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:250)
   at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:159)
   at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171)
   at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:13)
   at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:46)
   at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
   at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
   at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused By: org.jboss.weld.exceptions.DeploymentException: Exception List with 1 exceptions:
Exception 0 :
java.lang.IllegalStateException: CDI BeanManager cannot find an instance of requested type org.activiti.cdi.impl.util.ActivitiServices
   at org.activiti.cdi.impl.util.ProgrammaticBeanLookup.lookup(ProgrammaticBeanLookup.java:33)
   at org.activiti.cdi.impl.ActivitiExtension.lookupProcessEngine(ActivitiExtension.java:110)
   at org.activiti.cdi.impl.ActivitiExtension.afterDeploymentValidation(ActivitiExtension.java:68)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
….snip‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

What I have done is

enabled CDI by adding a beans.xml fil in META_INF

changed my maven dependency to activiti-cdi instead of activiti-engine

My activiti.cfg.xml is left unchanged:

   <jee:jndi-lookup jndi-name="ActivitiDS" id="dataSource" />
   <bean id="processEngineConfiguration" class="org.activiti.engine.impl.cfg.StandaloneProcessEngineConfiguration">
      <property name="databaseSchemaUpdate" value="false" />
      <property name="dataSource" ref="dataSource" />
      <property name="jobExecutorActivate" value="true" />
      <property name="transactionsExternallyManaged" value="true" />
      <property name="jdbcDriver" value="oracle.jdbc.driver.OracleDriver" />
   </bean>   ‍‍‍‍‍‍‍‍

My question is basically; does this have to do with the fact that I'm deploying as an ear in weblogic? If so, what measures do I have to take in order to get it to work?

Removing the beans.xml file from the deployment makes everything worka "the old way" again.

I do realize that in the "final" CDI configuration I should also use org.activiti.cdi.CdiStandaloneProcessEngineConfiguration as class for the processEngineConfiguration. Just trying to isolate my problem here…

Thanks in advance,
/Petter

[jbarrez]

I assume you also have to change the process engine configuration to CdiStandaloneProcessEngineConfiguration or CdiJtaProcessEngineConfiguration

[petter_f]

Yes, currently using CdiJtaProcessEngineConfiguration, see config file below:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jee="http://www.springframework.org/schema/jee"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-2.5.xsd">

<jee:jndi-lookup jndi-name="weblogic.transaction.TransactionManager" id="transactionManager" />
<jee:jndi-lookup jndi-name="ActivitiDS" id="dataSource" />

<bean id="processEngineConfiguration" class="org.activiti.cdi.CdiJtaProcessEngineConfiguration">
  <property name="transactionManager" ref="transactionManager" />
  <property name="databaseSchemaUpdate" value="false" />
  <property name="dataSource" ref="dataSource" />
<!–   <property name="jobExecutorActivate" value="true" /> –>
  <property name="transactionsExternallyManaged" value="true" />
  <property name="jdbcDriver" value="oracle.jdbc.driver.OracleDriver" />
</bean>
</beans>

[jbarrez]

So did you make a typo in your original post, because you stated that 'My activiti.cfg.xml is left unchanged:' and posted one without the cdi config.

So, where is the config you posted now is living, and how are you accessing the process engine created that way?

[petter_f]

Sorry, I was fiddling around with the config file and accidentally posted one with the Cdi configuration. Both configurations generate the same error however….

As for the access of the ProcessEngine instance, it is done as follows:

ProcessEngineConfiguration.createProcessEngineConfigurationFromResourceDefault().buildProcessEngine();
Regards,
/Petter

[jbarrez]

Okay, but where is this code called?

In CDI, shouldn't you configure these beans somehow. Now you are circumventing the cdi containter, it seems to me.

See the userguide:

The cdi extension needs to get access to a ProcessEngine. To achieve this, an implementation of the interface org.activiti.cdi.spi.ProcessEngineLookup is looked up at runtime. The cdi module ships with a default implementation named org.activiti.cdi.impl.LocalProcessEngineLookup, which uses the ProcessEngines-Utility class for looking up the ProcessEngine. In the default configuration ProcessEngines#NAME_DEFAULT is used to lookup the ProcessEngine. This class might be subclassed to set a custom name. NOTE: needs an activiti.cfg.xml configuration on the classpath.

Activiti cdi uses a java.util.ServiceLoader SPI for resolving an instance of org.activiti.cdi.spi.ProcessEngineLookup. In order to provide a custom implementation of the interface, we need to add a plain text file named META-INF/services/org.activiti.cdi.spi.ProcessEngineLookup to our deployment, in which we specify the fully qualified classname of the implementation.

[petter_f]

It actually seems like we have a general problem with running CDI enabled modules in our WebLogic. We are currently trying to resolve those issues using a very simple test app without involving Activiti at all. Will update this thread once that has been completed. Thanks for your time so far!

Regards,
/Petter

[petter_f]

Ok, update: I do have a test war that works in Jboss 7.1.1 and in Glassfish 3.1.2.2 but fails in Weblogic 12c (12.1.1.0) with the following error:
org.activiti.engine.ActivitiException: Could not find an implementation of the org.activiti.cdi.spi.ProcessEngineLookup service returning a non-null processEngine. Giving up.
I did run into the jersey/cdi problem (java.io.NotSerializableException: com.sun.jersey.server.impl.cdi.CDIExtension) and circumvented by adding
-Dcom.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true
to the start script of the managed node….

Seems to me that it is indeed a problem with Weblogic and not with Activiti. But if anyone has experienced a similar problem (and resolved it) I would be thrilled to know how.

As a side note, my current config (activiti.cdg.xml) is as follows:
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans   http://www.springframework.org/schema/beans/spring-beans.xsd">

  <bean id="processEngineConfiguration" class="org.activiti.cdi.CdiStandaloneProcessEngineConfiguration">
 
    <property name="jdbcUrl" value="jdbc:h2:mem:activiti;DB_CLOSE_DELAY=1000" />
    <property name="jdbcDriver" value="org.h2.Driver" />
    <property name="jdbcUsername" value="sa" />
    <property name="jdbcPassword" value="" />
   
    <property name="databaseSchemaUpdate" value="true" />
   
    <property name="jobExecutorActivate" value="false" />
   
  </bean>

</beans>
and the engine initialization is performed from a JAX-RS class as follows:
@Path("/test")
@RequestScoped
public class MyResource {
@Inject
private ProcessEngine pe;
…..
I have a hunch that this may have something to do with the fact that the spring depencies brings in jars with non-compliant version names like "3.1.0.RELEASE". I don't know if the Weblogic appc chokes on jars like that, but if anyone can give me hint on that as well I would appreicate it.

Thanks for your time,
/Petter

[petter_f]

Update again:

I have come to the conclusion that this is a general classloading problem in WebLogic and hence has nothing to do with Activiti as such.

For the interested:
The ServiceLoader lookup on ProcessEngingeLookup instances in ActivitiExtension fails in WebLogic due to the fact that the system class loader does not see the LocalProcessEngineLookup…Fixed that by providing the class loader for the ActivitiExtension class in the load call but then stumbled on the subsequent programmatic lookup for a ActivitiServices instance..Similar problem here, the injected BeanManager instance does not see the ActivitiServices bean instance…

Giving this up for now and hoping for the next version of WebLogic to fix these problems.

Regards,
/Petter

[jbarrez]

Thanks for posting this back. Interesting. Sad it just doesn't work