Just a quick summary, the servlet spec requires that a servlet container such as appengine provider an implementation for a service. Those jars such as servlet- api-2.4.jar are needed at compile time. They are sometimes provided by the servlet container/ engines at run time in a global directory that is found by the container/engine classloader. appengine provides the servlet, jsp implementations for us at runtime.
The appengine specific service implementations are also needed at runtime and compile time and are present in the appengine-api-1.0-sdk-<ver>.jar. They've chosen not to add the latest sdk to the container global classpath, so yes, the application must provide it. That may be an assumption that all builds are not required to be backwards compatible. Note that the application loader is now checking for the sdk version before upload too, so there's a rough check for compatibility in place. I think I had one app that was using 1.3.8 and was no longer able to deploy it with version 1.4.3. On May 12, 2:56 pm, Toby Reyelts <to...@google.com> wrote: > arjan, > > There are two sides to the App Engine API: the client and the server. The > client side (appengine-api.jar) lives entirely in "user-land". If you so > chose, you could create your own version of these classes. In the end, the > client ends up talking to the server through a binary protocol in order to > fulfill much of the API. > > Having this separation means that you can evolve the client and server > independently. For example, dev_appserver and prod obviously have two > different server backends for the same client API. You can take that one > step further and even independently implement your own server if you so > chose. It also means that its trivial to do things like test out and even > deploy hotfixes for individual applications instead of waiting for full > releases. > > > > On Thu, May 12, 2011 at 4:31 PM, arjan tijms <arjan.ti...@gmail.com> wrote: > > Hi ya! > > > On May 12, 1:05 am, Didier Durand <durand.did...@gmail.com> wrote: > > > 1 of the reasons is that all applications don't run all at the same > > > version on the gae productive infrastructure. So, google would have to > > > know which one you are using in order to put it for you in your war > > > when you upload it. > > > Hmmm, there are two possible problems with that explanation: > > > 1. Aren't the GAE jars in the war the ones for local simulation and > > not the actual ones used by the live GAE production servers? > > 2. Why would Google need to put them into the war when we upload it? > > Tomcat doesn't add the servlet-api jars to my war when I deploy it to > > Tomcat, JBoss AS doesn't add the EJB, JPA, etc etc jars to a war being > > deployed to it, Resin also doesn't do this. In fact, I've never > > encountered any Java server that required jars for functionality that > > the server provided to be put into the war. WEB-INF/lib is for extra > > functionality that the server -does not- provide. > > > If they just use it for detecting the version for which you developed > > your app, then why not just put that version number in appengine- > > web.xml? > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine for Java" group. > > To post to this group, send email to > > google-appengine-java@googlegroups.com. > > To unsubscribe from this group, send email to > > google-appengine-java+unsubscr...@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/google-appengine-java?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
