I shifted from Eclipse to Jdeveloper. I had a weird problem that I was able to solve but not able to understand.
Whenever I made any changes in HTML in Jdeveloper's web projects the changes were not reflected when I ran the HTML again. The old webpages kept coming in the webbrowser. Same source code. Same CSS/JS. I found that as long as there were proxy settings in my web browser the changes were not reflected. But if I switched off the proxy the changes made in HTML were reflected i.e webpage were displayed with the changes made from last time.
By proxy set I mean proxy setting placed at the following
Window -> Start Menu -> internet options -> Connections -> LAN Settings -> Proxy Server
I have tried to run the resulting URL on Google chrome, Firefox and internet explorer. As long as the web browser was using proxy the changes made in HTML were not shown by running it again.
In Eclipse Juno I simply had to clean Tomcat's directory to get changes reflected.
Anyone can explain why this happens?
Web servers return HTTP headers with every response, and usually those headers specify how long the response can be cached for. Proxy servers read those headers and make a decision whenever they see the same request again -- whether to propagate that request to the server again, or to simply return the cached copy of the response.
You can modify your server's configuration so that it the next time it tells the proxy server not to cache pages. However, some proxy servers are mis-configured or broken, and will cache pages that they are not supposed to cache.
For those cases, one ugly solution that works is to give your JS and CSS files new names whenever you change them. For example, if your index.html file includes index.css and index.js, and you make a change to index.js, you can save the changed file as index.2.js and change the tag in your index.html file to point to index.2.js from now on.
That's a bit drastic, but it works. A simpler solution to start with is to refresh your page using Shift-F5 rather than just F5 (in your browser). That tells the browser to force a refresh of all cached pages, whenever possible.
This seems tied to your proxy server type. There are several proxy server types, one of which is a "Caching Proxy Server". Which, if many users are connected to it, allows static pages to be stored locally on the server for repetitive requests from the client(you). When you change the proxy it is most likely just sending you an updated copy due to not having you as an active client, or being that you are a new user.
I would assume that the content on the new software you are building is precaching saved page names where as Eclipse Juno is was generating real time screens on the fly, bypassing the cached server option.
Related
I have a enterprise GWT product that runs on Tomcat8 on a retail store's local server. I have an independent daemon running that check for and installs updates The update process consists of downloading the file, stopping Tomcat, putting the updated file in place, and restarting Tomcat.
Now, if the user has this scheduled for 2 in the morning when no one is using the app, that's fine.
But, they also have the option to go into the admin settings and manually click a button to apply the update. When they do this, I'd like to be able to put up some sort of page when someone tries to access the app saying it's upgrading, and then have the browser refresh when it's back online (if they are sitting on the temp page.)
Does Tomcat facilitate this somehow? I don't feel like GWT can, because Tomcat isn't serving it up for it to be able to do anything. My app can be installed on Windows or CentOS, if that matters.
To address your issue we can do any one of the following
Once user click on upgrade button start showing him some masked view. Behind this view you can write down a timer which will keep hitting some dummy serivce/rpc call from server after specific time interval. Based on the response code you can understand whether tomcat is up or not.
We can write down some kind of web socket. Which do above job for us and try to connect automatically once server is up and running. Using events from such socket we can hide our upgrading view and take back user to required screen.
I have a GWT Web App (which requires a login) that calls a method on the Servlet (running in Tomcat) to generate a PDF file. The Servlet returns a URL to the file and opens the PDF in an iFrame.
Frame frame = new Frame(reportUrl);
frame.show();
Upon closing the frame (or browser), a request is made to delete the file that was generated server side. Now here is where the problem lies. If I log out of the web application, and open a new tab in IE, it shows the URL in the history that was used to display the PDF. Ideally this file is no longer accessible since it has been deleted on the server, and the user is no longer logged in, however the PDF still displays in the new tab. I assume this is because the PDF file is being cached.
I am unable to reproduce this behavior in Chrome, so I assume the file either isn't being cached in Chrome, or Chrome just handles things a little differently. Long story short, how do I make sure the file/url is no longer accessible once the user logs out of the web app?
Theoretically this is impossible, as you can't remotely clear the client-side cache. Also the user may have used wget or whatever to download the file so you can't assume information will be 100% inaccessible after the session has expired.
That being said, caching hints in the HTTP response headers can to some extent steer what a (well-behaved) client caches. As always implementation differs accross browsers. You can set HTTP headers either from your servlet directly in Java, or you can add them for instance from Apache HTTPD specifying cache headers for instance for all PDF downloads.
There are many resources on cache headers in HTTP, here's a good one: http://www.mobify.com/blog/beginners-guide-to-http-cache-headers/
I've also seen that HTTPS connections cause IE to be much stricter in what it caches, not sure if that is relevant/an option for you.
As per my understanding files are cached by the browser by default. Developers don't have to set specific
headers to enable the caching of these files. Right?
If yes, how come browser know that it has to enable caching for specific types of files only not for servlet/jsp calls. For example :- if i make call to same servlet
request goes to server side and fresh page is served (not the browser cached paged).
Now I have a problem:
user opens web app page, gets javaScript (ModuleName.nocache.js);
Then I update client side (roc requests, view etc).
user didn't close web app tab in browser, didn't update page. He clicks somewhere and gets random explosion. For example, RPC doesn't work, servlets moves anywhere, there is many errors or not.
Now I want to implement scenario:
User must have cookie attribute with web app version.
By request I see it and in response force him to update page (don't know how).
If user's request can't be delivered gwt force him to update page (don't know how).
But I think there must be a best-practice-way to solve this problem.
Catch IncompatibleRemoteServiceExceptions and StatusCodeExceptions in your AsynCallbacks. The first one tells you the client-side code is not compatible with the server-side code; the second can tell you that there no longer is a RPC servlet there (look for a 404 status code).
You can then show a message to the user prompting him to reload the page (this is what Google Groups does for example).
That said, there are some ways to mitigate this if the changes are relatively small: you can keep the old serialization policy files around server-side so the server can process requests from different client versions. The changes have to be somehow backwards compatible though.
You could then detect the client version on the server-side (either using a list of the latest serialization policy files and checking whether the client is using one of them or an older one; or using a request header or cookie) and include something in the response (response header or cookie) telling it there's a new version.
Or you could regularly poll the server (obviously not using RPC though) for the latest version of the app.
Another approach:
If it is empty (if not, go to next step), save the com.google.gwt.core.client.GWT.getPermutationStrongName(); in your LocalStorage or in your Cookies and finish the flow.
When your app loads, get the permutationStrongName again, and check if the saved one is different.
If it is different force to request to the server everything (if you want/need "break" async process you can use GQuery - promises). Then, replace in your LocalStorage or Cookies the new gwt's permutation id.
You can do this always that your app is loaded (is not a big deal). And you can now when the version on your server has changed.
Is there a way to modify an HTTP request using Chrome dev tools or Firebug? For example when developing locally and testing in Chrome, I have a page that needs an HTTP request to fill some data. Because it's local, that service isn't available.
Currently the only way of getting around the problem is configuring a proxy pass in Apache so it hits a QA environment for that call. I'm looking or a simpler way to achieve this because I use Jetty to test the app and can't configure a proxy pass (or that I know of).
In other words, is there a way to create a temporary proxy pass for the current session when testing an app locally?
This might help in some cases - use fetch command to send another, tampered, request. here's how to do it in Chrome:
open DevTools, tab Network
clear
create your request normally
right click that request and select Copy > Copy as fetch
go to Console tab and paste
tamper the data and hit Enter
You can use tweak chrome extension and you'll be able to do exactly that, intercept and modify HTTP requests.