Old deployment failing on new hardware any clues you can give me as to why this might be?

[lindleycb]

Please forgive me as this is not really an issue of the grails activitii plugin but the issue must somehow stem from in there and I need further clues as to what might be wrong so please help me by giving me further avenues to look into.

I have a grails 1.3.7 app using activitii plugin 5.8.2 which has been happily running in a Amazon AWS tomcat Elastic Beanstalk for about 7 years now. However, Amazon decided to retire the hardware that this was running on and now I can't get a working configuration. Nothing has changed in the code except the datasource URL. When I try running it on Tomcat7 with Mysql5.5 most things seem to work fine - old tasks can be completed etc. However, I can't start new processes. The following code always brings back a null task in the getUnassignedTask call. I'm struggling to see why this would be or event to get logging out of Activitii so that it can tell me what queries it is running (and so why data may not be coming back). Please help as this is a live production system and the downtime is expensive!

def startProcess = { username, params ->
activitiService.with {
params.controller = params.bpmController // convert to use the expected name

        // start the task
        ProcessInstance pi = startProcess(params)
        
        // find the first task
        Task task = getUnassignedTask(username, pi.id)
        
        // and claim it
        claimTask(task.id, username)
        def taskStartData = [
            "taskId": task.id,
            "taskName": task.name,
            "taskKey": task.taskDefinitionKey,
            "taskDescription": task.description,
            "taskCreateTime":task.createTime,
            "taskDueDate":task.dueDate,
            "taskAssignee":task.assignee,
            "processInstanceId": pi.processInstanceId
        ];
    
        // then return the task data
        return taskStartData
    }
}

[lindleycb]

Further investigation shows that it comes down to finding the task by candidate user i.e. it works when I comment out the line to match candidate users in ActivitiiService.groovy. As I said, the database contents haven't changed, the code hasn't changed. It's just a db export re-imported onto a new box and an existing war file put in a new Tomcat. Any clue as to what happens in this line that might fail when moving hardware?

Task getUnassignedTask(String username, String processInstanceId) {
	getTask("taskCandidateUser", username, processInstanceId)
}

private getTask(String methodName, String username, String processInstanceId) {
	taskService.createTaskQuery()
	.processInstanceId(processInstanceId)
	// THE LINE THAT MAKES THE DIFFERENCE ."${methodName}"(username)
	.singleResult()
}	

[lindleycb]

Please feel free to close this bug. I eventually found that the issue came down to load order between the activiti plugin and the activity-spring-security plugin as described here:

limcheekin/activiti-spring-security@895ea3c