[jbpm-issues] [JBoss JIRA] Deleted: (JBPM-1916) Query parameter binding or query with limits can fail with SOA-P 4.2 CP03 jars

Query parameter binding or query with limits can fail with SOA-P 4.2 CP03 jars ------------------------------------------------------------------------------ Key: JBPM-1916 URL: https://jira.jboss.org/jira/browse/JBPM-1916 Project: JBoss jBPM Issue Type: Bug Security Level: Public(Everyone can see) Environment: RHEL 4/PostgreSQL/Oracle 9/Oracle 10 Reporter: Jiri Pechanec Priority: Critical The tests org.jbpm.AllTests.testBulkJobs and org.jbpm.AllTests.testMultipleExecutors are failing when the testsuite is executed with SOA-P delivered jars on classpath. The problem is caused by incorrect parameter binding for query GraphSession.findLatestProcessDefinitionQuery. When the test suite is executed on the checked out build, the log contains lines 08:14:04,146 [main] DEBUG QueryParameters : named parameters: {name=bulk messages} 08:14:04,147 [main] DEBUG NullableType : binding 'bulk messages' to parameter: 1 When the tests are failing, the named parameter is bound to the second index 01:05:36,026 [main] DEBUG QueryParameters : named parameters: {name=bulk messages} 01:05:36,027 [main] DEBUG NullableType : binding 'bulk messages' to parameter: 2 Also note the difference in generated sql OK: /* named HQL query GraphSession.findLatestProcessDefinitionQuery */ select processdef0_.ID_ as ID1_112_, processdef0_.NAME_ as NAME3_112_, processdef0_.DESCRIPTION_ as DESCRIPT4_112_, processdef0_.VERSION_ as VERSION5_112_, processdef0_.ISTERMINATIONIMPLICIT_ as ISTERMIN6_112_, processdef0_.STARTSTATE_ as STARTSTATE7_112_ from JBPM_PROCESSDEFINITION processdef0_ where processdef0_.NAME_=? order by processdef0_.VERSION_ desc limit ? Error: /* named HQL query GraphSession.findLatestProcessDefinitionQuery */ select top ? processdef0_.ID_ as ID1_123_, processdef0_.NAME_ as NAME3_123_, processdef0_.DESCRIPTION_ as DESCRIPT4_123_, processdef0_.VERSION_ as VERSION5_123_, processdef0_.ISTERMINATIONIMPLICIT_ as ISTERMIN6_123_, processdef0_.STARTSTATE_ as STARTSTATE7_123_ from JBPM_PROCESSDEFINITION processdef0_ where processdef0_.NAME_=? order by processdef0_.VERSION_ desc and then it the log is select processdef0_.ID_ as ID1_123_, processdef0_.NAME_ as NAME3_123_, processdef0_.DESCRIPTION_ as DESCRIPT4_123_, processdef0_.VERSION_ as VERSION5_123_, processdef0_.ISTERMINATIONIMPLICIT_ as ISTERMIN6_123_, processdef0_.STARTSTATE_ as STARTSTATE7_123_ from JBPM_PROCESSDEFINITION processdef0_ where processdef0_.NAME_=? order by processdef0_.VERSION_ desc Why is there top ? whcih probably causes to bind parameter on the second position and there is no top ? in the PSQL Exception?