nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Activiti without CDI?

rsaunder

I've hit a roadblock on the engine lookup. I've stepped through Activiti and found that it's captured the correct classname from META-INF/Services. The loader also has a complete list of classes, but somehow the provider iterator comes back empty.

Is it possible to instantiate an engine without CDI c.g. ProcessEngine processEngine = ProcessEngines.getDefaultProcessEngine();

Tried this, it's still doing an engine lookup and failing. Also tried disabling Weld in Firefly without result.

Find more posts tagged with

Comments

yvoswillens

Hi,

take a look here http://activiti.org/javadocs/org/activiti/engine/ProcessEngineConfiguration.html

F.e.
ProcessEngine processEngine = ProcessEngineConfiguration
.createStandaloneProcessEngineConfiguration()
.buildProcessEngine();

Regards,

Yvo

rsaunder

Meanwhile, I've stepped through the code and found the problem. CDI happens prior to deployment. But when Activiti gets the system resource for the services directory, it's pointing at the future location on the server. Having no custom class names, the engine lookup returns "default". For some reason, default is returning a null process engine.

In the mean time, will try what you suggest.

rsaunder

Tried instantiating an engine by hand. The problem is, CDI still runs prior to deployment and throws a "null engine" exception. So I never get to the instantiation. Is there some way to turn off CDI? Removing beans.xml doesn't help, nor does commenting out the "Weld" portions of Wildfly's standalone.xml.

Here is the file it's looking for, which has a few unexpected twists.

vfs:/C:/Users/User/wildfly-8.2.0.Final/standalone/deployments/BorderCrossing.war/WEB-INF/lib/activiti-cdi-sources.jar/META-INF/services/org.activiti.cdi.spi.ProcessEngineLookup

rsaunder

Here's where I am now. Replaced the engine lookup by simple creation in ActivitiExtension (5.17.0) as follows. Am getting aruntime error. Any suggestions?

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:34)
at org.activiti.cdi.impl.ActivitiExtension.lookupProcessEngine(ActivitiExtension.java:122)
at org.activiti.cdi.impl.ActivitiExtension.afterDeploymentValidation(ActivitiExtension.java:71)

Here's the code:

protected ProcessEngine lookupProcessEngine(BeanManager beanManager) {
    ServiceLoader<ProcessEngineLookup> processEngineServiceLoader = ServiceLoader.load(ProcessEngineLookup.class);
    Iterator<ProcessEngineLookup> serviceIterator = processEngineServiceLoader.iterator();
    List<ProcessEngineLookup> discoveredLookups = new ArrayList<ProcessEngineLookup>();
    while (serviceIterator.hasNext()) {
      ProcessEngineLookup serviceInstance = (ProcessEngineLookup) serviceIterator.next();
      discoveredLookups.add(serviceInstance);
    }

    Collections.sort(discoveredLookups, new Comparator<ProcessEngineLookup>() {
      public int compare(ProcessEngineLookup o1, ProcessEngineLookup o2) {
        return (-1)*((Integer)o1.getPrecedence()).compareTo(o2.getPrecedence());
      }
    });

    ProcessEngineLookup processEngineLookup = null;
    ProcessEngineConfiguration processEngineConfiguration = CdiStandaloneProcessEngineConfiguration.createStandaloneProcessEngineConfiguration()
.setJobExecutorActivate(true)
.setDatabaseSchemaUpdate("true")
.setJdbcDriver("org.postgresql.Driver")
.setJdbcUrl("jdbc

ostgresql://localhost:5432/SOA_PoC")
.setJdbcUsername("postgres")
.setJdbcPassword("admin");
ProcessEngine processEngine = processEngineConfiguration.buildProcessEngine();

//    for (ProcessEngineLookup processEngineLookup : discoveredLookups) {
//      processEngine = processEngineLookup.getProcessEngine();
//      if(processEngine != null) {
//        this.processEngineLookup = processEngineLookup;
//        logger.debug("ProcessEngineLookup service {} returned process engine.", processEngineLookup.getClass());
//        break;
//      } else {
//        logger.debug("ProcessEngineLookup service {} retuned 'null' value.", processEngineLookup.getClass());
//      }
//    }

//    if(processEngineLookup == null) {
//      throw new ActivitiException("Could not find an implementation of the org.activiti.cdi.spi.ProcessEngineLookup service " +
//        "returning a non-null processEngine. Giving up.");
//    }


    ActivitiServices activitiServices = ProgrammaticBeanLookup.lookup(ActivitiServices.class, beanManager);
    activitiServices.setProcessEngine(processEngine);

    return processEngine;
}

rsaunder

This problem turns out to be server-specific. It lives in Wildfly 8.0.2. In the latest TomEE Plume, it runs correctly.

jbarrez

Doesn't removing activiti-cdi jar would solve the problem?