I'm developing a web application with jsp pages in Eclipse 3.7.2 and testing it with Tomcat v6.0.
I've almost the perfect environment as all changes to my jsp or java code are immediately available in the browser within Eclipse, so I can directly test any change.
But... I also use jQuery, who isn't ;-), and changes in my javascript files are not immediately active. Looks like they are cached or copied once and don't get replaced. Even after rebuilding or restarting the tomcat, the old files keep being used.
Any ideas on how to solve this?
Thanks a lot,
Frank
If you are using firebug in your browser, you can switch off the caching by default without adding code to your page:
click the arrow on the right side of the Networking button and select the disable browser cache option.
The files are probably cached by the browser.
ctrl-F5 might help but if you can configure the server to set no cache for js and css that should also help.
Another solution is to load all such files through a loader,
/load.<site extension, ex php>?file=myscript.js
And have that "proxy" set no cache.
We use that along with e-tag to be able to use build number as e-tag, vith every build a new version is forced to clients but then cached until next build.
Related
When I use Eclipse to develop some project with UI pages like html of jsp,I always get the old pages after I change some logic in the java code.It takes several times' re-compile or refresh to get the right one.I wonder if it's the cache problem?And sometimes this happens to my tomcat server:tomcat can't open in a project for some problem,and it's still the same crash after I delete the project unless I restart Eclipse,I wasted a lot of time on this kind of problem.If I can't solve this ,how can I reduce this kind of issue?Seek help.
Your browser may indeed be caching the webpages. Try refreshing using Ctrl+F5 or disable the browser cache altogether.
I am working on a GWT project. After having made changes server-side and compiled it useing GWT Compile, the changes are not reflected when I deploy the application on Tomcat Server. But if I run the application in dev.mode in Eclipse, the changes are reflected!
Any idea how to make the compiler use the latest code?
I have deleted all compiled filed, build and cleaned the project tons of times - none of it working.
This is typical if your cache settings aren't correct. Your broswer doesn't download the changed files because it has the old ones in cache and doesn't know they changed.
Try erasing the browser cache and/or pressing ctrl-f5 in your browser.
On production systems, you need to properly configure you web server to explicitly cache GWT files matching *.cache.*, and explicitly NOT caching *.nocache.*.
See this for a server filter example that takes care of the cache configuration (i.e., as geert3 explained so your server does not let your browser cache an obsolete version, search for section with requestURI.contains(".nocache.")) and to make your app crawlable as well.
We're trying to force the client's browser to reload static files when they change. Currently, we have our build scripts automatically creating a new directory with the build timestamp and replace the content in the code to point to that directory.
However, I feel this is hardly an optimal solution. It forces the client browser to load every single file if a new build exists, even if only 1 file changed, and build time increases considerably by scanning every file and replace every static file reference.
I know we can also set the version when we declare files (something like < link src="blahblah.css?version=1.1" />), but this forces us to change all our code to include a version placeholder and still have our build scripts replacing it.
Is there a smarter way to do this? We're using Spring MVC. Is there any option in mvc:resources that I'm not aware of to do this without changing code? Or something on web.xml?
We're using tomcat. Is there a way to do this at server level? Would it help to use a cache like Varnish or something? Or these caches only allow to set expiry times and not check that the file changed? Bear in mind I'm not comfortable at all in server and cache configuration tasks.
I found out about this project https://code.google.com/p/modpagespeed/, but since it's far from my comfort zone, I'm struggling to understand capabilities and if this helps with what I want.
Anyone has any ideas?
Thanks
You can use version as a query parameter, e.g. /resources/foo.js?_version=1.0.0. If you are using Maven, it is not that hard to get version information from /META-INF/maven/{groupId}/{artifactId}/pom.properties. Of course this will force reload all scripts with every new version... but new versions are probably not deployed that often.
Then it is always a good practice to properly set HTTP caching headers. <mvc:resources> should correctly handle Last-Modified header for you. And you can set cache-period to make browser check the for resource modifications more often.
Here is a working solution: CorrectBrowserCacheHandlerFilter.java
Basically, when your browser requests the static files, the server will redirect every requests to the same one but with a hash query parameter (?v=azErT for example) which depends on the content of the target static file.
Doing this, the browser will never cache the static files declared in your index.htmlfor example (because will always received a 302 Moved Temporarily), but will only cache the ones with the hash version (the server will answer 200 for them). So the browser cache will be used efficiently for those static files with hash version.
Disclaimer: I'm the author of CorrectBrowserCacheHandlerFilter.java.
I'm using Google AppEngine with their built in web server. My development goes about in a simple way: I make changes to my .java sources or .jsp and compile using ant and to see the changes I have to restart the development server.
I'm wondering if there's a way I can avoid this last step of restarting my development server - somehow refresh the cached classes context of my web-server. The options provided by Google on this dev server are quite limited and am wondering if there's a better way.
I would like to avoid using something like JRebel which I could buy, but for this simple project I'm just wondering if I can remove the burden of restarting my web-server... otherwise I'll live with it.
I realized that you can just touch
appengine-web.xml to force server context reload. Also loading the
page under /_ah/reloadwebapp will reload the servers context - even if
it gives you a 404, it will still reload the context.
In debug mode, the JVM can perform some hot swapping - I know and Intellij IDEA does it, i m sure other debuggers in other IDE's does it too.
Start the app server with the debug flag (-Xdebug -Xrunjdwp:transport=dt_socket,address=127.0.0.1:8000 for example), then connect the debugger to the app server.
Then, make a change to the source that is not a method signature or class field change. Recompile, and voila, the debugger hot swapped the class into the jvm being debugged!
This only really works semi-well. But it may just be enough.
I am developing a web based java app, running on jboss and sql server.
I seem to find myself spending an inordinate amount of time recompiling/deploying just to tweak the interface in jquery/javascript/css/html.
Any tips for reducing the turnaround ?
Its deployed to an ear file, so I can not alter the jsps/javascript after deployment(?). Yes, I have created the a static version of the webpage frontends but they do not give me the full functionality - none of the data from db/jstl processing.
To clarify its not so much the actual compile time itself (30seconds) as the ant builds are set-uo well and are very modular; its the subsequent deployment to jboss and accessing the application that cause the real headache.
If you do not work directly in an exploded war inside the hotdeploy folder of JBoss, then strongly consider it.
when developing with application server i've used this product in the past: JRebel from zeroturnaround.
It will prevent having to restart and redeploy an application running within an application server. It works for most scenario's however i found that there were a few occasions when a server restart were required(in my case making changes to the application initialisation). But if you're only working on the interface this product will save you a great number of deployments and restarts.
I have not used Jrebel in combination with JBoss but they mention it as a supported container so thta shouldn't be a problem.
I am an average web designer (at best!) and writing complicated HTML and CSS is a pain for me. A lot of what I do with styles and layout is trial and error and involves a lot of tweaking. I also change my mind frequently about exactly what shade of color I want things. Basically, I'm in the same boat as you.
Long ago I abandoned the idea of the tweak-deploy-test iteration cycle (mvn clean tomcat:deploy takes 2 minutes on my current project) as by the 10th iteration trying to sort a simple layout problem and waiting for the deployment would drive me round the bend. I now use two strategies;
Get a static copy of the HTML I want to work with. This usually means deploying the app, navigating to the page and saving it to a work directory somewhere. This saves the static HTML as well as any images. Next I copy the CSS files from my workspace into the work directory and hand edit the saved HTML file to point to these CSS files.
Open the static HTML page in Firefox. Now I can tweak the CSS or HTML and simply refresh Firefox to show the changes. Iteration time is now down to about 1 second. I can further improve my tweaking using the Firebug addon. This allows you to manipulate the CSS and HTML from within Firefox. This is especially useful for getting margin and padding size right. Once I've tweaked it in Firebug I hand edit the saved HTML and CSS then refresh Firefox to make sure I'm happy with the result.
At certain key stages I then make the changes to my workspace to reflect my tweaking on the static files. I then redeploy and test to make sure I got it right. As I use Firefox for all my development I have to pay special attention to browser compatibility, especially with IE, but this usually comes at a later stage.
Edit:
I didn't mention Javascript, but this process works great for JS too!