October 2008 - jbpm-issues - Jboss List Archives

[JBoss JIRA] Created: (JBPM-1285) add fixed date timer support

by Tom Baeyens (JIRA)

add fixed date timer support ---------------------------- Key: JBPM-1285 URL: http://jira.jboss.com/jira/browse/JBPM-1285 Project: JBoss jBPM Issue Type: Feature Request Security Level: Public (Everyone can see) Components: PVM Reporter: Tom Baeyens add support in the TimerDefinition for fixed dueDates this should be done by adding a dueDate (type java.util.Date) property to the TimerDefinition and adding the necessary logic in the timer creation. -- 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, 6 months

4
10
0 / 0

[JBoss JIRA] Created: (JBPM-1189) Create a story for the xsd

by Koen Aers (JIRA)

Create a story for the xsd --------------------------- Key: JBPM-1189 URL: http://jira.jboss.com/jira/browse/JBPM-1189 Project: JBoss jBPM Issue Type: Task Reporter: Koen Aers Assigned To: Tom Baeyens Currently the jpdl xsd appears in multiple locations: - the runtime - the designer - online These should be synchronized at regular times. There should be a strategy to make sure this happens. -- 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, 6 months

5
7
0 / 0

[JBoss JIRA] Created: (JBPM-1288) evaluate the previous methods

by Tom Baeyens (JIRA)

evaluate the previous methods ----------------------------- Key: JBPM-1288 URL: http://jira.jboss.com/jira/browse/JBPM-1288 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Components: PVM Reporter: Tom Baeyens this relates to Execution.getPreviousNode() Execution.getPreviousTransition() Node.isPreviousNeeded() Comment in Execution.java: // TODO evaluate the previous methods // these methods are kind of performance optimisations. a sequence and // some other specific control flow implementations can be optimised if they // have access to the previous node or transition. // Those activities could also be implemented by letting the activities store // the contextual information in process variables or some other execution // context. But with the previous properties as done now, these control flow // nodes can be implemented without storing an extra record. It's only a property // that is only updated when the node configuration indicates that it's needed. // (see also Node.isPreviousNeeded()) -- 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, 6 months

1
7
0 / 0

[JBoss JIRA] Created: (JBPM-1685) Check persistence of exception field in JobImpl

by Guillaume Porcher (JIRA)

Check persistence of exception field in JobImpl ----------------------------------------------- Key: JBPM-1685 URL: https://jira.jboss.org/jira/browse/JBPM-1685 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Components: PVM Reporter: Guillaume Porcher Priority: Critical in jobs, there is a exception field to put the exception stacktrace in hibernate mappings, this column length is set to 4000. Some stacktrace are more than 4000 char long, this creates an exception with hibernate. <tomb> porcherg: the 4000 is because of some DB limitation <tomb> i believe db2 <tomb> iirc, in db, the max string field is 4000 <tomb> if you want to go beyond that, we would need to use CLOBs <tomb> but i'm open to alternatives <tomb> maybe the stacktrace field should be a CLOB ? <porcherg> tomb: the problem is that it creates an exception if it is too long <tomb> yes <tomb> so we have to fix it somehow <tomb> just removing the 4000 limit is not good <tomb> as it will not work on db2 <tomb> so we either manually truncate the exception field in the code <tomb> in the setter <tomb> or we change it into a clob <tomb> probably the latter is better <porcherg> maybe we can use hibernate "text" type <porcherg> "text: Maps long Java strings to a SQL CLOB or TEXT type. " <tomb> do you guys have access to db2 db ? <tomb> the first thing we should do is verify if this problem is really present <tomb> so we should remove the 4000 limit in the hibernate mappings and see if we can create that problem on db2 <tomb> once we can reproduce it, then we can start looking for alternatives that fix the problem on db2 <tomb> then we can see if the fix works on the other dbs <tomb> i am a bit reluctant to start using clobs <tomb> as this would be the first use case for it <tomb> and clobs might lead to even more DB dependent issues... <tomb> but if there is no other way, then we have to <tomb> so let's start by removing the 4000 limit in the hibernate mappings and prioritizing that we have to test it in db2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

2
7
0 / 0

[JBoss JIRA] Created: (JBPM-1438) Task assigned to different actor-id can be seen and manipulated in jBPM console

by Martin Vecera (JIRA)

Task assigned to different actor-id can be seen and manipulated in jBPM console ------------------------------------------------------------------------------- Key: JBPM-1438 URL: https://jira.jboss.org/jira/browse/JBPM-1438 Project: JBoss jBPM Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Engine Affects Versions: jPDL 3.2.2 Environment: JBossESB server 4.3.GA, bpm_orchestration4 Reporter: Martin Vecera By default JBossESB server 4.3.GA has several jBPM users configured including 'user' and 'manager'. bpm_orchestration4 example contains one process definition which assigns two tasks, first to actor-id 'user' and the second to actor-id 'manager'. The problem is that the 'user' can see and manipulate both of the tasks. Steps to reproduce: 1. download JBossESB server 4.3.GA 2. start it using bin/run.sh 3. go to samples/quickstarts/bpm_orchestration4 4. run one by one: ant deploy, ant deployProcess, ant startProcess 5. open jBPM console and login as 'user' with password 'user' 6. click on Tasks to see the task list and on Examine to open the task, then on Save and Close 7. refresh the task list and you can see second task assigned to 'manager', try to Examine it... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

3
8
0 / 0

[JBoss JIRA] Created: (JBPM-1113) Maximum number of cursors exceeded: ResultSet not closed?

by Martin Vecera (JIRA)

Maximum number of cursors exceeded: ResultSet not closed? --------------------------------------------------------- Key: JBPM-1113 URL: http://jira.jboss.com/jira/browse/JBPM-1113 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.2 Environment: SOA-P 4.2.0.beta2 (JBossESB 4.2.1), Oracle 10g Reporter: Martin Vecera Assigned To: Tom Baeyens We deployed a performance test (see attached file) based on bpm_orchestration2. When we generated a large backlog of messages (10,000) there started to be problems with cursors. This doesn't happen when BPM is not used. See attached file for server log. 11:59:10,560 WARN [JDBCSupport] SQLException caught, SQLState 72000 code:1000- assuming deadlock detected, try:23 java.sql.SQLException: ORA-01000: maximum open cursors exceeded at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288) at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743) at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216) at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:955) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1168) at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3316) at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3400) at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251) at org.jboss.messaging.core.impl.JDBCPersistenceManager$1HandleBeforeCommit1PCRunner.doTransaction(JDBCPersistenceManager.java:1593) at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.execute(JDBCSupport.java:465) at org.jboss.messaging.core.impl.JDBCSupport$JDBCTxRunner2.executeWithRetry(JDBCSupport.java:503) at org.jboss.messaging.core.impl.JDBCPersistenceManager.handleBeforeCommit1PC(JDBCPersistenceManager.java:1680) at org.jboss.messaging.core.impl.JDBCPersistenceManager$TransactionCallback.beforeCommit(JDBCPersistenceManager.java:2790) at org.jboss.messaging.core.impl.tx.Transaction.commit(Transaction.java:208) at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.java:474) at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$ConnectionAdvised$sendTransaction$aop(ConnectionAdvised.java:101) at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java) at org.jboss.jms.server.container.SecurityAspect.handleSendTransaction(SecurityAspect.java:195) 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.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121) at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java) at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105) at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java) at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.sendTransaction(ConnectionAdvised.java) at org.jboss.jms.wireformat.ConnectionSendTransactionRequest.serverInvoke(ConnectionSendTransactionRequest.java:82) at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:795) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:387) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166) -- 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, 6 months

3
8
0 / 0

[JBoss JIRA] Created: (JBPM-1796) Add process variable view

by Heiko Braun (JIRA)

Add process variable view ------------------------- Key: JBPM-1796 URL: https://jira.jboss.org/jira/browse/JBPM-1796 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Components: Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: GWT Console 1.0.0 CR1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 7 months

1
5
0 / 0

[JBoss JIRA] Created: (JBPM-1459) getDefaultTransition

by Tom Baeyens (JIRA)

getDefaultTransition -------------------- Key: JBPM-1459 URL: https://jira.jboss.org/jira/browse/JBPM-1459 Project: JBoss jBPM Issue Type: Task Security Level: Public (Everyone can see) Reporter: Tom Baeyens shouldn't that be called Node.getDefaultOutgoingTransition() ? ...given that the rest of the transition methods all have incoming or outgoing. WDYT ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (JBPM-1236) fix for undescriptive NullPointerException when jbpm4jsf-config.xml is missing

by Gergely Nagy (JIRA)

fix for undescriptive NullPointerException when jbpm4jsf-config.xml is missing ------------------------------------------------------------------------------ Key: JBPM-1236 URL: http://jira.jboss.com/jira/browse/JBPM-1236 Project: JBoss jBPM Issue Type: Patch Security Level: Public (Everyone can see) Components: Web Interface Reporter: Gergely Nagy An undescriptive error page is shown when jbpm4jsf-config.xml is missing: simple error 500 page with no indication to the cause of the error. I could only track this down by debugging jbpm4jsf, and it took me a while to figure this out. The attached patch includes a check for null, and a descriptive error message. -- 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, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-1185) Node, State and ProcessState don't support Conditions on Transitions

by Britt Miner (JIRA)

Node, State and ProcessState don't support Conditions on Transitions -------------------------------------------------------------------- Key: JBPM-1185 URL: http://jira.jboss.com/jira/browse/JBPM-1185 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM jPDL 3.2.2 Reporter: Britt Miner Assigned To: Tom Baeyens Node, State, and ProcessState 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 a condition is present on the default transition, and that 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 really be altered (and a one-liner in ProcessState): In org.jbpm.graph.def.Node, add the following method: // BRITT-- public Transition calculateLeavingTransition(ExecutionContext executionContext) { Transition transition = null; 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)) { transition = candidate; } } else { transition = candidate; } } if (!hasTransitioned) { this.getDefaultLeavingTransition().removeConditionEnforcement(); log.warn("All transition conditions have evaluated to 'false'. Taking the default transition."); transition = this.getDefaultLeavingTransition(); } return transition; } // --BRITT ...and modify "leave(ExecutionContext executionContext)": // BRITT --replace the following line with the code below // to check conditions before selecting the transition to take... //leave(executionContext, getDefaultLeavingTransition()); //original line leave(executionContext, calculateLeavingTransition(executionContext)); // --BRITT For consistency, ProcessState should also have one line modified at the very end of it's "leave(ExecutionContext, Transition)" method: // BRITT-- rather than specify which transition, let the super class decide... //super.leave(executionContext, getDefaultLeavingTransition()); super.leave(executionContext, calculateLeavingTransition(executionContext)); // --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, 9 months

5
11
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbpm-issues October 2008