Description of problem: Normally, the options dialog disappears when selecting rule attribute from the drop-down list and user is able to further modify the option. After selecting date-effective or date-expires, the dialog stays visible but all existing options disappear from the editor. Reopening the rule doesn't help. No options are presented after clicking "(show options ...)". Version-Release number of selected component (if applicable): ER5 How reproducible: - Steps to Reproduce: 1. open any guided rule 2. click "(show options ...)", click green plus image for options 3. select date-effective or date-expires from rule attributes list Actual results: The rule options dialog stays visible, rule options disappear. Expected results: Dialog should disappear and the selected rule option should be added. Additional info:
Built jboss-integration (https://github.com/organizations/jboss-integration) at sync.2013.11.19 tag (i.e. ER5) locally. The "Options" section worked fine (I could add either of the date attributes, the popup closed and the editor showed the new attribute). I've contacted Ryan Zhang to check if ER5 was indeed built with correct dependencies.
<sigh> I love this BZ ;) Ryan contacted me and said he could not replicate the bug in Chrome 29. Ryan also confirmed both he and I were using exactly the same binaries. I downloaded Chrome 31 and the bug was not evident. Hmmmm... me thinks must be a browser issue. I fiddle a bit more. To cut a long and otherwise tedious story short; I cleared my Firefox (12.0) browser cache (that I could replicate this bug with); redeployed BRMS ER5 on EAP and retried. The bug disappeared. I repeated this a few times and the bug does not reoccur following a browser cache clearance (downloaded files). At this stage; I have to conclude this appears to be a browser cache issue. Can you please clear your browser's cache and re-try.
We're still unconvinced this is completely fixed. Assigning back to me until we've tested on jboss-integration.11.19 on AS7 and EAP.
Tested with kie-drools-wb-6.0.0-SNAPSHOT-jboss-as7.0.war built from jboss-integration.11.19 and this worked OK... trying distribution for EAP now...
Tested with eap-modules-distributions-6.0.0-SNAPSHOT-org.kie.kie-drools-wb-webapp.war built from jboss-integration.11.19 on EAP6.2 and this worked OK too... trying on EAP6.1.1.
Tested with eap-modules-distributions-6.0.0-SNAPSHOT-org.kie.kie-drools-wb-webapp.war built from jboss-integration.11.19 on EAP6.1.1 and this worked OK too... I suggest there is little we can do other than re-test on the next ER release?
I should add I've tested on both FF12.0 and Chrome 31.
From my experience this issue is not browser or cache related. My user had "admin,analyst" roles all the time and I reproduced the issue under all circumstances. Then I removed the "analyst" role and the issue was gone. When I added "analyst" back, I couldn't reproduce it, *surprisingly*! However after clearing .niogit directory, the issue occurred again (with "admin,analyst" roles). 1. clean EAP 6.1.1 + BRMS ER5 installation, log in with admin=admin,analyst user - reproduced 2. change roles to admin=admin, restart server - cannot reproduce 3. change roles to admin=admin,analyst, restart server - cannot reproduce 4. don't touch roles, delete .niogit, restart server - reproduced I have repeated this process to verify it is reliable.
I agreed, it seems not a browser or cache related. I also 100% reproduce this issue. For the first time startup (ie a new installation or for the second time but removed .niogit directory cases) the issue always happening. But if you restart the server, this issue will disappear. I am checking if I removed bpms modulization job and deployed the war directly and wait to see if there is any difference... (In reply to Jiri Locker from comment #9) > From my experience this issue is not browser or cache related. > > My user had "admin,analyst" roles all the time and I reproduced the issue > under all circumstances. Then I removed the "analyst" role and the issue was > gone. When I added "analyst" back, I couldn't reproduce it, *surprisingly*! > However after clearing .niogit directory, the issue occurred again (with > "admin,analyst" roles). > > 1. clean EAP 6.1.1 + BRMS ER5 installation, log in with admin=admin,analyst > user > - reproduced > 2. change roles to admin=admin, restart server > - cannot reproduce > 3. change roles to admin=admin,analyst, restart server > - cannot reproduce > 4. don't touch roles, delete .niogit, restart server > - reproduced > > I have repeated this process to verify it is reliable.
Strange! I have tried the 6.0.0. Final version download from https://repository.jboss.org/nexus/content/groups/public-jboss/org/kie/kie-wb-distribution-wars/6.0.0.Final/kie-wb-distribution-wars-6.0.0.Final-eap-6_1.war And I deployed it directly to EAP 6.1.1 and removed the EAP modulized folder which I blieve it can isolate the issue from EAP modulization job for bpms. (and I also added into the ER5 's configuration.) I can also reproduce this issue. @Mike, could you provide me a download link for your build? let me try it. (In reply to manstis from comment #7) > Tested with > eap-modules-distributions-6.0.0-SNAPSHOT-org.kie.kie-drools-wb-webapp.war > built from jboss-integration.11.19 on EAP6.1.1 and this worked OK > too... I suggest there is little we can do other than re-test on the next ER > release?
Cannot reproduce in ER6.
Strange. I didn't reproduce it on the first attempt but then I checked the steps described in comment 9. I restarted the server and deleted .niogit and reproduced the issue. I wasn't changing my user roles with ER6. I have "analyst,admin" all the time, so I'm starting to think it is not related to roles either. My question is what actions do I have to take, after starting with clean .niogit, to avoid the issue?
As per comment 10 I can replicate the issue by deleting .niogit and refreshing the browser without performing a server restart. If I stop the server, delete .niogit and restart the server I cannot replicate the problem. i.e.:- 1) Start server 2) Launch webapp in browser 3) Delete .niogit 4) Refresh browser Can you please double-confirm that this problem happens even with a server restart? (And if it does happen, can you please check the content of .niogit when the problem occurs - I suspect it's not there at all when the problem happens).
(In reply to manstis from comment #17) > As per comment 10 I can replicate the issue by deleting .niogit and > refreshing the browser without performing a server restart. That doesn't make sense to me. When you delete .niogit and refresh the browser... How can you then open any rule when there is no GIT repository? > If I stop the server, delete .niogit and restart the server I cannot replicate the problem. I can. Always. > > i.e.:- > > 1) Start server > 2) Launch webapp in browser > 3) Delete .niogit > 4) Refresh browser > > Can you please double-confirm that this problem happens even with a server > restart? (And if it does happen, can you please check the content of .niogit > when the problem occurs - I suspect it's not there at all when the problem > happens). In short, yes. I always replicate after server restart + rm -rf .niogit/. And when the problem happens, .niogit is there (it's always created during business central deploy). I'm also observing that I cannot replicate on fresh installation until I first delete .niogit. I was doing a lot of tasks including cloning and removing repositories through UI and restarted the server many times. The problem didn't occur as long as I didn't clear .niogit.
I have finally found a reliable way to "fix" the problem after replicating it. In the end it seems to be also cache related. To reproduce, it is sufficient to perform this sequence: 1. stop the server 2. rm -rf .niogit/ 3. start the server 4. create new guided rule in example/repository1/project1 (should be generated during deploying the workbench if system property org.kie.example=true) Then, to get rid of the problem (impossible to add date-effective and date-expire), follow these steps: 1. stop the server 2. close browser window and clear cache (tested with Firefox) 3. start the server 4. open the rule and add date options (will be successful) Notice that it is insufficient to clear the browser cache (that's why I first believed that clearing the cache doesn't help). You have to restart the server too(!).
Hi Jiri, I'd be interested in what yuo do inbetween steps 3 and 4: <quote> To reproduce, it is sufficient to perform this sequence: 1. stop the server 2. rm -rf .niogit/ 3. start the server 4. create new guided rule in example/repository1/project1 (should be generated during deploying the workbench if system property org.kie.example=true) </quote> Do you wait for the server to fully start - and check that .niogit has been created before trying to run the workbench in a browser? The problem could be that the browser is using cached JavaScript that tries to download the workbench preferences before they've been created in .niogit/system.git. Normally the container (i.e. EAP) will not service any requests until it has fully started but this could be circumvented with the browser cache. This is leading to an empty set of preferences in the browser that causes the "Date Effective" and "Date Expires" problem (both try to access the date/time format preference). Stopping and restarting the server without deleting .niogit/system.git solves the problem because by the 2nd (and subsequent starts) the workbench preferences have been created in .niogit/system.git.
(In reply to manstis from comment #21) > > Do you wait for the server to fully start - and check that .niogit has been > created before trying to run the workbench in a browser? The problem could > be that the browser is using cached JavaScript that tries to download the > workbench preferences before they've been created in .niogit/system.git. Yes, I wait for the start completion message in server log (...(AS 7.2.1.Final-redhat-10) started in 12364ms - Started 302 of 359 services...) and .niogit is always present with all commits in place. So this is what I do between 3 and 4. And still I can reproduce. > > Normally the container (i.e. EAP) will not service any requests until it has > fully started but this could be circumvented with the browser cache. > > This is leading to an empty set of preferences in the browser that causes > the "Date Effective" and "Date Expires" problem (both try to access the > date/time format preference). > > Stopping and restarting the server without deleting .niogit/system.git > solves the problem because by the 2nd (and subsequent starts) the workbench > preferences have been created in .niogit/system.git. You are right. After the 2nd restart the problem disappears without the need to clear the cache. I haven't noticed this before.
it was caused by no preferences being available. The problem was actually caused by WatchService that fired resource added event as soon as something is added to the repository - cloned repo from github, configuration, etc. Then addResourse is actually triggering the incremental build change listener class to be initialized that in turn check the preferences if the incremental builds are enabled and by that fetching empty preferences - they where not yet written into system repo. subsequent calls to the load preferences method returns always empty map as they considered to be loaded and are cached. I followed same approach as for clustering - delay the start of watch service until the application is completely initialized - ApSetup on @PostConstruct fires ApplicationStarted event that is enabling the watch service threads and loads the preferences - they will be loaded properly regardless if the first one will be watch service or based on ApplicationStarted event. That way everything is configured in right time uberfire master: https://github.com/droolsjbpm/uberfire/commit/f2736444816cea83a72c96527cfdbb25c2b7bc6b 0.3.x: https://github.com/droolsjbpm/uberfire/commit/532198c52f7c3b8a8aff094decd295ca0f4d4992 guvnor: master: https://github.com/droolsjbpm/guvnor/commit/9db8cfdf0331f8dd556a59542b3f223d877b6aa2 6.0.x: https://github.com/droolsjbpm/guvnor/commit/b8798b7c6a24fb12a270233486031ff7272aea07 kie-wb-distributions: master: https://github.com/droolsjbpm/kie-wb-distributions/commit/a09354048401c835adcec23c39b83cbc893d9c19 6.0.x: https://github.com/droolsjbpm/kie-wb-distributions/commit/98ec543b84d5c7c320dba9116b283c02bb4e8339
Cannot reproduce in CR1.