Group items tagged

it could be implemented as follows: The developer creates a CName record from *.<developersAppSubDomain>.<developersDomain>.com to <appEngineAppId>.appspot.com (if wildcard CName values aren't available on the developer's DNS server, then the developer will have to create one entry per customer). When Google receives a request on the App Engine Server with an unknown host name such as <subdomain>.<customersDomain>.com, it does the CName look-up, until it finds a host name of the form <appEngineAppId>.appspot.com. It then sends the server request on to that App Engine application, ideally including the whole CName "chain" as a special CGI variable, so that the application can determine the user ID of the customer that owns the domain. (And if the App Engine server doesn't find a host name for an App Engine application, it returns 404.)

I figure it is going to take me at least four iterations to get this right. The first one will be building a GWT application with a simple UI that has no server logic behind it (just to learn how layout in GWT works). Step two will be adding a fake servlet backend (not app engine, just in memory). While not exactly App Engine yet, I should have a completely specified client-server API by the end of this process that I can subsequently implement on App Engine (iteration 3). Iteration four will handle deployment, CSS and whatever I may screw up in iterations one and two. I will log my notes of things I run into while I code.

The easiest way to get setup rapidly is to download the template project from the download section. It provides a ready-to-go project with the right configuration files pre-filled and an appropriate directory layout: web.xml preconfigured with the Gaelyk servlets appengine-web.xml with the right settings predefined (static file directive) a sample Groovlet and template the needed JARs (Groovy, Gaelyk and Google App Engine SDK)

Running your application locally Google App Engine provides a local servlet container, powered by Jetty, which lets you run your applications locally. If you're using the Gaelyk template, when you're at the root of your project — and we assume you have installed the App Engine SDK on your machine — you can run your application with the following command-line: dev_appserver.sh war

Deploying your application in the cloud Once you're at the root of your application, simply run the usual deployment command: appcfg.sh update war

Cron jobs / task queues Instead of using a framework like Quartz to schedule jobs, Google App Engine takes care of executing jobs for you. You simply enter a cron-like expression and a URL to call and your job is configured. You also have a task queue at your disposal. Your application code can add tasks to a task queue which will be executed later in the future, asynchronously. An example use case is that you don’t want clients to wait for an email to be sent before he sees the next page. Instead you can put the email task on the task queue and the email will be sent asynchronously.

When an email is received Google App Engine does a post on an URL in your application you configured. The HTTP body of the POST request contains the exact mime message as it was received by Google. To parse this mime message you can use the MimeMessage class provided by the JDK.

we can build the start of an open source App Engine server clone that's suitable for many purposes:  initially just for regression testing & local development (like the "dev_appserver" that comes with the App Engine Python SDK), but perhaps in the future (once Hypertable/Hbase/etc are ready) a full stack to give to ISPs to let them run App Engine apps on their own.

The GAE docs talk about how to setup a test to use the datastore.  But also follow the instructions here until the docs are fully updated.

The data loader feature communicates with your application running on App Engine using remote_api, a request handler included with the App Engine runtime environment that allows remote applications with the proper credentials to access the datastore remotely. To use remote_api, you must map a URL to it.

Yes, worker would be a servlet which can handle a request with POST parameters. If you want an asynchronous call from client's point of view then RPC is enough (from server's point of view it is still synchronous). If you want to do "delayed" jobs which don't talk to your client, you can use a task queue.

Instead of trying to create a thread (which is impossible in App Engine), this is a great way to asynchronously run tasks.

GaeVFS is an Apache Commons VFS plug-in that implements a distributed, writeable virtual file system for Google App Engine (GAE) for Java. GaeVFS is implemented using the GAE datastore and memcache APIs. The primary goal of GaeVFS is to provide a portability layer that allows you to write application code to access the file system--both reads and writes--that runs unmodified in either GAE or non-GAE servlet environments.

Authentication with App Engine, regardless of where you're doing it, is a three-stage process: Obtain an authentication token. This can be done with ClientLogin for installed apps, for example, or with AuthSub for a webapp. When logging in directly to an application, this is the part of the login process where your user sees a Google signin screen. Take that authentication token, and use it to obtain an authentication cookie. Use that authentication cookie in all subsequent requests.

Google app engine uses the concept of static files. This is a performance optimization. Using the file appengine-web.xml you can configure the way google handles static files. You can include and exclude certain files using their extension or name. More information can be found here at google. This all works nice in the online version, however there seems to be a problem with the development server. Some solutions try to configure the local version as well, still that did not work for me. I decided to look for a servlet that serves static files.

That is it, now you can test your stuff locally and all your scripts, images, styles are loaded by your application. Of course you have to remove this servlet before uploading your application. Hope it helps people with their local debugging of jquery scripts or other javascript things.

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.*

Google App Engine applications written in Java can write information to the log files using java.util.logging.Logger. Log data for an application can be viewed and analyzed using the Administration Console, or downloaded using appcfg.sh request_logs. More info in the Logging documentation.