Google AppEngine

build-time substitution. Here’s our appengine-web.xml: <?xml version="1.0" encoding="utf-8"?> <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application>${gae.app.name}</application> <version>${friendlyversion}</version> <system-properties> <property name="java.util.logging.config.file" value="WEB-INF/logging.properties"/> </system-properties> </appengine-web-app>

At build time, I use the AntRun plugin (lines 97-118) to create a small file under the target directory that holds a ‘sanitized’ version of the standard Maven version. (I.e. “1.0-SNAPSHOT” becomes GAE-friendly “1-0-snapshot”.) I then use the Maven filter functionality available in the WAR plugin (lines 80-96) to copy the appengine-web.xml into its proper directory with the version substituted in.

3. Adds a new gae:start goal. This is identical to gae:run, except that it does not automatically execute the package phase before starting the server. The intent is to use this in a project POM, but it can also be used to start the server quickly when you don't want to rebuild the project. Right now I just copied the RunGoal completely, except for the '@execute phase="package"' declaration, because I didn't want to introduce conflicts in case someone else is editing RunGoal.java. A better thing to do in the future would be to have RunGoal extend StartGoal with an empty class that just adds the '@execute phase="package"' annotation (it can't be the other way around, with StartGoal extending Run goal, because there's no way to override a mojo with an @execute annotation with one that doesn't have it---it gets inherited automatically).

The idea behind all of these changes is to make it so that you can use the maven-gae-plugin in a project's POM for automated integration tests. The gae:start goal automatically binds to the pre-integration-test phase by default, and the gae:stop goal binds to post-integration-test. This is most useful when combined with something like the maven-failsafe-plugin and a functional testing library like HtmlUnit that you can use to simulate web requests. It would also be useful for Selenium testing.

About loading request/performance, there're lots of discussions that you can find in the groups, please just try google it. Here are some notes based on reading those. Latency causes by 1- time to start new JVM 2- time to load your application To reduce load time by 1) others star request to a) pay to reserve JVM b) request Google to load your app before start dispatch request to that instance c) accept the situation For 2) we try to a- try to use/replace frameworks with light-weight ones: datastore access framework, MVC framework,... b- try to limit calculation in your index page to alleviate the impact of loading request c- design your object model based on your need, so that you do calculation at insert time, not at query time. For example, in my app, if I want to report on year and quarter, then I have 5 summary "record" for those, instead of querying and computing those d- caching result. For example, If I know 1 one 5 piece of data above would be read frequently, then I will read those 5 all, and put into memcache for later use ... So it's application-specific, I don't know if each of above can help you. But only you who can know if which one of your code can be cached and how...

Personally, I would recommend using the blobstore API for this since it is officially supported by google and means it won't break in the future. It also has nice bindings into the imageservice. http://code.google.com/appengine/docs/java/blobstore/overview.html

The Blobstore API provides two types of functions:   An ability to upload and save the blob automaticallyThe BlobstoreService which is provided by the com.google.appengine.api.blobstore.BlobstoreService allows us to specify a URL where users can upload their large files. You can think of this url as the action element in the HTML form. The implementation at this URL is internal to the BlobstoreService. But what it does is significant. It will extract out the file contents that you uploaded and store it as a Blob in the database. Each blob that is stored in the database is associated with the a Blob Key. This Blob key is then provided to your url and you can then use the Blob Key to do anything within your application. In our case, we form a url that is tweeted to the users who can then view the picture that we uploaded. An ability to serve or retrieve the blob.The BlobstoreService also provides an ability to serve or retrieve the blob that was saved successfully. It will provide the blob as a response that could then use as a source in an <img> element for example. All you need to do is provide it the Blob Key and the response stream and in return, it will provide the content properly encoded as per its type that you could then use.

This article studies the proxy technique first and then turns to the Google AJAX Feed API method, giving you a chance to intermix Java™and JavaScript coding.

You need a service that, when given a feed URL, connects to that site, downloads its contents, and sends them back to the caller. (For a shell-line parallel, consider the wget or curl command.) You can do this many ways, and Listing 2 shows a simple way to accomplish the task. Because I decided to call my remote proxy RemoteProxy, the server-side class had to be called RemoteProxyImpl; Impl stands for "Implementation."

The SOP won't let your code get data from another site, but there's an exception: You can download and execute JavaScript code using the <script ... /> tag. If the code you download happens to include data and calls a function of yours that puts the data to good use, then you have managed to bypass the SOP. Here's the idea behind the Google AJAX Feed API: It uses the <script ... /> tag to call a Google site that works as a proxy. The remote site gets the feed data and returns it in the form of JavaScript code. The downloaded JavaScript code calls your function so you can process the incoming XML

Just so you know, because it isn't documented, you can choose the tag name of the root element with UiBinder (the HTMLPanel(String,String) constructor), just use a tag="" attribute, e.g. <g:HTMLPanel>This will use a div element</g:HTMLPanel> <g:HTMLPanel tag='p'>While this will use a p element</g:HTMLPanel> You can then use an HTMLPanel as the root of your UiBinder and build your widget as a Composite, passing the HTMLPanel built by UiBinder to the initWidget method.

I was very pleased to see that the new OAuth API provides the same interface as the Users API, but I see a missed opportunity here:

my problem is that there are two versions of the method: google.appengine.api.oauth.get_current_user() google.appengine.api.users.get_current_user() one works with OAuth and one with sign-in (or am I wrong?).

this tip can cut a few hundred milliseconds or more off of your cold start time. Using JSPs slows you down in two ways: If you have a file with a .jsp extension, anywhere in your website directory, appcfg will detect that you use JSP, and it will add 8 libraries that are used for processing JSPs into your lib directory before uploading to the app engine.  These libraries total two megabytes in size, and simply having them in your lib directory slows your cold starts down by a few hundred milliseconds. If you are interested in what libraries these are, you can see them in the temporary folder appcfg creates while uploading your app. The first JSP file accessed after a cold start, even an empty one, will take a few hundred additional milliseconds to be processed.  I'm not sure what causes this, maybe it has to do with initializing the JSP processor.

disabling session id in code will not stop the cookie from saving session id. When you enable session in app engine xml file than you are telling the framework that you don't want to save sessions in cookies (client side), instead you want to save them on server i.e. using _ah_session. Cookies JSession id is default behavior of Java session mgmt. And it is nothing to do with APP engine framework.*