This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
1. Create a Java EE 7 web project with GlassFish 4 as the target server 2. Run it in Chrome with NetBeans integration 3. Edit index.html and save it => Sometimes the page in Chrome is not refreshed. This is random - often it works, just sometimes it does not propagate correctly. (I was able to reproduce in every 1 of 3-4 attempts.) Not sure if the problem is in the compile on save/deploy on save/copy resources on save functionality, or in the communication with the browser.
I'm able to reproduce it, but don't feel this is a P2 issue. As workaround you can refresh the page one more time after a while which mostly results in the correct refreshment. Typically the problem is happening when you switch to the browser immediately after the change was made and obviously sometimes the change is not propagated so fast. Also the problem is happening in both Ant and Maven project --> not sure what is the correct place for these types of problems, Davide can you please move it to the correct product/component
I will check the Ant Web Project. There were some fixes in this area and at least for Ant it used to work well I think.
Created attachment 136971 [details] hacking... I think the problem is in GlassFish. The issue is fairly easy to reproduce. Type 1 in index.html and press Ctrl+S, 2, Ctrl+S, 3, Ctrl+S, 4, Ctrl+S, etc. Usually each third time the page is not reloaded. First, I had a look at what exact content the URL has when server API fires DeployOnSaveListener.deployed. Have a look at BaseClientSideDevelopmentSupport.java - it dumps the content of the URL into /tmp/aaaaa. That showed me that file is really not updated on the server. If I changed XX.post to wait 5000ms before reloading the content of the URL is always right. Hence the conclusion is that Glassfish server fires DeployOnSaveListener.deployed before file was reloaded in the server. Second thing I tried was to change Glassfish's FastDeploy.java to enforce call to redeploy because for static files it is simply not called. And that indeed resolved this issue. Whether that's a right fix I doubt.
While evaluating issue 230565, I finally see why the issue were filled as P2. It's not about F5 browser reload, but about automatic reload after the file save (didn't notice that when I was trying it). Changing the priority back, sorry for confusion.
This has nothing to do with SDK. Will checks with Vince if we has time to have a look at this. I already did some changes into FastDeploy.java in initialDeploy method which are not pushed yet. But this fix probably won't touch this piece of code too.
(In reply to comment #3) > Second thing I tried was to change Glassfish's FastDeploy.java to enforce call > to redeploy because for static files it is simply not called. And that indeed > resolved this issue. Whether that's a right fix I doubt. forcing a redeploy when somebody changes static content is a pretty big hammer for this issue. I have to wonder why the GF FastDeploy is getting called before the changes have been saved to the deploy dir. I haven't seen that before... but I have been away from this for some time.
re. "forcing a redeploy when somebody changes static content is a pretty big hammer for this issue" - I agree. I'm not saying it should be fixed that way. I only evaluated where the problem was.
Reverting unintended change.
actually... i was picking this up and forgot to take it off Tomas' plate
It looks like there is a bug in the server. I did a test of a directory deployed web where I updated a static content file and curled the file from GF. The curl did not return the actual content of the file each time. It looks like there is a buffer of about 5 seconds. Unfortunately, the last deploy time does not trickle into the FastDeploy code, so it seems like it is impossible to know when/if a redeploy for a static content change is necessary. So, the big hammer may be the only hammer we have.
Was this always the case or is this a "regression" in GF 4?
Created attachment 138090 [details] this is a hack Well... this is a first shot at resolving the issue and it does a lot of 'wrong' things.
TOMAS: please review the 'this is a hack' patch. If you see a better solution, use your solution instead.... otherwise, please integrate this (or a similar variant).
thanks for the review.
Integrated into 'main-silver', will be available in build *201308022300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/43d173a6f78f User: vince kraemer <vkraemer@netbeans.org> Log: #231510 : make sure save/refresh forces a deploy when it happens to a static resource within 5 seconds of the last save/refresh.
the fix should be in the nightlies, now.