Community
Participate
Working Groups
It appears that App Engine has a problem with JARs that are signed by Eclipse, as attempts to use the EMF runtime JARs for GWT on App Engine (e.g., if you try to press the 'Save' button in the generated sample editor) result in exceptions similar to the following: 01-18 01:58PM 12.976 EXCEPTION java.lang.SecurityException: SHA1 digest error for org/eclipse/emf/server/ecore/resource/URIServiceImpl.class at com.google.appengine.runtime.Request.process-9b2456d7578c6a02(Request.java) at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:210) at java.util.jar.JarVerifier.processEntry(JarVerifier.java:218) at java.util.jar.JarVerifier.update(JarVerifier.java:205) at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:428) at sun.misc.Resource.getBytes(Resource.java:114) at java.net.URLClassLoader.defineClass(URLClassLoader.java:273) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at java.lang.ClassLoader.loadClass(ClassLoader.java:268) at org.mortbay.util.Loader.loadClass(Loader.java:91) at org.mortbay.util.Loader.loadClass(Loader.java:71) at org.mortbay.jetty.servlet.Holder.doStart(Holder.java:73) at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:242) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24) at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:435) at com.google.net.rpc.impl.Server$RpcTask.runInContext(Server.java:572) at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:448) at com.google.tracing.TraceContext.runInContext(TraceContext.java:688) at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:326) at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:318) at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:446) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) E 01-18 01:58PM 12.976 javax.servlet.ServletContext log: unavailable javax.servlet.UnavailableException: SHA1 digest error for org/eclipse/emf/server/ecore/resource/URIServiceImpl.class at org.mortbay.jetty.servlet.Holder.doStart(Holder.java:79) at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:242) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:685) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.createHandler(AppVersionHandlerMap.java:191) at com.google.apphosting.runtime.jetty.AppVersionHandlerMap.getHandler(AppVersionHandlerMap.java:168) at com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:123) at com.google.apphosting.runtime.JavaRuntime.handleRequest(JavaRuntime.java:261) at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:8495) at com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:8493) at com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24) at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:435) at com.google.net.rpc.impl.Server$RpcTask.runInContext(Server.java:572) at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:448) at com.google.tracing.TraceContext.runInContext(TraceContext.java:688) at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:326) at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:318) at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:446) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) The editor works fine, however, when deployed with the EMF GWT runtime projects checked out into the workspace.
Michal, is it possible to disable signing for just the GWT bundles? Would it be possible for us to try a build with signing disabled to see if that addresses the problem?
The eclipse signer (and buckminster) will honor the options described here: http://wiki.eclipse.org/JarProcessor_Options so this should just be a matter of adding an eclipse.inf file. It would be interesting to know why the check fails though. Is the file incorrectly signed somehow (in which case it should be addressed by the Eclipse signer)? Or is this a bug in GAE (should be reported to Google)?
Disabling signing for the GWT JARs as per Thomas' comment did indeed eliminate the problem. I'm not sure who's at "fault" here. I did a Google search for this kind of problem in the GWT / App Engine context, but came up empty. We can follow up with the GWT developer forum (Ed, could you do that?), but I'm not going to hold my breath for a response. In the meantime, we can keep the signing disabled so that at least we can successfully deploy.
There is a downside to not having EMF GWT bundles signed. Considering projects which use of both org.eclipse.emf.common org.eclipse.emf.gwt.common, will cause certain packages to contribute both signed and unsigned classes to the CP, triggering java.lang.SecurityExceptions similar to this: java.lang.SecurityException: class "org.eclipse.emf.common.util.InvocationTargetException"'s signer information does not match signer information of other classes in the same package The exact context in which I was hit by this is a bit involved, but I can imagine it occurring in various situations, for example, if direct use of EMF is taking place on the server side along with EMF-GWT use on the client side, or during development, as result of GWT's tendency to look beyond the web-app CP into the system CP when missing certain classpath entries. Overall I'd rather see all EMF bundles uniformly signed as opposed to this, which would surprise most people IMO. Regardless, the root cause for the SHA1 digest error should be investigated.
I'm resolving all old releng bugs because the build has been replaced with a Tycho build: https://bugs.eclipse.org/bugs/show_bug.cgi?id=529487 And the update site has been superseded by: http://download.eclipse.org/modeling/emf/emf/builds/ If there are outstanding issues, please report a new bug based on the new build infrastructure and the new update site.
