[JBoss JIRA] Commented: (JBPM-424) JBPM on DB2: ModuleInstances in the instance variable of ProcessInstance don't get persisted correctly
by archana archana (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-424?page=comments#action_12415537 ]
archana archana commented on JBPM-424:
--------------------------------------
hjh
> JBPM on DB2: ModuleInstances in the instance variable of ProcessInstance don't get persisted correctly
> ------------------------------------------------------------------------------------------------------
>
> Key: JBPM-424
> URL: http://jira.jboss.com/jira/browse/JBPM-424
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.0.1
> Environment: JBoss 4.0.3 with JBM 3.0.1 and EJB's (spec 2.0, generated by XDoclet) on Windows XP, DB2 on image (VMWare) of Win2K
> Reporter: Frank Verbruggen
> Assigned To: Tom Baeyens
> Priority: Blocker
>
> I have a SLSB that facades for the JBPM,
> it is called FacadeBean (Remote Interface called: Facade),
> and it offers a set of functions:
> ** FacadeBean **
> /**
> * Business method
> * @ejb.interface-method view-type = "both"
> * @ejb.transaction type = "Required"
> */
> public Long createInstance(java.lang.String procesDefinitionName) {
> JbpmSession jbpmSession = null;
> try {
> JbpmSessionFactory factory = JbpmSessionFactory.getInstance();
> jbpmSession = factory.openJbpmSession();
> ProcessDefinition procdef = jbpmSession.getGraphSession()
> .findLatestProcessDefinition(procesDefinitionName);
> ProcessInstance procinst = procdef.createProcessInstance();
> log.debug("New process instance created (" + procinst.getId() + ") based on latest definition of " + procesDefinitionName);
> String size = procinst.getInstances() == null ? "null" : "" + procinst.getInstances().size();
> log.debug("instances of processInstance: " + size);
> if (procinst.getInstances() != null) {
> Iterator it = procinst.getInstances().values().iterator();
> while (it.hasNext()) {
> log.debug("Next processInstance.instance: " + it.next());
> }
> }
> return new Long(procinst.getId());
> } finally {
> jbpmSession.close();
> }
> }
>
> /**
> * Business method
> * @ejb.interface-method view-type = "both"
> * @ejb.transaction type = "Required"
> */
> public void sendSignal(java.lang.Long processInstanceId) {
> JbpmSession jbpmSession = null;
> try {
> JbpmSessionFactory factory = JbpmSessionFactory.getInstance();
> jbpmSession = factory.openJbpmSession();
> log.debug("Loading processInstance " + processInstanceId);
> ProcessInstance instance = jbpmSession.getGraphSession().loadProcessInstance(processInstanceId.longValue());
> log.debug("ProcessInstance " + processInstanceId + " loaded.");
> ContextInstance contextInstance = instance.getContextInstance();
> log.debug("Context retrieved");
> String traceLog = (String) contextInstance.getVariable(CTX_INSTANCE_TRACE);
> String traceLine = instance.getRootToken().getNode().getName() + "\n";
> if (traceLog == null) {
> contextInstance.createVariable(CTX_INSTANCE_TRACE, traceLine);
> } else {
> contextInstance.setVariable(CTX_INSTANCE_TRACE,
> traceLog +
> traceLine);
> }
> instance.signal();
> } finally {
> jbpmSession.close();
> }
> }
>
> /**
> * Business method
> * @ejb.interface-method view-type = "both"
> */
> public Boolean hasEnded(java.lang.Long processInstanceId) {
> JbpmSession jbpmSession = null;
> try {
> JbpmSessionFactory factory = JbpmSessionFactory.getInstance();
> jbpmSession = factory.openJbpmSession();
> ProcessInstance instance = jbpmSession.getGraphSession().loadProcessInstance(processInstanceId.longValue());
> return new Boolean(instance.hasEnded());
> } finally {
> jbpmSession.close();
> }
> }
>
> /**
> * Business method
> * @ejb.interface-method view-type = "both"
> */
> public String getTraceLog(java.lang.Long processInstanceId) {
> JbpmSession jbpmSession = null;
> try {
> JbpmSessionFactory factory = JbpmSessionFactory.getInstance();
> jbpmSession = factory.openJbpmSession();
> ProcessInstance instance = jbpmSession.getGraphSession().loadProcessInstance(processInstanceId.longValue());
> ContextInstance contextInstance = instance.getContextInstance();
> return (String) contextInstance.getVariable(CTX_INSTANCE_TRACE);
> } finally {
> jbpmSession.close();
> }
> }
> ** End of Listing **
> Now, I want to run the following code:
> ** Begin Listing **
> private static String runProcess(Facade facade, String processDefinitionName) throws RemoteException {
> StringBuffer buffer = new StringBuffer();
> try {
> Long procId = facade.createInstance(processDefinitionName);
> buffer.append("Process gecreerd met id " + procId + "\n");
> while (!facade.hasEnded(procId).booleanValue()) {
> facade.sendSignal(procId);
> }
> buffer.append(facade.getTraceLog(procId));
> } catch (Throwable t) {
> buffer.append(t);
> }
> return buffer.toString();
> }
> ** End of Listing **
> The instance gets created and I see the following four lines in my debug log:
> ** Begin Listing **
> 2005-10-27 11:25:49,483 DEBUG [nl.inkassounie.focus.jbpm.FacadeBean] New process instance created (141) based on latest definition of inkassounie_uninterruped_flow
> 2005-10-27 11:25:49,483 DEBUG [nl.inkassounie.focus.jbpm.FacadeBean] instances van processInstance: 2
> 2005-10-27 11:25:49,483 DEBUG [nl.inkassounie.focus.jbpm.FacadeBean] Next processInstance.instance: org.jbpm.taskmgmt.exe.TaskMgmtInstance@1a498b6
> 2005-10-27 11:25:49,483 DEBUG [nl.inkassounie.focus.jbpm.FacadeBean] Next processInstance.instance: org.jbpm.context.exe.ContextInstance@1ddd83c
> ** End of Listing **
> So I know at creation time that the instances variable holds 2 values.
> They exist in the DB
> BUT
> the NAME_ column in the JBPM_MODULEINSTANCE table does not contain any values (the other columns do)
> therefore the Map instances in ProcessInstance cannot be reformed from the DB.
> The error I recieved:
> ** Begin Listing **
> 11:25:53,295 ERROR [LogInterceptor] RuntimeException in method: public abstract void nl.inkassounie.focus.jbpm.Facade.sendSignal(java.lang.Long) throws java.rmi.RemoteException:
> org.hibernate.HibernateException: null index column for collection: org.jbpm.graph.exe.ProcessInstance.instances
> at org.hibernate.persister.collection.AbstractCollectionPersister.readIndex(AbstractCollectionPersister.java:652)
> at org.hibernate.collection.PersistentMap.readFrom(PersistentMap.java:222)
> at org.hibernate.loader.Loader.readCollectionElement(Loader.java:994)
> at org.hibernate.loader.Loader.readCollectionElements(Loader.java:635)
> at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:579)
> at org.hibernate.loader.Loader.doQuery(Loader.java:689)
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:223)
> at org.hibernate.loader.Loader.loadCollection(Loader.java:1916)
> at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:36)
> at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:520)
> at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:60)
> at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1562)
> at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:343)
> at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:85)
> at org.hibernate.collection.AbstractPersistentCollection.readElementByIndex(AbstractPersistentCollection.java:160)
> at org.hibernate.collection.PersistentMap.get(PersistentMap.java:127)
> at org.jbpm.graph.exe.ProcessInstance.getInstance(ProcessInstance.java:136)
> at org.jbpm.graph.exe.ProcessInstance.getContextInstance(ProcessInstance.java:163)
> at nl.inkassounie.focus.jbpm.FacadeBean.sendSignal(FacadeBean.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
> at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
> at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:149)
> at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:154)
> at org.jboss.webservice.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:54)
> at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
> at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:106)
> at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:335)
> at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166)
> at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:153)
> at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
> at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
> at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
> at org.jboss.ejb.Container.invoke(Container.java:873)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:805)
> at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:406)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
> at sun.rmi.transport.Transport$1.run(Transport.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> at java.lang.Thread.run(Thread.java:595)
> ** End of Listing **
> I don't know how to fix this, but atm it is a showstopper for a big customer.
> Plz let me know if this is a bug for JBPM (fverbruggen(a)solidium.nl).
> I am inclined to believe it is since the exact same thing happens in my MySQL test DB (which resides on my local system)
> Kind regards,
> Frank Verbruggen
> Software Architect
> Solidium ( Ordina J-Solutions )
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months
[JBoss JIRA] Created: (JBPM-1183) Node/State don't provide any support for Conditions on Transitions
by Britt Miner (JIRA)
Node/State don't provide any support for Conditions on Transitions
------------------------------------------------------------------
Key: JBPM-1183
URL: http://jira.jboss.com/jira/browse/JBPM-1183
Project: JBoss jBPM
Issue Type: Bug
Components: Core Engine
Affects Versions: jBPM jPDL 3.2.2
Reporter: Britt Miner
Assigned To: Tom Baeyens
Node and State don't provide any preliminary check for conditions provided on transitions. No check is performed until the transition is signaled, at which point the process will barf if the condition evaluates to false. Regardless if a person "should" be using transition conditions in Node or State, the schema allows it, the documentation doesn't forbid it, and the current behavior of a Transition element in the jpdl is inconsistent. The fix to make everything consistent is fairly simple--only org.jbpm.graph.def.Node needs to be altered:
// BRITT --replace the following line with the code below
// to check conditions before selecting the transition to take...
//leave(executionContext); //original line
boolean hasTransitioned = false;
Iterator iter = leavingTransitions.iterator();
while (iter.hasNext()) {
Transition candidate = (Transition) iter.next();
String conditionExpression = candidate.getCondition();
if (conditionExpression != null) {
Object result = JbpmExpressionEvaluator.evaluate(conditionExpression, executionContext);
if (Boolean.TRUE.equals(result)) {
leave(executionContext, candidate);
hasTransitioned = true;
break;
}
} else {
leave(executionContext, candidate);
hasTransitioned = true;
break;
}
}
if (!hasTransitioned) {
this.getDefaultLeavingTransition().removeConditionEnforcement();
log.warn("All transition conditions have evaluated to 'false'. Taking the default transition.");
leave(executionContext, this.getDefaultLeavingTransition());
}
// --BRITT
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months
[JBoss JIRA] Updated: (JBPM-1024) Serializable variables are not being deserialized when retrieved from process
by Alejandro Guizar (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-1024?page=all ]
Alejandro Guizar updated JBPM-1024:
-----------------------------------
Workaround Description: Take the custom serializable classes to be stored as variables out of the process archive and put them in a location in the classpath accessible to the classloader that loaded the jBPM classes.
Workaround: [Workaround Exists]
> Serializable variables are not being deserialized when retrieved from process
> -----------------------------------------------------------------------------
>
> Key: JBPM-1024
> URL: http://jira.jboss.com/jira/browse/JBPM-1024
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1.4, jBPM jPDL 3.2.2
> Reporter: thilker
> Assigned To: Alejandro Guizar
> Fix For: jBPM jPDL 3.2.3
>
>
> Storing an serializable object in a process should write an "R" in the column "converter" in table JBPM_VARIABLEINSTANCE.
> But the value of the field is "null".
> The cause:
> The converter ID is retrieved in class org.jbpm.db.hibernate.Converter at line 63.
> For the case of the SerializableToByteArrayConverter the ID is "null".
> Regards,
> Thorsten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months
[JBoss JIRA] Reopened: (JBPM-216) Add "and" to duration language in timers
by Alejandro Guizar (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-216?page=all ]
Alejandro Guizar reopened JBPM-216:
-----------------------------------
Damn. I just wanted to comment and inadvertently I clicked on "Resolve".
> Add "and" to duration language in timers
> ----------------------------------------
>
> Key: JBPM-216
> URL: http://jira.jboss.com/jira/browse/JBPM-216
> Project: JBoss jBPM
> Issue Type: Task
> Components: Core Engine
> Affects Versions: jBPM 3.0 beta 1
> Environment: All
> Reporter: Jim Rigsbee
> Assigned To: Tom Baeyens
> Priority: Minor
>
> Currently the PDL allows for duration expressions of the type <quantity> {business} <unit>, e.g. 5 business hours or 5 days. Please expand this to allow the word "and" between multiple nodes. The time should be aggregated as milliseconds. Some examples,
> 5 business days and 2 hours,
> 1 month and 25 days and 2 minutes
> Tom's suggestion is that if business appears anywhere in the string that the entire duration is considered to be in "business time".
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months
[JBoss JIRA] Resolved: (JBPM-216) Add "and" to duration language in timers
by Alejandro Guizar (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-216?page=all ]
Alejandro Guizar resolved JBPM-216.
-----------------------------------
Resolution: Done
This proposal was already taken in PVM. Not sure it is worth backporting, tough. There aren't many votes for it, though the community may not be aware of it.
Which brings another question: how can we communicate with the community about issues for which we would like input/votes?
> Add "and" to duration language in timers
> ----------------------------------------
>
> Key: JBPM-216
> URL: http://jira.jboss.com/jira/browse/JBPM-216
> Project: JBoss jBPM
> Issue Type: Task
> Components: Core Engine
> Affects Versions: jBPM 3.0 beta 1
> Environment: All
> Reporter: Jim Rigsbee
> Assigned To: Tom Baeyens
> Priority: Minor
>
> Currently the PDL allows for duration expressions of the type <quantity> {business} <unit>, e.g. 5 business hours or 5 days. Please expand this to allow the word "and" between multiple nodes. The time should be aggregated as milliseconds. Some examples,
> 5 business days and 2 hours,
> 1 month and 25 days and 2 minutes
> Tom's suggestion is that if business appears anywhere in the string that the entire duration is considered to be in "business time".
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months
[JBoss JIRA] Commented: (JBPM-1024) Serializable variables are not being deserialized when retrieved from process
by Alejandro Guizar (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-1024?page=comments#action_12415097 ]
Alejandro Guizar commented on JBPM-1024:
----------------------------------------
We could change Converter.revert(Object value) to take not only the value, but the VariableInstance itself. The VariableInstance has a reference to the storing token.
In fact, this issue has been already addressed in CVS head:
if (converter instanceof SerializableToByteArrayConverter) {
converter = (SerializableToByteArrayConverter) converter;
SerializableToByteArrayConverter serializableToByteArrayConverter = (SerializableToByteArrayConverter) converter;
serializableToByteArrayConverter.setProcessInstance(this.getProcessInstance());
if(this.getProcessInstance() != null) {
value = serializableToByteArrayConverter.revert(value, this
.getProcessInstance());
}
else {
value = serializableToByteArrayConverter.revert(value);
}
}
else {
value = converter.revert(value);
}
I consider the above "fix" very inelegant, tough.
> Serializable variables are not being deserialized when retrieved from process
> -----------------------------------------------------------------------------
>
> Key: JBPM-1024
> URL: http://jira.jboss.com/jira/browse/JBPM-1024
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1.4
> Reporter: thilker
> Assigned To: Tom Baeyens
>
> Storing an serializable object in a process should write an "R" in the column "converter" in table JBPM_VARIABLEINSTANCE.
> But the value of the field is "null".
> The cause:
> The converter ID is retrieved in class org.jbpm.db.hibernate.Converter at line 63.
> For the case of the SerializableToByteArrayConverter the ID is "null".
> Regards,
> Thorsten
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months