Red Hat Bugzilla – Bug 1263594
Creating Project, then copying it, then deleting it causes NoSuchFileException
Last modified: 2018-01-30 23:45:25 EST
Description of problem:
See subject. That's not a problem by itself, but after this exception file operations like rename in DRL editor (and possibly other editors) stop working correctly.
For example: You can get Modal with NoSuchFileException after creating new DRL, then renaming it, then deleting it.
Version-Release number of selected component (if applicable):
kie-wb 6.3.x snapshot
Steps to Reproduce:
I isolated the exact steps that reproduce the issue in 100% cases:
1. In Authoring perspective create new project 'original'
2. In Project editor, click copy and enter new name 'mycopy'
3. In project editor, click delete
--- mycopy is deleted in UI , but the exception appears in server log.
--- following this exception other issues start arising. For example:
4. Create new DRL file
5. In DRL editor click Rename and rename it to some new valid name >>HERE the DRL editor should be reloaded with the new filename, but it itsn't, which causes exception in step 6<<
6. In DRL edito click Delete -> You will get Modal with NoSuchFileException
Could you also make sure to test this against the REST API? (Or otherwise let the REST API QE engineer know about this bug?).
what do you mean by testing it against REST API? Do you think we should try to reproduce it the way when we do steps 1-3 through REST API and then the next steps 4-6 through GUI? Because after discussion with Jan I understand that this problem occurs when you delete a project using GUI and this project remains selected when you try to create a new DRL file. So in my opinion it is just a GUI bug. What do you think?
Tomas, yes, 1-3 in the REST API and 4-6 through the GUI.
The changes affect code that the REST API uses as well -- in face, the commits are only for changes in the backend.
This however does not have a high priority, if possible/you have time, please do this.
I'm unable to verify this with ER5, because now there's an error when copying the project (step 2 in steps to reproduce).
Please try the following steps:
1) Go to authoring and create new project "abc"
2) In Project Editor that is opened click Copy and enter new name "def" for the copy
You get modal "ERROR - File "/def/global" already exists." and there's exception in server.log (see attachment)
When I dismiss the error modal and follow through with the remaining steps to reproduce described in the original comment, I still get the NoSuchFileException as before.
I also managed to reproduce this issue in kie-ci docker environment (6.3.1 branch + kie-wb + EAP + H2 db).
Created attachment 1089431 [details]
Exception from server.log when copying project
(In reply to Jan Hrcek from comment #6)
> I'm unable to verify this with ER5, because now there's an error when
> copying the project (step 2 in steps to reproduce).
> Please try the following steps:
> 1) Go to authoring and create new project "abc"
> 2) In Project Editor that is opened click Copy and enter new name "def" for
> the copy
> You get modal "ERROR - File "/def/global" already exists." and there's
> exception in server.log (see attachment)
> When I dismiss the error modal and follow through with the remaining steps
> to reproduce described in the original comment, I still get the
> NoSuchFileException as before.
> I also managed to reproduce this issue in kie-ci docker environment (6.3.1
> branch + kie-wb + EAP + H2 db).
This is something completely different ;)
The original error was caused by a programming error and would have affected both BRMS and BPMS - we were trying to instantiate a Project object for a project that had been deleted from the VFS.
This "new" error (but related to copying projects - and I suspect just creating two projects in BPMS) is caused by Designer trying to recreate existing "global" definitions - I assume used by Designer.
Could you please confirm the originally reported "NoSuchFileException" error does not happen (with BRMS)? The new "FileAlreadyExistsException" will only be thrown in BPMS.
I'm reassigning this BZ to Tiho - as he'll need to ensure Designer's org.jbpm.designer.repository.vfs.VFSRepository.createGlobalDirOnNewProject() method checks whether files already exist.
Please see the log. Looks like you'll need to check if files already exist in the "global" workspace before creating them.
I've just tried with BRMS and I'm still able to reproduce the original issue using the same steps as I gave in the original description (just ignoring the "FileAlreadyExistsException" modal on the way - yes, it happens in BRMS too).
Let's do it like this: I'll open new BZ for Tiho for the copying-of-project issue, but I'm still leaving this one as assigned so that the original issue is fixed. Is that ok?
Could you please attach the log for BRMS too?
I suspect it's the same issue - I forgot BRMS also includes Designer for Rule Flow.
I reproduced the problems with BRMS too - and the cause is the "FileAlreadyExistsException" error thrown by org.jbpm.designer.repository.vfs.VFSRepository.createGlobalDirOnNewProject().
I tested the original issue with a workbench that has no jBPM Designer dependency (drools-wb-webapp.. a sort of trimmed down Business Central for developers) and following your reproducer-steps everything worked just fine.
So, I believe this BZ is resolved ("NoSuchFileException"), however we're unable to verify it due to the issue in Designer. I'm happy for this BZ to be left in "MODIFIED" and a new BZ raised for Tiho.
You won't be able to test this BZ however until Tiho fixes the "new" issue.
OK with you?
Sure, I'm fine with that. Thanks for looking into this. I added the reference to the new BZ using Depens On field. Let's leave this on modified until that Designer issue is fixed.
Bug # 1277883 (on which verification of this bug depends) didn't end up in 6.3.x, so I'm still unable to verify this with 6.2.0 CR1.
This is fixed in 6.3.0.