Posts Tagged ‘google app engine’

Problems uploading a new GAE app

May 29, 2015

I was working on a new project – I haven’t done a Google App Engine project in a while.  So I get it working… it finally passed all of my local integration testing.  Now I was ready to upload into GAE (1.9.19 at the time of this writing).

So, first, I made sure I’d created the application in the GAE project console.

then, from Eclipse (Kepler SR2), since I use Maven all the time:

mvn appengine:update

Hmmm:

"Either the access code is invalid or the OAuth token is revoked.Details: invalid_grant"

So it is using Oauth2 to authorize the upload, except it looks like my details are out of date. No amount of logging in or out of Eclipse fixed it.

Finally, I found a post out on the GAE Issues site that said to delete the .appcfg_oauth2_tokens_java file.  After a bit of digging, I had to delete the .appcfg_oauth2_tokens_java in the c:\Users\MyUser folder.

Then I re-run my maven command:

[INFO] Running --oauth2 update C:\Users\...-0.0.1-SNAPSHOT

A which point my default browser is popped up, I have to agree to some things, I do and then am presented with a simple page with a code to copy and past “into my application”.

Which application?
My GAE application?
What in the world?

I happen to flip back to Eclipse and see the console:

Please enter code:

Can I even type into that console? I think I can…

So I do, and hit <enter>

Magically, it starts working…

Integration Testing, Maven, and GAE

September 8, 2013

I’m starting to use REST-assured for integration testing my REST APIs.  It provides a nice clean way of writing integration tests and, of course, I’d like them to be run automatically.

Maven Integration Tests

While unit testing is pretty much ready to go out of the box in Maven, integration testing isn’t.  It is not too hard but there’s a couple of things that need to be done. First, you have to pull Fail Safe into Maven with:
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-failsafe-plugin</artifactId>
  <version>${maven.failsafe.version}</version>
  <executions>
    <execution>
      <goals>
        <goal>integration-test</goal>
        <goal>verify</goal>
      </goals>
    </execution>
  </executions>
</plugin>
Now, when you execute the maven verify goal, test classes of the pattern IT*.java or *IT.java are automatically executed. This works well until you realize that real integration tests require a bit more setup than unit tests do.
 

GAE Dev Server and Integration Testing

In particular, I want the GAE dev server running before the integration tests run.  So all we should have to do is get the GAE plug-in to execute the devserver_start goal during pre-integration-test and the devserver_stop goal to execute during post-integration-test.
<plugin>
  <groupId>com.google.appengine</groupId>
  <artifactId>appengine-maven-plugin</artifactId>
  <version>${appengine.target.version}</version>
  <executions>
    <execution>
      <id>start-gae</id>
      <phase>pre-integration-test</phase>
      <goals>
        <goal>devserver_start</goal>
      </goals>
    </execution>
    <execution>
      <id>stop-gae</id>
      <phase>post-integration-test</phase>
      <goals>
        <goal>devserver_stop</goal>
      </goals>
    </execution>
  </executions>
</plugin>
Now, executing mvn verify will run your integration tests once your unit tests pass and the GAE dev server should start and stop around the integration tests as well.

Adding Jersey to a GAE Maven Project

September 3, 2013

Continuing from my post yesterday, Getting Maven, GAE, and Eclipse Working Together, I’m adding Jersey to my test GAE project to finish proving the Maven integration and test that I can get my favorite REST library up and running both locally and as a full fledged GAE project.

Adding Jersey

Jersey is one of the few “magical” (read: annotation) libraries I use.  I really don’t like magic in my code.  It is great when it works, and miserable when it fails… and it always fails at inopportune moments…

We start by adding a new dependency to the pom file:

<dependency>
    <groupId>org.glassfish.jersey.containers</groupId>
    <!-- if your container implements Servlet API older than 3.0, use "jersey-container-servlet-core" -->
    <artifactId>jersey-container-servlet-core</artifactId>
    <version>2.2</version>
</dependency>

The artifactId started out as “jersey-container-servlet” but since GAE only supports the Servlet 2.5 spec we follow the comment and append “-core”.

Next, we quickly write a test Jersey class:

package mavengaetestproject.mavengaetestproject;

import javax.ws.rs.GET;
import javax.ws.rs.Path;

@Path("/jerseyws")
public class TestJerseyWS {

    @GET
    @Path("/test")
    public String testMethod() {
        return "this is a test";
    }
}

And then update the web.xml:

<servlet>
    <servlet-name>Jersey Web Application</servlet-name>
    <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
    <init-param>
        <param-name>jersey.config.server.provider.packages</param-name>
        <param-value>mavengaetestproject.mavengaetestproject</param-value>
    </init-param>
    <init-param>
        <!-- speed up initial Jersey loading by deactivating WADL -->
        <param-name>jersey.config.server.wadl.disableWadl</param-name>
        <param-value>true</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>Jersey Web Application</servlet-name>
    <url-pattern>/context/*</url-pattern>
</servlet-mapping>

Finally, run the appengine:devserver maven target, and once the server is up and running open a browser to http://localhost:8080/context/jerseyws/test ; You should see the “this is a test” message.

And there we have it: Maven, Eclipse, GAE and Jersey all working nicely together.

Deploying to the GAE

That’s all well and good, but I want this thing actually in the cloud, not on a dev server.  It may seem obvious, but I failed to do this first: you need to create your project in your GAE account.  You might need to update the application tag in the webapp/WEB-INF/appengine-web.xml to match the GAE application identifier.

At this point you should be able to run the Maven appengine:update target.  If working from inside Eclipse, it is probably easier to log into Google beforehand, AND you WILL need to configure the Eclipse Run As configuration for UpdateApplication to use the external Maven environment (see the other post if you need a refresher on why).  If running Maven from a command line, it will pop open your default web browser, prompt you to log in, and then provide a code to put back into your console/shell to allow it to continue.  For me, it worked cleanly from both environments (once I had the Maven config corrected in Eclipse) and my REST servlet was up and running easily.

At this point I’ve completed everything I intended to accomplish.  It took a little longer than planned and with the mish-mash of tech that didn’t always line up correctly I hope this helps others out.

Getting Maven, GAE, and Eclipse Working Together

September 3, 2013

Today, we turn to some “fun” making Maven, Google App Engine, and Eclipse work together nicely.  I like Eclipse I lot.  I know its not everyone’s favorite, but it is my choice of IDE.  Similarly, I know Maven isn’t everyones… ok, its no one’s favorite, but it does solve a number of problems quite well and I peacefully co-exist with it right now.  Maven and Eclipse are enough to make people complain loudly to me at work, but today I wanted to build a GAE project, in Eclipse, and using Maven to manage my dependencies (I’m going to have a number on this little project of mine and its good for what I need).

Google certainly has a nice Eclipse plugin for managing GWT and GAE projects, but it doesn’t conform to Maven conventions.  After trying several times to coerce a GAE project into a Maven structure I gave up and did some searching.  I found https://developers.google.com/appengine/docs/java/tools/maven to be generally useful but it required some modifications for the current versions of things.  Here is what I had to do to get everything working together:

Steps

Starting Environment

  • Eclipse Java EE IDE for Web Developers, Version: Kepler Release, Build id: 20130614-0229
  • Maven 3.1.0 installed outside of Eclipse (in my devtools folder if it matters)
  • JDK 1.7.0_25
  • Windows 7

Target Implementation

A basic REST servlet using:

  • GAE 1.8.3
  • Jersey 2.2
  • Final WAR deployed into my GAE account

Step 1: Add the External Maven to Eclipse

I didn’t realize it was going to be important to have an external Maven installation but it turns out that it is (reasons later).  In the Eclipse Preferences, search for Maven, and look for the Installations tree node.  Add a new installation by browsing for your devtools equivalent location.  Once added, make sure the checkbox is on the External one.  You may also need to update where your settings.xml is pointing both here in the Installations, and/or in the User Settings.  I have both pointing at the settings.xml in the external maven configuration folder.

Step 2: Update Eclipse Maven with Remote Archetype catalog

In that same Maven area above, look for the Archetypes tree node.  Add a remote catalog providing http://repo1.maven.org/maven2/archetype-catalog.xml in the catalog file box (name it if you want, I didn’t).

Step 3: Create the project stub

Using the Eclipse project wizard create a new Maven Project.  The second step in the wizard selects an archetype, look for com.google.appengine.archetypes:skeleton-archetype.  Select your group and artifact ids (I choose “mavengaetestproject” for both) and it will create a nice stub GAE project. Note that the artifact id becomes the Eclipse project name. That annoys me because my Eclipse project names don’t always match my maven artifact names, but considering what we’re trying to accomplish, I’ll let this one slide.  If I’ve missed where I can name the project, please let me know.

Step 4: Fix up the default pom.xml

The default pom is set up for GAE version 1.7.5 so change the appengine.target.version property to 1.8.3 to pull in the latest GAE environment.

Step 5: Test out the basic war

One of the nice things about the skeleton-archetype is that it comes with appengine-maven-plugin already set up.  That gives us some maven goals that help make up for the lack of the GAE Eclipse plugin.

Right clicking on the project node, Run As, Maven Build…, set the goal to be appengine:devserver and then run it.

Boom!

As of the time of this writing there’s a problem:

[ERROR] Failed to execute goal com.google.appengine:appengine-maven-plugin:1.8.3:devserver (default-cli) on project mavengaetestproject: The plugin com.google.appengine:appengine-maven-plugin:1.8.3 requires Maven version 3.1.0 -> [Help 1]

Eclipse Kepler is running Maven 3.0.4 internally, and in one of those warning messages I never read on the Maven Installations configuration dialog it says “Note: Embedded runtime always used for dependency resolution…”.  Basically, by default, any Run As, Maven command is using Eclipse’s embedded Maven configuration.

This can be fixed by going into the Run As, Run Configurations… dialog and searching for DevAppServer, click on it. At the bottom there is a Maven Runtime combobox, select the external Maven entry.  Apply and then run.  This time it should work better.

Open a browser to http://localhost:8080/_ah/admin to prove that its working.

One annoying side effect: killing the process inside the Eclipse console doesn’t seem to kill the real process so I have to manually kill it when I’m done testing.  Any suggestions on this would be welcome.

Conclusions

At this point we have a working GAE project that does nothing.  But, it is Maven-ized and working in Eclipse.  In the next post, I’ll pull Jersey in and make sure Maven and Jersey and everything are all working correctly.