cancel
Showing results for 
Search instead for 
Did you mean: 

Accessing jndi in activiti

chilopoda
Champ in-the-making
Champ in-the-making
I have a problem when accessing jndi in activiti. I have read the articles : http://forums.activiti.org/content/persistence and http://forums.activiti.org/content/jdbc-datasource-out-jndi but still no success. We use hibernate with the jpa specification for our project. I'm able to execute hibernate queries when using Java Service Task, also I'm able to achieve the same from a Task Listener this way:


private BeanManager getBeanManager() {
try {
return (BeanManager) InitialContext.doLookup("java:comp/BeanManager");
}
catch (final NamingException e) {
e.printStackTrace();
}
return null;
}

@SuppressWarnings("unchecked")
private T lookup(final Class clazz) {
final BeanManager bm = getBeanManager();
final Iterator> iter = bm.getBeans(clazz).iterator();
if (!iter.hasNext()) {
throw new IllegalStateException("CDI BeanManager cannot find an instance of requested type " + clazz.getName());
}
final Bean bean = (Bean) iter.next();
final CreationalContext ctx = bm.createCreationalContext(bean);
return (T) bm.getReference(bean, clazz, ctx);
}



and getting the entitymanager this way:


EntityManagerFactory emf = null;
EntityManager em = null;
BeanManager bm = getBeanManager();
emf = lookup(EntityManagerFactory.class);
System.out.println("Contents of emf ::::"+emf);
em = emf.createEntityManager();



With the entity manager in place i can then execute hibernate statements and queries.

Now the problem comes in when i try the same after a trigger from a timer event e.g the timeCycle, i'm not able to access the jndi.
The exception i get is : javax.naming.NameNotFoundException: java:comp/BeanManager. We do not use spring for our application.
My config file looks like this:


<?xml version="1.0" encoding="UTF-8"?>
<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.engine.impl.cfg.StandaloneProcessEngineConfiguration">
    <property name="dataSourceJndiName" value="java:comp/BeanManager" />
    <property name="transactionsExternallyManaged" value="true" />
    <property name="history" value="audit" /> 
    <property name="jobExecutorActivate" value="true" />
    <property name="jdbcUrl" value="jdbc:oracle:thin:@localhost:1521:xe" />
    <property name="jdbcDriver" value="oracle.jdbc.driver.OracleDriver" />
    <property name="jdbcUsername" value="fm" />
    <property name="jdbcPassword" value="fm123" />
    <property name="databaseSchemaUpdate" value="true" />
  </bean>
</beans>



Any help is highly appreciated. Thank you good people.
2 REPLIES 2

frederikherema1
Star Contributor
Star Contributor
The API-calls you trigger, run inside the thread you call them from. Any resources specific to the environment are available (eg lookup in JNDI). The job-executor, on the other hand, executes job in a single thread that is part if an internal thread-pool. These threads don't run in the same context as the API-calls you do.

You need to extends the JobExecutor and, prior to actually executing a job, make sure the thread has access to the resources it needs. not sure how you set this up for your usecase. Anyway, some piece of code (prolly in the framework you're using) makes sure JNDI-calls are possible from the threads. If you're not using anything special, It might be that the container-thread handling the request (eg. tomcat) makes sure the treads have access to the JNDI.

To make a long story short: Extend JobExecutor and override the right class (perhaps even ExecuteJobCmd) to wrap the running of the job with your environment initialisation. Does that make sense?

Hi, frederikheremans,
Thank you for the quick response. The statement above makes sense especially:
<blockquote>The job-executor, on the other hand, executes job in a single thread that is part if an internal thread-pool. These threads don't run in the same context as the API-calls you do.</blockquote> I think my problem is about the context, i.e when there is a trigger from the jobexecutor, I loose the context and therefore not able to access the JNDI.
As for your suggestion, <blockquote>You need to extends the JobExecutor and, prior to actually executing a job, make sure the thread has access to the resources it needs. not sure how you set this up for your usecase.</blockquote> I think this must be the solution but the problem I do not know how to exactly implement this. I'm still new in java but very much interested and always willing to try new stuff. I just can't figure out why if i just use a service task or tasklistener without the triggers I'm able to execute any queries but if i call say a service task as a result of a trigger, i just get an error and cant access the JNDI.
Could you please give me step by step guideline? alternatively, i can also attach any files you may need for further clarification.
For our environment we use JbossAS 7 and stripes framework. Thanks.