[jBPM Users] - Re: nested forks
by saraswati.santanu
We can use our understanding about the bug to have a hack for the time being.
We see task1 twice because the transition to task1 is the default transition of the fork node. To stop task1 from appearing twice we need to make sure that it is not the default transition. Instead we can add a dummy node for default transition to make sure that the rest of the forked nodes behave properly. We can try a flow like this:
| <?xml version="1.0" encoding="UTF-8"?>
|
| <process name="ForumFlow2" xmlns="http://jbpm.org/4.0/jpdl">
|
| <start g="5,129,48,48" name="start1">
| <transition to="fork1"/>
| </start>
| <end g="957,121,48,48" name="end1"/>
|
| <task g="300,199,92,52" name="task2">
| <transition g="444,222:" to="join2"/>
| </task>
| <task g="334,329,92,52" name="task3">
| <transition g="679,358:" to="join1"/>
| </task>
| <task g="745,120,92,52" name="task8">
| <transition to="end1"/>
| </task>
| <task g="513,120,92,52" name="task9">
| <transition to="join1"/>
| </task>
| <task g="294,123,92,52" name="task1">
| <transition to="join2"/>
| </task>
| <fork g="211,130,48,48" name="fork2">
| <transition name="to java1" to="java1" g="235,68:-45,-18"/>
| <transition to="task1"/>
| <transition g="235,228:" to="task2"/>
| </fork>
| <join g="417,123,48,48" name="join2">
| <transition to="task9"/>
| </join>
| <join g="652,119,48,48" name="join1">
| <transition to="task8"/>
| </join>
| <fork g="93,126,48,48" name="fork1">
| <transition g="114,355:" to="task3"/>
| <transition to="fork2"/>
| </fork>
| <java name="java1"
| class="org.jbpm.test.DoNothingActivity"
| method="doNothing"
| g="301,41,92,52">
| </java>
| </process>
|
And a dummy java activity class
| package org.jbpm.test;
|
| /**
| * @author Santanu
| *
| */
| public class DoNothingActivity{
|
| public void doNothing() {
| System.out.println("Doing nothing");
| }
|
| }
|
This should give you correct list of tasks after the nested fork.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266409#4266409
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266409
16 years, 5 months
[jBPM Users] - Re: Problem moving from 4.1 to 4.2 using Spring configuratio
by RockerRocker
I am getting DBSession error due to this error --
| 16:14:51,625 INFO [STDOUT] Hibernate: select propertyim0_.KEY_ as KEY1_6_, propertyim0_.VERSION_ as VERSION2_6_, propertyim
| _.VALUE_ as VALUE3_6_ from JBPM4_PROPERTY propertyim0_ where propertyim0_.KEY_='next.dbid'
| 16:14:51,671 INFO [STDOUT] Hibernate: update JBPM4_PROPERTY set VERSION_=?, VALUE_=? where KEY_=? and VERSION_=?
| 16:14:51,734 INFO [DefaultCommandService] exception while executing command org.jbpm.pvm.internal.cmd.DeployCmd@1c0dc84
| org.hibernate.SessionException: Session is closed!
| at org.hibernate.impl.AbstractSessionImpl.errorIfClosed(AbstractSessionImpl.java:72)
| at org.hibernate.impl.SessionImpl.fireSave(SessionImpl.java:558)
| at org.hibernate.impl.SessionImpl.save(SessionImpl.java:550)
| at org.hibernate.impl.SessionImpl.save(SessionImpl.java:546)
| at org.jbpm.pvm.internal.repository.RepositorySessionImpl.deploy(RepositorySessionImpl.java:60)
| at org.jbpm.pvm.internal.cmd.DeployCmd.execute(DeployCmd.java:47)
| at org.jbpm.pvm.internal.cmd.DeployCmd.execute(DeployCmd.java:33)
| at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
| at org.jbpm.pvm.internal.spring.CommandTransactionCallback.doInTransaction(CommandTransactionCallback.java:50)
| at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:127)
| at org.jbpm.pvm.internal.tx.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:77)
| at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
| at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
| at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
| at org.jbpm.pvm.internal.repository.DeploymentImpl.deploy(DeploymentImpl.java:91)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266406#4266406
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266406
16 years, 5 months
[EJB] - caching the jndi call
by redlight
hi,
i got my ejb's up and running
in my web project i call them like that
| TraxManager TraxManager = (TraxManager)context.lookup("TraxService/remote");
|
in my web project i implement this call in each of managed beans, which no an optimal solution
so i try to do a generic method ==>
| import java.util.Collections;
| import java.util.HashMap;
| import java.util.Map;
| import java.util.Properties;
|
| import javax.ejb.EJBHome;
| import javax.naming.Context;
| import javax.naming.InitialContext;
| import javax.naming.NamingException;
|
| public class EJBHomeFactory {
|
| private static Map<String, Object> cache=Collections.synchronizedMap(new HashMap());; //used to hold references to EJBHomes/JMS Resources for re-use
|
|
| private EJBHomeFactory() throws ServiceLocatorException {
| try {
| //THIS DOESN'T GET EXECUTED :(
| cache = Collections.synchronizedMap(new HashMap());
| } catch (Exception e) {
| throw new ServiceLocatorException(e);
| }
| }
|
|
| public static Object lookupObject(String jndiName) throws ServiceLocatorException {
| EJBHome home = null;
| Context context = null;
|
| try {
| if (cache.containsKey((Object)jndiName)) {
| return cache.get(jndiName);
| } else {
| Properties props = new Properties();
| props.setProperty("java.naming.factory.initial","org.jnp.interfaces.NamingContextFactory");
| props.setProperty("java.naming.provider.url", "jnp://192.168.1.201:1099");
| props.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming");
| props.setProperty("jnp.socket.Factory", "org.jnp.interfaces.TimedSocketFactory");
| context = new InitialContext(props);
| //Object obj = context.lookup(jndiName);
| cache.put(jndiName, context.lookup(jndiName));
| }
| } catch (NamingException ne) {
| throw new ServiceLocatorException(ne);
| } catch (Exception e) {
| throw new ServiceLocatorException(e);
| }
| return cache.get(jndiName);
|
| }
|
|
|
| public Map<String, Object> getCache() {
| return cache;
| }
|
|
|
| public void setCache(Map<String, Object> cache) {
| EJBHomeFactory.cache = cache;
| }
|
|
| }
|
|
|
i test with 2 class, so that the first one , fill the map and the second should find a a map with the key of the jndi name , but it never found it,
| if (cache.containsKey((Object)jndiName)) {
| return cache.get(jndiName);
| }
is never executed
and thanks
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266404#4266404
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266404
16 years, 5 months
[Installation, Configuration & Deployment] - Prevent EJB deployment with sar
by Falcor1
Hi,
I have a jar file, lets call it ejb.jar, that contains both the interface and implementation of several stateless session beans. I typically deploy ejb.jar and one other jar containing stateless session beans in an ear. I am now working on a sar file that contains a single MBean, this MBean makes use of some of the stateless session beans in the ejb.jar. The sar that deploys my MBean can't be bundled in the ear with ejb.jar because it has to be flexible so that it can use the stateless session beans locally or talk to them remotely if they are deployed in a separate JBoss instance.
Since the sar may be running on a separate machine, it at least needs to have the interfaces for my EJBs on the classpath, so it has ejb.jar in the root of the sar. My problem is that when trying to deploy the sar, JBoss wants to deploy the EJBs also but fails because there is no persistence unit definition (it's usually found in the ear's META-INF). So is there a way to tell JBoss not to deploy the stateless session beans that it is finding in the sar? If not then I guess my next alternative would be to deploy this as a war, but that's not ideal in this case.
Thanks
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266401#4266401
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266401
16 years, 5 months
[JBoss Cache Users] - Re: Question about lockParentForChildInsertRemove - when to
by rsmysore
Thanks Brian. I think I kind of get the implication. However, arent getChildren or getChildrenNames methods considered read operations, and if so, with mvcc, the reads wouldnt need a write lock anyway. The read calls would return something that is based on isolation level (REPEATABLE_READ) in that case. So how would that affect the application.
By the way, the only use case for which we need getChildren is to retrieve all objects of a certain type that are cached. In that case, if we get a snapshot from before any of the current running transaction started, that is good enough. The more I think about it, I am pretty sure we don't need this in our application. But I am just trying to understand if there is something obvious that I am ignoring, like nodes getting lost or overwritten by different threads etc. For eg. just because I didnt set this option to true, if two threads insert two nodes into this parent at the same time, we would never run into a situation where one of the node is lost or overwritten by the other or something of that nature, right? I wouldn't think so, but just confirming. Now, its totally ok if the read calls at around the same time don't include this/these node because of the transaction being not committed yet.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4266399#4266399
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4266399
16 years, 5 months