Wednesday, November 10, 2010

Received IOException parsing the input stream for … web.xml

If you use Eclipse with the Google plugin to do development for App Engine, you might one day encounter the following error when you try to deploy your app:

  Received IOException parsing the input stream for …path/to/your/web.xml

This only happend when I updated my plugin recently, which is now:

  Google Plugin for Eclipse 3.5   1.4.0.v201010280047

The problem was the DTD in the header of the web.xml file, which was out of date. If you create a brand new Google Web Application Project, you can steal the proper header from that project.

Here’s what my web.xml header used to look like, causing deployment failure:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
    "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
  ...
</web-app>

 

And here’s what the new header looks like:

<?xml version="1.0" encoding="utf-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5">
  ...
</web-app>

Thursday, November 4, 2010

AppEngine / Google Checkout FAIL

 

I’m dying here…

appengine_googlecheckout_fail

From what I understand, Google Checkout will wait 10 seconds for a response from your callback URL.

But if your callback URL lives on App Engine, and if you are using the Google Checkout Java SDK – you’re in trouble. It will take longer than 10 seconds for your SDK to simply “warm up”.

I have tracked down the source of the problem, which I’ve blogged about earlier. It is a call to

   JAXBContext.newInstance(“com.google.checkout.sdk.domain”);

But I began wondering why this call takes *so* long on AppEngine, but only a couple seconds on my wimpy little desktop machine?

Just by examining the syntax of the above JAXB function call, one would suspect there is some Java reflection being employed to scan for all the classes present in the com.google.checkout.sdk.domain namespace. And doesn’t reflect come with some costs, like interacting with the Security Manager?  The GoogleCheckout Java SDK has 100 classes in that namespace, and I suspect Google’s JVM for AppEngine has it’s own Security Manager…   

I’m totally guessing here at a possible culprit, but I’m thinking it has to be something unique to the AppEngine environment since the same call on my wimpy dev machine is only a couple seconds vs. 20 +/- seconds on AppEngine.

I’ve already filed a bug report. I’m not sure what I am going to do next, but I have to act soon because the above errors are not going to stop. I’d really prefer to keep using the Google Checkout SDK, else I’d have to re-invent a bunch of code to deal with all the possible XML that can arrive at my callback URL – this seems a bad strategy for a system already in production – what could go wrong?! I could move that function to Rackspace, or somewhere else…  but then I’d really consider moving it all off AppEngine, and that would be too bad…

Well, something’s gotta give, and quickly.