[Fuente: https://developers.google.com/appengine/docs/java/gettingstarted/]
This tutorial describes how to develop and deploy a simple Java project with Google App Engine. The example project, a guest book, demonstrates how to use the Java runtime environment, and how to use several App Engine services, including the datastore and Google Accounts.
This tutorial has the following sections:
Introducción
Welcome to Google App Engine! Creating an App Engine application is easy, and only takes a few minutes. And it’s free to start: upload your app and share it with users right away, at no charge and with no commitment required.
Google App Engine applications can currently be written in Java, Python, or Go. This tutorial covers Java. If you’re more likely to use Python to build your applications, see Getting Started: Python. If you want to use Go, see Getting Started: Go.
In this tutorial, you will learn how to:
- build an App Engine application using standard Java web technologies, such as servlets and JSPs
- create an App Engine Java project with Eclipse, and without
- use the Google Plugin for Eclipse for App Engine development
- use the App Engine datastore with the Datastore API
- integrate an App Engine application with Google Accounts for user authentication
- upload your app to App Engine
By the end of the tutorial, you will have implemented a working application, a simple guest book that lets users post messages to a public message board.
Installing the Java SDK
You develop and upload Java applications for Google App Engine using the App Engine Java software development kit (SDK).
The SDK includes software for a web server that you can run on your own computer to test your Java applications. The server simulates all of the App Engine services, including a local version of the datastore, Google Accounts, and the ability to fetch URLs and send email from your computer using the App Engine APIs.
Getting Java
Google App Engine supports Java 5 and Java 6. When your Java application is running on App Engine, it runs using the Java 6 virtual machine (JVM) and standard libraries. Ideally, you should use Java 6 for compiling and testing your application to ensure that the local server behaves similarly to App Engine.
For developers that don’t have easy access to Java 6 (such as developers using Mac OS X), the App Engine SDK is compatible with Java 5. You can upload compiled classes and JARs made with Java 5 to App Engine.
If necessary, download and install the Java SE Development Kit (JDK) for your platform. Mac users, see Apple’s Java developer site to download and install the latest version of the Java Developer Kit available for Mac OS X.
Once the JDK is installed, run the following commands from a command prompt (for Windows, Command Prompt; for Mac OS X, Terminal) to verify that you can run the commands, and to determine which version is installed. If you have Java 6 installed, these commands will report a version number similar to 1.6.0. If you have Java 5 installed, the version number will be similar to 1.5.0.
java -version javac -version
Using Eclipse and the Google Plugin for Eclipse
If you are using the Eclipse development environment, the easiest way to develop, test and upload App Engine apps is to use the Google Plugin for Eclipse. The plugin includes everything you need to build, test and deploy your app, entirely within Eclipse.
The plugin is available for Eclipse versions 3.3, 3.4, 3.5, 3.6, and 3.7. You can install the plugin using the Software Update feature of Eclipse. The installation locations are as follows:
- The Google Plugin for Eclipse, for Eclipse 3.3 (Europa):
https://dl.google.com/eclipse/plugin/3.3
- The Google Plugin for Eclipse, for Eclipse 3.4 (Ganymede):
https://dl.google.com/eclipse/plugin/3.4
- The Google Plugin for Eclipse, for Eclipse 3.5 (Galileo):
https://dl.google.com/eclipse/plugin/3.5
- The Google Plugin for Eclipse, for Eclipse 3.6 (Helios):
https://dl.google.com/eclipse/plugin/3.6
- The Google Plugin for Eclipse, for Eclipse 3.7 (Indigo):
https://dl.google.com/eclipse/plugin/3.7
For details on how to use Software Update to install the plugin, and how to create a new project, see Using the Google Eclipse Plugin.
Using Apache Ant
If you want to compile and run your application using the command line, or an IDE other than Eclipse, you will need to install something to manage this process. Apache Ant is one such solution. Full directions on installing and setting up Apache Ant to work with App Engine can be found at Using Apache Ant.
Getting the SDK
If you are using Eclipse and the Google Plugin, you can install the App Engine SDK from Eclipse using Software Update. If you haven’t already, install the “Google App Engine Java SDK” component using the locations above.
If you are not using Eclipse or the Google Plugin, you can download the App Engine Java SDK as a Zip archive.
Download the App Engine Java SDK. Unpack the archive in a convenient location on your hard drive.
Note: Unpacking the archive creates a directory whose name is something like appengine-java-sdk-X.X.X, where X.X.X is the SDK version number. Throughout this documentation, this directory will be referred to as appengine-java-sdk/. You may want to rename the directory after unpacking.
Trying a Demo Application
The App Engine Java SDK includes several demo applications in the demos/ directory. The final version of the guest book application you will create in this tutorial is included under the directory guestbook/. This demo has been precompiled for you so you can try it right away.
If you are using Eclipse, the SDK is located in your Eclipse installation directory, under plugins/com.google.appengine.eclipse.sdkbundle_VERSION/, where VERSION is a version identifier for the SDK. From the command line, change the current working directory to this directory to run the following command. If you’re using Mac OS X or Linux, you may need to give the command files executable permissions before you can run them (such as with the command chmod u+x dev_appserver.sh).
If you are using Windows, start the guest book demo in the development server by running the following command at a command prompt:
appengine-java-sdkbindev_appserver.cmd appengine-java-sdkdemosguestbookwar
If you are using Mac OS X or Linux, run the following command:
./appengine-java-sdk/bin/dev_appserver.sh appengine-java-sdk/demos/guestbook/war
The development server starts, and listens for requests on port 8080. Visit the following URL in your browser:
Note: When you start the development server from within Eclipse using the Google Plugin for Eclipse (discussed later), the server uses the port 8888 by default:http://localhost:8888/
For more information about running the development web server from the command line, including how to change which port it uses, see the Dev Web Server reference.
To stop the server, make sure the command prompt window is active, then press Control-C.
Creating a Project
App Engine Java applications use the Java Servlet standard for interacting with the web server environment. An application’s files, including compiled classes, JARs, static files and configuration files, are arranged in a directory structure using the WAR standard layout for Java web applications. You can use any development process you like to develop web servlets and produce a WAR directory. (WAR archive files are not yet supported by the SDK.)
The Project Directory
For this tutorial, we will use a single directory named Guestbook/ for all project files. A subdirectory named src/ contains the Java source code, and a subdirectory named war/contains the complete application arranged in the WAR format. Our build process compiles the Java source files and puts the compiled classes in the appropriate location in war/.
The complete project directory looks like this:
Guestbook/
src/
...Java source code...
META-INF/
...other configuration...
war/
...JSPs, images, data files...
WEB-INF/
...app configuration...
lib/
...JARs for libraries...
classes/
...compiled classes...
If you are using Eclipse, create a new project by clicking the New Web Application Project button in the toolbar: 
Give the project a “Project name” of Guestbook and a “Package” of guestbook. Uncheck “Use Google Web Toolkit,” and ensure “Use Google App Engine” is checked. See Using the Google Plugin for Eclipse for more information. The wizard creates the directory structure, and the files described below.
If you are not using Eclipse, create the directory structure described above. As you read each of the files described in this section, create the files using the given locations and names.
You can also copy the new project template included with the SDK, in the appengine-java-sdk/demos/new_project_template/ directory.
The Servlet Class
App Engine Java applications use the Java Servlet API to interact with the web server. An HTTP servlet is an application class that can process and respond to web requests. This class extends either the javax.servlet.GenericServlet class or the javax.servlet.http.HttpServlet class.
Our guest book project begins with one servlet class, a simple servlet that displays a message.
If you are not using the Eclipse plugin, create the directories for the path src/guestbook/, then create the servlet class file described below.
In the directory src/guestbook/, make a file named GuestbookServlet.java with the following contents:
package guestbook;
import java.io.IOException;
import javax.servlet.http.*;
public class GuestbookServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
resp.setContentType("text/plain");
resp.getWriter().println("Hello, world");
}
}
The web.xml File
When the web server receives a request, it determines which servlet class to call using a configuration file known as the “web application deployment descriptor.” This file is named web.xml, and resides in the war/WEB-INF/ directory in the WAR. WEB-INF/ and web.xml are part of the servlet specification.
In the directory war/WEB-INF/, a file named web.xml has the following contents:
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE web-app PUBLIC "-//Oracle Corporation//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5"> <servlet> <servlet-name>guestbook</servlet-name> <servlet-class>guestbook.GuestbookServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>guestbook</servlet-name> <url-pattern>/guestbook</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>index.html</welcome-file> </welcome-file-list> </web-app>
This web.xml file declares a servlet named guestbook, and maps it to the URL path /guestbook. It also says that, whenever the user fetches a URL path that is not already mapped to a servlet and represents a directory path inside the application’s WAR, the server should check for a file named index.html in that directory and serve it if found.
The appengine-web.xml File
App Engine needs one additional configuration file to figure out how to deploy and run the application. This file is named appengine-web.xml, and resides in WEB-INF/alongside web.xml. It includes the registered ID of your application (Eclipse creates this with an empty ID for you to fill in later), the version number of your application, and lists of files that ought to be treated as static files (such as images and CSS) and resource files (such as JSPs and other application data).
In the directory war/WEB-INF/, a file named appengine-web.xml has the following contents:
<?xml version="1.0" encoding="utf-8"?> <appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> <application></application> <version>1</version> </appengine-web-app>
appengine-web.xml is specific to App Engine, and is not part of the servlet standard. You can find XML schema files describing the format of this file in the SDK, in the appengine-java-sdk/docs/ directory. See Configuring an App for more information about this file.
Running the Project
The App Engine SDK includes a web server application you can use to test your application. The server simulates the App Engine environment and services, including sandbox restrictions, the datastore, and the services.
If you are using Eclipse, you can start the development server within the Eclipse debugger. Make sure the project (“Guestbook”) is selected, then in the Run menu, select Debug As > Web Application. See Using the Google Plugin for Eclipse for details on creating the debug configuration.
If you are not using Eclipse, see Using Apache Ant for a build script that can build the project and start the development server. To start the server with this build script, enter the following command: ant runserver To stop the server, hit Control-C.
Testing the Application
Start the server, then visit the server’s URL in your browser. If you’re using Eclipse and the Google Eclipse plugin, the server runs using port 8888 by default:
If you’re using the dev_appserver command to start the server, the default port is 8080:
For the rest of this tutorial, we’ll assume the server is using port 8888.
The server calls the servlet, and displays the message in the browser.
Using the Users Service
Google App Engine provides several useful services based on Google infrastructure, accessible by applications using libraries included with the SDK. One such service is the Users service, which lets your application integrate with Google user accounts. With the Users service, your users can use the Google accounts they already have to sign in to your application.
Let’s use the Users service to personalize this application’s greeting.
Using Users
Edit src/guestbook/GuestbookServlet.java as indicated to resemble the following:
package guestbook;
import java.io.IOException;
import javax.servlet.http.*;
import com.google.appengine.api.users.User;
import com.google.appengine.api.users.UserService;
import com.google.appengine.api.users.UserServiceFactory;
public class GuestbookServlet extends HttpServlet {
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
UserService userService = UserServiceFactory.getUserService();
User user = userService.getCurrentUser();
if (user != null) {
resp.setContentType("text/plain");
resp.getWriter().println("Hello, " + user.getNickname());
} else {
resp.sendRedirect(userService.createLoginURL(req.getRequestURI()));
}
}
}
If you are using Eclipse and your development server is running in the debugger, when you save your changes to this file, Eclipse compiles the new code automatically, then attempts to insert the new code into the already-running server. Changes to classes, JSPs, static files and appengine-web.xml are reflected immediately in the running server without needing to restart. If you change web.xml or other configuration files, you must stop and start the server to see the changes.
If you are using Ant, you must stop the server and rebuild the project to see changes made to source code. Changes to JSPs and static files do not require restarting the server.
Rebuild your project and restart the server, if necessary. Test the application by visiting the servlet URL in your browser:
Instead of displaying the message, the server prompts you for an email address. Enter any email address (such as alfred@example.com, then click “Log In.” The app displays a message, this time containing the email address you entered.
The new code for the GuestbookServlet class uses the Users API to check if the user is signed in with a Google Account. If not, the user is redirected to the Google Accounts sign-in screen. userService.createLoginURL(...) returns the URL of the sign-in screen. The sign-in facility knows to redirect the user back to the app by the URL passed to createLoginURL(...), which in this case is the URL of the current page.
The development server knows how to simulate the Google Accounts sign-in facility. When run on your local machine, the redirect goes to the page where you can enter any email address to simulate an account sign-in. When run on App Engine, the redirect goes to the actual Google Accounts screen.
You are now signed in to your test application. If you reload the page, the message will display again.
To allow the user to sign out, provide a link to the sign-out screen, generated by the method createLogoutURL(). Note that a sign-out link will sign the user out of all Google services.
Using JSPs
While we could output the HTML for our user interface directly from the Java servlet code, this would be difficult to maintain as the HTML gets complicated. It’s better to use a template system, with the user interface designed and implemented in separate files with placeholders and logic to insert data provided by the application. There are many template systems available for Java, any of which would work with App Engine.
For this tutorial, we’ll use JavaServer Pages (JSPs) to implement the user interface for the guest book. JSPs are part of the servlet standard. App Engine compiles JSP files in the application’s WAR automatically as one large JAR file, then maps the URL paths accordingly.
Hello, JSP!
Our guest book app writes strings to an output stream, but this could also be written as a JSP. Let’s begin by porting the latest version of the example to a JSP.
In the directory war/, create a file named guestbook.jsp with the following contents:
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ page import="java.util.List" %>
<%@ page import="com.google.appengine.api.users.User" %>
<%@ page import="com.google.appengine.api.users.UserService" %>
<%@ page import="com.google.appengine.api.users.UserServiceFactory" %>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>
<html>
<body>
<%
UserService userService = UserServiceFactory.getUserService();
User user = userService.getCurrentUser();
if (user != null) {
pageContext.setAttribute("user", user);
%>
<p>Hello, ${fn:escapeXml(user.nickname)}! (You can
<a href="<%= userService.createLogoutURL(request.getRequestURI()) %>">sign out</a>.)</p>
<%
} else {
%>
<p>Hello!
<a href="<%= userService.createLoginURL(request.getRequestURI()) %>">Sign in</a>
to include your name with greetings you post.</p>
<%
}
%>
</body>
</html>
By default, any file in war/ or a subdirectory (other than WEB-INF/) whose name ends in .jsp is automatically mapped to a URL path. The URL path is the path to the .jsp file, including the filename. This JSP will be mapped automatically to the URL /guestbook.jsp.
For the guest book app, we want this to be the application’s home page, displayed when someone accesses the URL /. An easy way to do this is to declare in web.xml that guestbook.jsp is the “welcome” servlet for that path.
Edit war/WEB-INF/web.xml and replace the current <welcome-file> element in the <welcome-file-list>. Be sure to remove index.html from the list, as static files take precedence over JSP and servlets.
<welcome-file-list> <welcome-file>guestbook.jsp</welcome-file> </welcome-file-list>
Tip: If you are using Eclipse, the editor may open this file in “Design” mode. To edit this file as XML, select the “Source” tab at the bottom of the frame.
Stop then start the development server. Visit the following URL:
The app displays the contents of guestbook.jsp, including the user nickname if the user is signed in. We want to HTML-escape any text which users provide in case that text contains HTML. To do this for the user nickname, we use the JSP’s pageContext so that java code can “see” the string, then call the escapeXML function we imported via the taglib element.
When you upload your application to App Engine, the SDK compiles all JSPs into one JAR file, and that is what gets uploaded.
The Guestbook Form
Our guest book application will need a web form so the user can post a new greeting, and a way to process that form. The HTML of the form will go into the JSP. The destination of the form will be a new URL, /sign, to be handled by a new servlet class, SignGuestbookServlet. SignGuestbookServlet will process the form, then redirect the user’s browser back to /guestbook.jsp. For now, the new servlet will just write the posted message to the log.
Edit guestbook.jsp, and put the following lines just above the closing </body> tag:
...
<form action="/sign" method="post">
<div><textarea name="content" rows="3" cols="60"></textarea></div>
<div><input type="submit" value="Post Greeting" /></div>
</form>
</body>
</html>
Create a new class named SignGuestbookServlet in the package guestbook. (Non-Eclipse users, create the file SignGuestbookServlet.java in the directory src/guestbook/.) Give the source file the following contents:
package guestbook;
import java.io.IOException;
import java.util.logging.Logger;
import javax.servlet.http.*;
import com.google.appengine.api.users.User;
import com.google.appengine.api.users.UserService;
import com.google.appengine.api.users.UserServiceFactory;
public class SignGuestbookServlet extends HttpServlet {
private static final Logger log = Logger.getLogger(SignGuestbookServlet.class.getName());
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
UserService userService = UserServiceFactory.getUserService();
User user = userService.getCurrentUser();
String content = req.getParameter("content");
if (content == null) {
content = "(No greeting)";
}
if (user != null) {
log.info("Greeting posted by user " + user.getNickname() + ": " + content);
} else {
log.info("Greeting posted anonymously: " + content);
}
resp.sendRedirect("/guestbook.jsp");
}
}
Edit war/WEB-INF/web.xml and add the following lines to declare the SignGuestbookServlet servlet and map it to the /sign URL:
<web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5"> ... <servlet> <servlet-name>sign</servlet-name> <servlet-class>guestbook.SignGuestbookServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>sign</servlet-name> <url-pattern>/sign</url-pattern> </servlet-mapping> ... </web-app>
This new servlet uses the java.util.logging.Logger class to write messages to the log. You can control the behavior of this class using a logging.properties file, and a system property set in the app’s appengine-web.xml file. If you are using Eclipse, your app was created with a default version of this file in your app’s src/ and the appropriate system property.
If you are not using Eclipse, you must set up the Logger configuration file manually. Copy the example file from the SDK appengine-java-sdk/config/user/logging.properties to your app’s war/WEB-INF/ directory. Then edit the app’s war/WEB-INF/appengine-web.xml file as indicated:
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0"> ... <system-properties> <property name="java.util.logging.config.file" value="WEB-INF/logging.properties"/> </system-properties> </appengine-web-app>
The servlet logs messages using the INFO log level (using log.info()). The default log level is WARNING, which suppresses INFO messages from the output. To change the log level for all classes in the guestbook package, edit the logging.properties file and add an entry for guestbook.level, as follows:
.level = WARNING guestbook.level = INFO ...
Tip: When your app logs messages using the java.util.logging.Logger API while running on App Engine, App Engine records the messages and makes them available for browsing in the Admin Console, and available for downloading using the AppCfg tool. The Admin Console lets you browse messages by log level.
Rebuild and restart, then test http://localhost:8888/. The form displays. Enter some text in the form, and submit. The browser sends the form to the app, then redirects back to the empty form. The greeting data you entered is logged to the console by the server.
Using the Datastore
Storing data in a scalable web application can be tricky. A user could be interacting with any of dozens of web servers at a given time, and the user’s next request could go to a different web server than the previous request. All web servers need to be interacting with data that is also spread out across dozens of machines, possibly in different locations around the world.
With Google App Engine, you don’t have to worry about any of that. App Engine’s infrastructure takes care of all of the distribution, replication, and load balancing of data behind a simple API—and you get a powerful query engine and transactions as well.
App Engine’s data repository, the High Replication Datastore (HRD), uses the Paxos algorithm to replicate data across multiple data centers. Data is written to the Datastore in objects known as entities. Each entity has a key that uniquely identifies it. An entity can optionally designate another entity as its parent; the first entity is a child of the parent entity. The entities in the Datastore thus form a hierarchically structured space similar to the directory structure of a file system. An entity’s parent, parent’s parent, and so on recursively, are its ancestors; its children, children’s children, and so on, are its descendants. An entity without a parent is a root entity.
The Datastore is extremely resilient in the face of catastrophic failure, but its consistency guarantees may differ from what you’re familiar with. Entities descended from a common ancestor are said to belong to the same entity group; the common ancestor’s key is the group’s parent key, which serves to identify the entire group. Queries over a single entity group, called ancestor queries, refer to the parent key instead of a specific entity’s key. Entity groups are a unit of both consistency and transactionality: whereas queries over multiple entity groups may return stale, eventually consistent results, those limited to a single entity group always return up-to-date, strongly consistent results.
The code samples in this guide organize related entities into entity groups, and use ancestor queries on those entity groups to return strongly consistent results. In the example code comments, we highlight some ways this might affect the design of your application. For more detailed information, see Structuring Data for Strong Consistency.
Note: If you built your application using an earlier version of this Getting Started Guide, please note that the sample application has changed. You can still find the sample code for the original Guestbook application, which does not use ancestor queries, in the demos directory of the SDK.
The Datastore is one of several App Engine services offering a choice of standards-based or low-level APIs. The standards-based APIs decouple your application from the underlying App Engine services, making it easier to port your application to other hosting environments and other database technologies, if you ever need to. The low-level APIs expose the service’s capabilities directly; you can use them as a base on which to implement new adapter interfaces, or just use them directly in your application.
App Engine includes support for two different API standards for the Datastore: Java Data Objects (JDO) and the Java Persistence API (JPA). These interfaces are provided by DataNucleus Access Platform, an open-source implementation of several Java persistence standards, with an adapter for the App Engine Datastore.
For clarity getting started, we’ll use the low-level API to retrieve and post messages left by users.
Updating Our Servlet to Store Data
Here is an updated version of src/SignGuestbookServlet.java that stores greetings in the Datastore. We will discuss the changes made here below.
package guestbook;
import com.google.appengine.api.datastore.DatastoreService;
import com.google.appengine.api.datastore.DatastoreServiceFactory;
import com.google.appengine.api.datastore.Entity;
import com.google.appengine.api.datastore.Key;
import com.google.appengine.api.datastore.KeyFactory;
import com.google.appengine.api.users.User;
import com.google.appengine.api.users.UserService;
import com.google.appengine.api.users.UserServiceFactory;
import java.io.IOException;
import java.util.Date;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class SignGuestbookServlet extends HttpServlet {
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
UserService userService = UserServiceFactory.getUserService();
User user = userService.getCurrentUser();
// We have one entity group per Guestbook with all Greetings residing
// in the same entity group as the Guestbook to which they belong.
// This lets us run a transactional ancestor query to retrieve all
// Greetings for a given Guestbook. However, the write rate to each
// Guestbook should be limited to ~1/second.
String guestbookName = req.getParameter("guestbookName");
Key guestbookKey = KeyFactory.createKey("Guestbook", guestbookName);
String content = req.getParameter("content");
Date date = new Date();
Entity greeting = new Entity("Greeting", guestbookKey);
greeting.setProperty("user", user);
greeting.setProperty("date", date);
greeting.setProperty("content", content);
DatastoreService datastore = DatastoreServiceFactory.getDatastoreService();
datastore.put(greeting);
resp.sendRedirect("/guestbook.jsp?guestbookName=" + guestbookName);
}
}
Storing the Submitted Greetings
The low-level Datastore API for Java provides a schemaless interface for creating and storing entities. The low-level API does not require entities of the same kind to have the same properties, nor for a given property to have the same type for different entities. The following code snippet constructs the Greeting entity in the same entity group as the guestbook to which it belongs:
Entity greeting = new Entity("Greeting", guestbookKey);
greeting.setProperty("user", user);
greeting.setProperty("date", date);
greeting.setProperty("content", content);
In our example, each Greeting has the posted content, and also stores the user information about who posted, and the date on which the post was submitted. When initializing the entity, we supply the entity name, Greeting, as well as a guestbookKey argument that sets the parent of the entity we are storing. Objects in the Datastore that share a common ancestor belong to the same entity group.
After we construct the entity, we instantiate the Datastore service, and put the entity in the Datastore:
DatastoreService datastore = DatastoreServiceFactory.getDatastoreService(); datastore.put(greeting);
Because querying is strongly consistent only within entity groups, we assign all Greetings to the same entity group by setting the same parent for each Greeting. This means a user will always see a Greeting immediately after it was written. However, the rate at which you can write to the same entity group is limited to 1 write to the entity group per second. When you design a real application, you’ll need to keep this fact in mind. Note that by using services such as Memcache, you can mitigate the chance that a user won’t see fresh results when querying across entity groups immediately after a write.
Updating the JSP
We also need to modify the JSP we wrote earlier to display Greetings from the Datastore, and also include a form for submitting Greetings. Here is our updated guestbook.jsp:
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ page import="java.util.List" %>
<%@ page import="com.google.appengine.api.users.User" %>
<%@ page import="com.google.appengine.api.users.UserService" %>
<%@ page import="com.google.appengine.api.users.UserServiceFactory" %>
<%@ page import="com.google.appengine.api.datastore.DatastoreServiceFactory" %>
<%@ page import="com.google.appengine.api.datastore.DatastoreService" %>
<%@ page import="com.google.appengine.api.datastore.Query" %>
<%@ page import="com.google.appengine.api.datastore.Entity" %>
<%@ page import="com.google.appengine.api.datastore.FetchOptions" %>
<%@ page import="com.google.appengine.api.datastore.Key" %>
<%@ page import="com.google.appengine.api.datastore.KeyFactory" %>
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>
<html>
<head>
<link type="text/css" rel="stylesheet" href="/stylesheets/main.css" />
</head>
<body>
<%
String guestbookName = request.getParameter("guestbookName");
if (guestbookName == null) {
guestbookName = "default";
}
pageContext.setAttribute("guestbookName", guestbookName);
UserService userService = UserServiceFactory.getUserService();
User user = userService.getCurrentUser();
if (user != null) {
pageContext.setAttribute("user", user);
%>
<p>Hello, ${fn:escapeXml(user.nickname)}! (You can
<a href="<%= userService.createLogoutURL(request.getRequestURI()) %>">sign out</a>.)</p>
<%
} else {
%>
<p>Hello!
<a href="<%= userService.createLoginURL(request.getRequestURI()) %>">Sign in</a>
to include your name with greetings you post.</p>
<%
}
%>
<%
DatastoreService datastore = DatastoreServiceFactory.getDatastoreService();
Key guestbookKey = KeyFactory.createKey("Guestbook", guestbookName);
// Run an ancestor query to ensure we see the most up-to-date
// view of the Greetings belonging to the selected Guestbook.
Query query = new Query("Greeting", guestbookKey).addSort("date", Query.SortDirection.DESCENDING);
List<Entity> greetings = datastore.prepare(query).asList(FetchOptions.Builder.withLimit(5));
if (greetings.isEmpty()) {
%>
<p>Guestbook '${fn:escapeXml(guestbookName)}' has no messages.</p>
<%
} else {
%>
<p>Messages in Guestbook '${fn:escapeXml(guestbookName)}'.</p>
<%
for (Entity greeting : greetings) {
pageContext.setAttribute("greeting_content",
greeting.getProperty("content"));
if (greeting.getProperty("user") == null) {
%>
<p>An anonymous person wrote:</p>
<%
} else {
pageContext.setAttribute("greeting_user",
greeting.getProperty("user"));
%>
<p><b>${fn:escapeXml(greeting_user.nickname)}</b> wrote:</p>
<%
}
%>
<blockquote>${fn:escapeXml(greeting_content)}</blockquote>
<%
}
}
%>
<form action="/sign" method="post">
<div><textarea name="content" rows="3" cols="60"></textarea></div>
<div><input type="submit" value="Post Greeting" /></div>
<input type="hidden" name="guestbookName" value="${fn:escapeXml(guestbookName)}"/>
</form>
</body>
</html>
Warning! Whenever you display user-supplied text in HTML, you must escape the string using the fn:escapeXml JSTL function, or a similar escaping mechanism. If you do not correctly and consistently escape user-supplied data, the user could supply a malicious script as text input, causing harm to later visitors.
Retrieving the Stored Greetings
The low-level Java API provides a Query class for constructing queries and a PreparedQuery class for fetching and returning the entities that match the query from the Datastore. The code that fetches the data is here:
Query query = new Query("Greeting", guestbookKey).addSort("date", Query.SortDirection.DESCENDING);
List<Entity> greetings = datastore.prepare(query).asList(FetchOptions.Builder.withLimit(5));
This code creates a new query on the Greeting entity, and sets the guestbookKey as the required parent entity for all entities that will be returned. We also sort on the date property, returning the newest Greeting first.
After you construct the query, it is prepared and returned as a list of Entity objects. For a description of the Query and PreparedQuery interfaces, see the Datastore reference.
A Word About Datastore Indexes
Every query in the App Engine Datastore is computed from one or more indexes. Indexes are tables that map ordered property values to entity keys. This is how App Engine is able to serve results quickly regardless of the size of your application’s Datastore. Many queries can be computed from the builtin indexes, but the Datastore requires you to specify a custom index for some, more complex, queries. Without a custom index, the Datastore can’t execute the query efficiently.
Our guest book example above, which filters results by ancestor and orders by date, uses an ancestor query and a sort order. This query requires a custom index to be specified in your application’s datastore-indexes.xml file. When you run your application in the SDK, it will automatically add an entry to this file. When you upload your application, the custom index definition will be automatically uploaded, too. The entry for this query will look like:
<?xml version="1.0" encoding="utf-8"?> <datastore-indexes autoGenerate="true"> <datastore-index kind="Greeting" ancestor="true"> <property name="date" direction="desc" /> </datastore-index> </datastore-indexes>
You can read all about Datastore indexes on the Datastore Indexes page.
Clearing the Datastore
The development web server uses a local version of the Datastore for testing your application, using local files. The data persists as long as the temporary files exist, and the web server does not reset these files unless you ask it to do so.
The file is named local_db.bin, and it is created in your application’s WAR directory, in the WEB-INF/appengine-generated/ directory. To clear the Datastore, delete this file.
Using Static Files
There are many cases where you want to serve static files directly to the web browser. Images, CSS stylesheets, JavaScript code, movies and Flash animations are all typically served directly to the browser. For efficiency, App Engine serves static files from separate servers than those that invoke servlets.
By default, App Engine makes all files in the WAR available as static files except JSPs and files in WEB-INF/. Any request for a URL whose path matches a static file serves the file directly to the browser—even if the path also matches a servlet or filter mapping. You can configure which files App Engine treats as static files using the appengine-web.xml file.
Let’s spruce up our guest book’s appearance with a CSS stylesheet. For this example, we will not change the configuration for static files. See App Configuration for more information on configuring static files and resource files.
A Simple Stylesheet
In the directory war/, create a directory named stylesheets/. In this directory, create a file named main.css with the following contents:
body {
font-family: Verdana, Helvetica, sans-serif;
background-color: #FFFFCC;
}
Edit war/guestbook.jsp and insert the following lines just after the <html> line at the top:
<html>
<head>
<link type="text/css" rel="stylesheet" href="/stylesheets/main.css" />
</head>
<body>
...
</body>
</html>
Visit http://localhost:8888/. The new version uses the stylesheet.
Uploading Your Application
You create and manage applications in App Engine using the Administration Console.
Once you have registered an application ID for your application, you upload it to App Engine using either the Eclipse plugin, or a command-line tool in the SDK.
Note: Once you register an application ID, you can delete it, but you can’t re-register that same application ID after it has been deleted. You can skip these next steps if you don’t want to register an ID at this time.
Note : If you have an App Engine Premier account, you can specify that your new application should reside in the European Union rather than the United States. For developers that do not have a Premier account, you will need to enable billing for applications that should reside in the European Union.
Hosting applications in the European Union is especially useful if your users are closer to Europe than to the United States. There is less network latency and the End User Content will be stored at rest in the European Union. You must specify this location by clicking the “Edit” link in the “Location Options” section when you register the application; you cannot change it later.
Registering the Application
You create and manage App Engine web applications from the App Engine Administration Console, at the following URL:
Sign in to App Engine using your Google account. If you do not have a Google account, you can create a Google account with an email address and password.
To create a new application, click the “Create an Application” button. Follow the instructions to register an application ID, a name unique to this application.
Edit the appengine-web.xml file, then change the value of the <application> element to be your registered application ID.
For this tutorial, you should probably elect to use the free appspot.com domain name, and so the full URL for the application will be http://your_app_id.appspot.com/. You can also purchase a top-level domain name for your app, or use one that you have already registered.
For Authentication Options (Advanced), the default option, “Open to all Google Accounts users“, is the simplest choice for this tutorial. If you choose “Restricted to the following Google Apps domain”, then your domain administrator must add your new app as a service on that domain. If you choose the Google Apps domain authentication option, then failure to add your app to your Google Apps domain will result in an HTTP 500 where the stack trace shows the error “Unexpected exception from servlet: java.lang.IllegalArgumentException: The requested URL was not allowed: /guestbook.jsp”. If you see this error, add the app to your domain. See Configuring Google Apps to Authenticate on Appspot for instructions.
If you have an App Engine Premier account, you can specify that your new application should reside in the European Union rather than the United States. This is especially useful if your application’s users are closer to Europe than to the United States. There is less network latency and the End User Content will be stored at rest in the European Union. You must specify this location when you register the application; you cannot change it later. Click the Edit link in the Location Options section; select a location option, either United States or European Union.
Uploading the Application
You can upload your application using Eclipse, or using a command at the command prompt.
Currently, you can only upload applications with a maximum size of 32 megabytes.
Uploading From Eclipse
You can upload your application code and files from within Eclipse using the Google Plugin.
To upload your application from Eclipse, click on the Google button 
in the Eclipse toolbar, then select “Deploy to App Engine.”
If prompted, follow the instructions to provide the Application ID from the App Engine console that you would like to use for this app, your Google account username (your email address), and your password. Then click the Deploy button. Eclipse will then automatically upload the contents of the war/ directory.
Uploading Using the Command Prompt
You can upload your application code and files using a command included in the SDK named appcfg.cmd (Windows) or appcfg.sh (Mac OS X, Linux).
AppCfg is a multi-purpose tool for interacting with your app on App Engine. The command takes the name of an action, the path to your app’s war/ directory, and other options. To upload the app code and files to App Engine, you use the update action.
To upload the app, using Windows:
..appengine-java-sdkbinappcfg.cmd update war
To upload the app, using Mac OS X or Linux:
../appengine-java-sdk/bin/appcfg.sh update war
Enter your Google username and password at the prompts.
Checking Your Application State
After your application is uploaded, its Datastore Indexes will be automatically generated. This operation may take some time, and any visitors to your site will receive aDatastoreNeedIndexException until the indexes have been built. You can monitor the progress of the operation by visiting the App Engine console, selecting your application, and then selecting the Datastore Indexes link.
Accessing Your Application
You can now see your application running on App Engine. If you set up a free appspot.com domain name, the URL for your website begins with your application ID:
http://your_app_id.appspot.com/
Congratulations!
You have completed this tutorial. For more information on the subjects covered here, see the rest of the App Engine documentation.