Bug 1045688

Summary: Cannot build&deploy a simple process.
Product: [Retired] JBoss BPMS Platform 6 Reporter: Marek Baluch <mbaluch>
Component: Business CentralAssignee: Mauricio Salatino <msalatin>
Status: CLOSED CURRENTRELEASE QA Contact: Tomas Livora <tlivora>
Severity: high Docs Contact:
Priority: high    
Version: 6.0.0CC: kverlaen
Target Milestone: CR1   
Target Release: 6.0.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-06 20:13:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1043877    
Bug Blocks:    
Attachments:
Description Flags
Process definition
none
Screencast none

Description Marek Baluch 2013-12-21 08:07:04 UTC
Description of problem:
An attempt to use the predefined repository/project to create a simple process and deploy it will fail. 

Message bellow will be present in the log - business-central will say that the build was finished successfully.

08:58:43,890 ERROR [stderr] (Thread-107) Exception in thread "Thread-107" java.lang.NullPointerException
08:58:43,891 ERROR [stderr] (Thread-107) 	at org.uberfire.metadata.io.BatchIndex$1.run(BatchIndex.java:57)


Steps to Reproduce:
1. Create a new process in example/repository1/project1 
2. Model start->humanTask->end (I specified one 'actor' and the 'task name')
3. Save the process and close it
4. Show the 'Project editor' view and hit 'build&deploy'


Actual results:
NPE in the server log - deployment visible in the 'Deployments' view but no process in the 'Process definitions' view.


Expected results:
No NPE present and process visible in the 'Process definitions' view.

Comment 1 Mauricio Salatino 2013-12-21 16:47:35 UTC
Can you please attach the bpmn process file that you are using to test? because the problem is probably related with that.

Comment 2 Marek Baluch 2013-12-23 08:09:14 UTC
Created attachment 840721 [details]
Process definition

Attached the process definition.

Comment 3 Marek Baluch 2013-12-23 08:12:28 UTC
Created attachment 840722 [details]
Screencast

Attached screencast.

The screencast shows that a process created in the example/repository1/project1 project will produce a NPE in the server log and will not be available in the 'Process Definitions' list.

Please note that 'Build&Deploy' works is another imported repository is used (e.g. the one  containing mortages)

Comment 4 Kris Verlaenen 2014-01-03 02:53:25 UTC
Seems to be similar to
https://bugzilla.redhat.com/show_bug.cgi?id=1047900

Comment 5 Mauricio Salatino 2014-01-07 12:30:23 UTC
I've just started analysing this issue, and I've noticed that the video shows a task without a name (a name in the node) so we need to decide where to report that error. I can do the backend checking to avoid the failure, but the process validation should fail IMO. If it doesn't fail we will end up with a Task without a name in the task list, which will also be invalid. Wdyt?

Comment 6 Marek Baluch 2014-01-07 12:52:33 UTC
Well, a node (activity if you will) without a name is valid according to the BPMN2 specification. That's why I think it would not be the best solution to force the user to specify it. I believe that it would be better to use the 'taskName' instead if 'name' is not specified. The Drools 'taskName' attribute is required as far as I know.

Comment 7 Mauricio Salatino 2014-01-07 13:13:09 UTC
I've just checked this issue in master, and the error is not there anymore, but as I mention we end up with a task with no name that will obviously will cause more issues. 
It's also important to mention that the Task Name property in designer is just for the Forms, and not for the actual "Task name" in the task list, so it's important that in your process diagrams you enter a valid Node Name. 

We already had a discussion about this in the past, but it seems that we finally agreed to keep Task Name as a property separated for the actual Node Name for enabling different form resolutions using the Task Name property. IMO Task Name should be optional, but once again we enter in the same discussion as before. 

About the BPMN2 spec, that's fine that is optional, but remember that in the back we are creating a Task using the WS-HT specification so in some way we are relying on the fact that a Human task will be created. IMO we should avoid this inconsistencies.
I'm checking this in 6.0.x now, to avoid the issue, but fixing this issue will not fix the real problem/inconsistency.

Comment 8 Mauricio Salatino 2014-01-07 13:45:21 UTC
I wasn't able to reproduce the issue in 6.0.x, it seems that is already fixed. I was assuming that the user that you use id in your video was a valid user name for the Actor right? 
Because the issue was not happening I've managed to start a process instance, and as I mention before the task with an empty name appears in the task list and everything was fine until I've tried to complete the task. On the task completion (because it also completes the process instance and all the task details are removed from the database another issues appears related with the form for the un existing task). 
I'm not sure if we will need another BZ for those issues, I'm resign the solution right now, but I will not push the fixes for them until I have a blocker BZ. 

Is there any way that you can test again to see if you can reproduce this issue again? 
Again with KIE-Wb from the 6.0.x branch the issue is not happening in Hosted mode.

Comment 9 Marek Baluch 2014-01-07 14:01:59 UTC
(In reply to Mauricio Salatino from comment #8)
> I wasn't able to reproduce the issue in 6.0.x, it seems that is already
> fixed. I was assuming that the user that you use id in your video was a
> valid user name for the Actor right? 

Yes - the actor name was the same name as the login name used to create the process.

> Because the issue was not happening I've managed to start a process
> instance, and as I mention before the task with an empty name appears in the
> task list and everything was fine until I've tried to complete the task. On
> the task completion (because it also completes the process instance and all
> the task details are removed from the database another issues appears
> related with the form for the un existing task). 
> I'm not sure if we will need another BZ for those issues, I'm resign the
> solution right now, but I will not push the fixes for them until I have a
> blocker BZ. 

Not sure what you mean by a "blocker BZ". This BZ is already approved as blocker.

> Is there any way that you can test again to see if you can reproduce this
> issue again? 
> Again with KIE-Wb from the 6.0.x branch the issue is not happening in Hosted
> mode.

I can retest with the latest snapshot when your fix will get picked up.

Comment 10 Mauricio Salatino 2014-01-07 14:21:38 UTC
The problem is that I cannot add the fix for the commit associated with this BZ because it's related with task completion and not with the build & deploy process that it seems to be working ok in 6.0.x.

Comment 11 Marek Baluch 2014-01-07 14:26:39 UTC
I will create quickly another issue.

Comment 12 Mauricio Salatino 2014-01-07 14:47:35 UTC
The error already related with task completion is already covered by this bug that is already fixed in master but wasn't marked as a blocker.. I would suggest to mark this new one as blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1042520 so fixing it will fix all the issues that are appearing now

Comment 13 Kris Verlaenen 2014-01-08 14:35:31 UTC
I reproduced this on ER7, and also got the same error message on 6.0.1.Final but there the process did show up as expected.  So I believe the error message itself might be harmful (will investigate further to remove it), but the fact that the process doesn't show up is probably related to https://bugzilla.redhat.com/show_bug.cgi?id=1043877 and not immediately linked to the error in the log.

Comment 14 Mauricio Salatino 2014-01-09 18:25:55 UTC
The following commits fixes the issue in 6.0.x -> 
https://github.com/droolsjbpm/uberfire/commit/d22d5d8fb
https://github.com/droolsjbpm/uberfire/commit/dbd577f8c

Porcelli, reviewed the issue and those changes were introduced in uberfire to avoid the NPEs

Comment 15 Tomas Livora 2014-01-27 11:04:25 UTC
Verified on BPMS 6.0.0 CR2