Whenever I run Google App Engine it seems to be running an older version of the servlet than the last one I've saved.
What's going on? How can I fix this?
I'm using the GAE Eclipse Plugin.
I think this is a common pitfall. I also ran into a couple of times.
You should delete the cookies and the cache from Chrome.
If this isn't working, you should terminate and restart the server at eclipse all the time, when you modify the server side code.
Related
I just upgraded to the App Engine 1.7.6 SDK for my python app and realised that breakpoints no longer work in PyDev (Eclipse plugin) when using the new dev_appserver.py.
Does anyone know of a way of enabling them again? I assume the new server is spawning a new process for the web server, and the debugger isn't attaching to that one. I'm not sure how to configure it to do that though.
In the meantime I am using the old_dev_appserver.py server.
UPDATE 2012-07-27:
Following the comment, I verified, the issue is solved after updating to
PyDev. 2.8 and App Engine 1.8.2
OBSOLETE:
I found the following analysis of the problem at googleappengine issues tracker
The reason why PDB doesn't work is because dev_appserver is using
stdin/stdout for interprocess communication. Python has built-in
libraries for IPC: http://docs.python.org/2/library/ipc.html.
dev_appserver should use these, and then stdin/stdout can be left
alone so that PDB still works.
So it seems that there is no workaround, rather than reverting to use old_dev_appserver.py
UPDATE 2013-04-23:
Inability to debug is annoying.
Many developers complain about it
PyDev Breakpoints in App Engine 1.7.6 broken?
https://groups.google.com/forum/?fromgroups=#!topic/google-appengine/ep5BWYKpQpU
https://groups.google.com/forum/?fromgroups=#!topic/google-appengine/TCQuJpF44cY
https://code.google.com/p/appengine-devappserver2-experiment/issues/detail?id=28
https://code.google.com/p/googleappengine/issues/detail?id=9012
I am keeping track of the development of this issue here:
http://goo.gl/XRU01
Yep, ran into the same problem.
Open your Run/Debug Configuration and set the Main Module to:
${GOOGLE_APP_ENGINE}/old_dev_appserver.py
Do you mean pdb.set_trace() isn't working?
Look for the function MonkeyPatchPdb() in google/appengine/tools/dev_appserver.py
Run that somewehere in your own project before you use pdb and it should fix it.
I have a simple app running on tomcat (using Postgresql). I deployed it to the Cloud-Foundry using the STS plugin and it runs OK. Recently I've encountered serious compilation problems (related to JS and JQuery) which led me to re install my STS. Now, when I run the app locally it runs perfect but when I use "Update & Restart" nothing happens - my new updates are not deployed! (I'm connected and Start/Stop works). I don't have a clue for how to tackle this. Please help.
Since you have reinstalled your STS, I would suggest you delete your app from Cloud Foundry and deploy your project from STS again. It might be because your project is not being linked with the app you have on cloudfoundry.com
Try that and let us know how it goes.
I'm working with Google App Engine in Eclipse w/ JSP pages in Windows 7.
I already have an app deployed and working, but I am unable to make changes to it for some reason.
If I make changes and debug locally, my localhost page is showing the changes that I implement.
While I am not getting any errors in the deployment, the same changes that work on my local debug are no longer showing up, so I can't update my app.
I thought updating the version number might help, but I had no luck with this.
Any ideas? Thanks.
Are you deploying the same version (as specified in appengine-web.xml) as the default version that is running on your app? If not, you'll have to access your new deployment at http://newversion.appname.appspot.com, or change your default version in app engine to your newly deployed version.
I have had the same problems too, especially when the changes concerned the static pages. Some little things to check:
If you have set an expiration date in your app.yaml, your browser cache could be holding the file.
If it’s specific to the online contents, it could be an intermediary cache (such as a squid server) serving the outdated contents, in which case you’d have to flush the cache to get the new version.
You could start by checking the log on the GAE console to see if the request is received by the server, that would help you debug.
Another trick, if you’re being served an outdated version of http://yourapp.appspot.com/index, try and pass a dummy argument to force the browser to update the version, for instance : http://yourapp.appspot.com/index?p=1
I'm developing an application using the Vaadin framework in Eclipse. I'm using the Tomcat v6.0 servlet and run the application in the Eclipse Web Browser. A problem I've been having though is to have recent changes show in the browser when I test the application.
No matter how many times I restart Tomcat, clean all published resources and restart the Eclipse Web Browser the changes still won't take effect. The changes seem to take effect randomly where time is the biggest factor, which is of great frustration when developing...
So my question is if anyone else has noticed this problem and have any ideas of how to solve it, if there is a configuration I can do or if I'm missing a step in the restart which blocks the changes from taking effect..?
Any help would be greatly appreciated!
In Vaadin most of the code runs in the server and is contained in normal Java files. There are three levels of resource/class changes:
The runtime "hot code replacement". If running Tomcat in debug mode some Java class changes can be published without redeploying the web application. However, if the Tomcat is configured to "auto publish" (check your server settings in Eclipse), the redeployment is automatically done whenever classes change and this causes full context reload and sessions serialization (see #2) . Hot code replacement can be enhanced using tools like JRebel.
Web application deployment. This is essentially deploying a new war file to the server. Causes the previous version to be undeployed and deploys the new version of all classes and resources. Sometimes there are some resources left in the servers work directory or classes are not reloaded, in which case the server restart (#3) is needed.
Server restart. This makes the whole JVM to reload and all the classes and web applications are also reloaded. Still cleaning the work directory separately is needed to make sure everything is reloaded.
In addition to this there is the client-side part of Vaadin (essentially a JavaScript compiled with GWT), which is treated as a static resource by Tomcat. If you modify the client-side Java code the GWT is used to recompile the JavaScript. Deployment should be simply file copying. The browsers cache the generated HTML/JS files, but GWT includes mechanism to avoid this.
You should first try to change the server settings for automatic publishing and see if that helps. Also, I've noticed that different Tomcat version behave differently. This is unfortunate, but the only thing you can do is to try to find the versions/set-up that works for you.
Just to make sure: you have been adding ?restartApplication in the URL to force application to restart on page reload, haven't you?
I've got a strange situation; when I run a Flex app from Eclipse (i.e. click run as web app), my remote calls always hang.
In Firefox, they return as failed.
But when I open up a browser and browse to my .html file in the bin-debug folder, the remote calls work.
Why is that?
Thanks for any helpful tips!
p.s. I'm accessing a websphere server and authentication is required but a Java developer hardcoded his ID in.
One thing to check:
Do you have a breakpoint set in your code somewhere? Eclipse may be waiting for you to interact with it so the program execution can continue. On my Win7 machine, when the debugger takes over, eclipse often does not take over focus; so I have to manually minimize IE.
My problem was solved today and the issue was getting through to the IBM websphere server; the authentication was still in place and the java developers had to create a cloned environment where authentication was not required. Thank you everyone for their helpful answers.