[
https://issues.jboss.org/browse/WFLY-2391?page=com.atlassian.jira.plugin....
]
Max Rydahl Andersen commented on WFLY-2391:
-------------------------------------------
I've done a bit to reproduce this.
First of, it does not happen on just a few requests.
Before 5 hits updates happens including noticing restarts and .dodeploy markers.
Force refreshing the browser ~5 times and suddenly things gets weird.
updates to html has no effect.
restarting via management service sees the module be restarted but the content is still
the old one.
restarting via .dodeploy works too - but content not refreshed.
This last one I can't find a way to reproduce reliably but it has happend 3 times
now:
...I'm even seeing the app being undeployed by the server (I didn't request it,
but .undeployed file is there and log prints its undeployed) and the content is still
being served.
Wildfly caches content in exploded mode, breaking developer
productivity
------------------------------------------------------------------------
Key: WFLY-2391
URL:
https://issues.jboss.org/browse/WFLY-2391
Project: WildFly
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.0.0.Beta1
Environment: MacOSX with JBossTools 4.1.1.Beta1
Reporter: Xavier Coulon
While I was building a sample application with JBoss Tools 4.1.1.beta1 on WildFly
8.0.Beta1, I noticed that after a few minutes (or a few browser requests), the content of
my index.html file seemed to be cached by the server, although I used the "exploded
content" deployment mode (since I published the content using the WildFly Server
Adapter in JBoss Tools).
I checked the actual content of the index.html in the deployments folder and it contained
the latest changes, which means that the JBoss Tools Server Adapter is doing its job well
;-)
I also tried to edit the index.html file directly in the deployments folder, and once
again, I got no update in both Chrome and Firefox browsers.
I checked in the "Network" tab of the browsers and could see that the server
response for the index.html page had a "200 OK" status, which means that
there's no browser caching involved.
I tried to get the index.html page with cUrl and got the same old version, which
definitely excludes a browser caching issue.
At the end of the dat, this means that after a few changes, my browsers keep getting an
old version of the deployed resources, which in turns means that I have to stop and
restart the server to get the new content, and this is pretty bad in term of dev
productivity.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira