RPC calls no longer working in GWT 1.4 RC1

[Dave]

We have been using GWT 1.2 and 1.3 for quite some time and our RPC
calls have been working in production and in hosted mode. Our RPC
calls are implmented using servlets + EJB + hibernate so we always
have a local Weblogic server running in hosted and web mode test.

Now that we have moved to GWT 1.4 RC1 as an experiment our RPC calls
no longer work. Basically the first RPC call issued by the app never
seems to return. This is both in hosted mode and web mode on our
Weblogic server.

Here is how we have declared our RPC stuff.

In our GWT module we declare the RPC call
<servlet path="/gwt.module.name/securityService"
class="xxx.yyy.server.SecurityServiceServletImpl"/>

In our web.xml file we have
<servlet-mapping>
<servlet-name>SecurityService</servlet-name>
<url-pattern>/gwt.module.name/securityService</url-pattern>
</servlet-mapping>

In the code that looks up our RPC endpoint we have

private static final String BASE_RPC_URL = "http://localhost/webapp/
gwt.module.name";

public static SecurityRPCServiceAsync getSecurityServiceProxy() {

// create Async from non-Async, just in case of there's a need
to
SecurityRPCServiceAsync securityServiceProxy =
(SecurityRPCServiceAsync) GWT
.create(SecurityRPCService.class);
ServiceDefTarget endpoint = (ServiceDefTarget)
securityServiceProxy;
setEndpointURL(endpoint,"/securityService");
return securityServiceProxy;
}

private static void setEndpointURL(ServiceDefTarget endpoint, String
urlSuffix) {
String url = GWT.getModuleBaseURL() + urlSuffix;

if (!GWT.isScript()) {
url = BASE_RPC_URL + urlSuffix;;
}

endpoint.setServiceEntryPoint(url);
}

It looks like the correct URL for the servlet is being declared and
using Tamper Headers in Firefox I can see the Async request is issued,
but it seems to never return.

There are no errors listed in hosted mode and breakpoints on the
server side code never seem to be invoked.

Is anyone else having similar issues?

Dave

[Dave]

Using the Fiddler plug-in for IE I get the following in the RPC
response

HTTP/1.1 200 OK
Date: Fri, 01 Jun 2007 16:24:56 GMT
Content-Length: 350
Content-Type: text/plain; charset=utf-8

//EX[0,4,0,3,0,0,2,1,
["com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException/
3936916533",
"java.lang.ClassNotFoundException/4030839331",
"xxx.yyy.client.security.SecurityRPCService",
"Could\x20not\x20locate\x20requested\x20interface\x20'
xxx.yyy.client.security.SecurityRPCService'\x20in\x20default
\x20classloader"],0,2]

So it seems that the server side RPC routing mechanism is having
trouble finding my RPC service interface in the web app.

[Dave]

The compiled classes for the interface are in WEB-INF/classes for the
web app.
The compiled value object classes used by the RPC interface and the
EJB tier are in a JAR file in APP-INF/lib

Dave

[greensunie]

Same exact problem here. No changes to our back end servlet (other
than re-compiling with new GWT servlet JAR).

Google's got a blurb about it in the APIs:

This exception can be caused by the following problems:

The requested RemoteService cannot be located via
Class.forName(String) on the server.
The requested RemoteService interface is not implemented by the
RemoteServiceServlet instance which is configured to process the
request.
The requested service method is not defined or inherited by the
requested RemoteService interface.
One of the types used in the RemoteService method invocation has had
fields added or removed.
The client code receives a type from the server which it cannot
deserialize.

But for an app that has no changes.... what gives? Why would any of
those factors suddenly come into play? I didn't see anything
mentioned in the release notes about necessary changes to the server
side servlet.

I must have undeployed, cleaned, re-built this thing three times.
Nowhere would there a cached copy of any of these JARs.

[Miguel Méndez]

Hi Guys,

It seems like there are a couple of issues here so I need to ask some questions. 

Where is your gwt-servlet.jar installed? 

I ask because, in 1.4, we extracted the RPC encoding and decoding logic from RemoteServiceServlet into a separate class.  In doing so, we changed the classloader used to resolve the types used in RPC.  This is a regression.  As a test, could you move your gwt-servlet.jar into the same classloader as your application code?  This should make the code work.

I created Issue 1138 to track this problem.

Was the AsyncCallback.onFailure method ever called? 

Doesn't sound like it was but I would like to confirm.  I suspect that this happened because the version of Throwable in our JRE emulation library does not implement Serializable but the real one does.  This can cause problems because the deserialization done by the client will differ from that done by the server.

I created issue 1139 to track this.

Thanks for commenting on these problems.

Cheers,

--
Miguel

[Brill]

I had the same issue, make sure your deployed webapp is also compiled
and installed with the new 1.4 libraries.
Mine would not work properly until I updated everything.

It is possible that there was some other issue, but thats what fixed
it for me.

- Brill Pappin

On Jun 1, 12:18 pm, Dave <b...@widomaker.com> wrote:
> We have been using GWT 1.2 and 1.3 for quite some time and our RPC
> calls have been working in production and in hosted mode. Our RPC
> calls are implmented using servlets + EJB + hibernate so we always
> have a local Weblogic server running in hosted and web mode test.
>
> Now that we have moved to GWT 1.4 RC1 as an experiment our RPC calls
> no longer work. Basically the first RPC call issued by the app never
> seems to return. This is both in hosted mode and web mode on our
> Weblogic server.

ve

[Dave]

This change represents a significant problem for us. Currently in our
application we have gwt-servlet.jar in our APP-INF/lib directory of
our EAR file. This directory is recognized by Weblogic 8.1 as being on
the classpath for all EJB and WAR modules in the EAR. Our business
logic for our application is a mix of EJB code in the form of
Stateless Session Beans with calls to the backend DB implemented using
Hibernate. Our RPC servlet layer just delegates the calls to the EJB
tier. This gives us transaction and security support for our business
logic.

In our application we have a set of value objects that implement
IsSerializable that are shared by our GWT client codebase and by the
EJB tier code. For our EJB tier to compile and go through all of the
packaging process we are required to have gwt-servlet.jar on the
classpath because the EJB tier code depends on the value objects. We
cannot move the gwt-servlet.jar file to WEB-INF/lib to get it on the
web application classloader. Trying to place the JAR file in both
locations does not work either. In general we have been able to place
JAR files at the APP-INF/lib directory and have it work. Is your
custom classloader taking into account that it might be part of a
hierarchy of classloaders?

This represents a critical issue for us, since we have a significant
amount of code that is currently running in production on GWT 1.2 and
have no mechanism to migrate to GWT 1.4

Any suggestions?

Dave

[John]

I'm facing the same issue and haven't worked out the solution yet. The
service is called and runs but it always throws an exception
(InvocationException) on return. The return data all look exactly as
they should.

I have the new gwt-servlet.jar in C:\Program Files\Apache Software
Foundation\Tomcat 5.5\common\lib as well as in \WEB-INF\classes\lib
for my application. Is that what you mean by putting it in the same
classloader?

Thanks for the help! -- John

On Jun 1, 8:05 pm, "Miguel Méndez" <mmen...@google.com> wrote:
> Hi Guys,
>
> It seems like there are a couple of issues here so I need to ask some
> questions.
>
> Where is your gwt-servlet.jar installed?
>
> I ask because, in 1.4, we extracted the RPC encoding and decoding logic from
> RemoteServiceServlet into a separate class. In doing so, we changed the
> classloader used to resolve the types used in RPC. This is a regression.
> As a test, could you move your gwt-servlet.jar into the same classloader as
> your application code? This should make the code work.
>
> I created Issue

> 1138<http://code.google.com/p/google-web-toolkit/issues/detail?id=1138>to

> track this problem.
>
> Was the AsyncCallback.onFailure method ever called?
>
> Doesn't sound like it was but I would like to confirm. I suspect that this
> happened because the version of Throwable in our JRE emulation library does
> not implement Serializable but the real one does. This can cause problems
> because the deserialization done by the client will differ from that done by
> the server.
>
> I created issue

> 1139<http://code.google.com/p/google-web-toolkit/issues/detail?id=1139>to

> track this.
>
> Thanks for commenting on these problems.
>
> Cheers,
>

[Miguel Méndez]

This is just a work around until we ship the next RC.

I'm not sure if having it in both places would cause a problem.  Just make sure that gwt-servlet.jar is in the sample directory on the server as your application classes/jar file.  This will ensure that the class loader which loads the RPC class will also load your user code and thereby work around this problem until we fix it.