Bug 1263594
Summary: | Creating Project, then copying it, then deleting it causes NoSuchFileException | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] JBoss BPMS Platform 6 | Reporter: | Jan Hrcek <jhrcek> | ||||
Component: | Business Central | Assignee: | manstis | ||||
Status: | CLOSED EOL | QA Contact: | Lukáš Petrovický <lpetrovi> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 6.2.0 | CC: | kverlaen, lpetrovi, manstis, rrajasek, smcgowan | ||||
Target Milestone: | --- | Keywords: | Regression | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2020-03-27 20:12:49 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: | |||||
Embargoed: | |||||||
Bug Depends On: | 1277883 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Jan Hrcek
2015-09-16 09:12:13 UTC
Jan, Could you also make sure to test this against the REST API? (Or otherwise let the REST API QE engineer know about this bug?). Hi Marco, 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). @Jan, 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. @Tiho, Please see the log. Looks like you'll need to check if files already exist in the "global" workspace before creating them. Cheers, Mike Mike, 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? Jan, Could you please attach the log for BRMS too? Thanks, Mike I suspect it's the same issue - I forgot BRMS also includes Designer for Rule Flow. Hi Jan, 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? Cheers, Mike 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. |