Serialization policy missing in hosted mode when using Serializable

[GoogleCodeExporter]

"the serialization policy (*.gwt.rpc) file cannot be found
in hosted mode. I had to
copy it manually to target/tomcat/webapps/ROOT/<module-name>/*.gwt.rpc
to make it available.
It is needed when the classes used in RPC implement Serializable
instead of IsSerializable. "

Original issue reported on code.google.com by charlie....@gmail.com on 9 Sep 2008 at 4:50

[GoogleCodeExporter]

I can't reproduce this.  I don't think the shell needs the serialization 
policy, the
shell works straight from code, not from anything the compiler outputs 
(including the
ser pol file). 

Original comment by charlie....@gmail.com on 14 Sep 2008 at 6:44

• Changed state: Invalid

[GoogleCodeExporter]

Re-open, see this thread
http://groups.google.com/group/gwt-maven/browse_thread/thread/19504fe37e46cc8d. 
Still a reported issue. 

Original comment by charlie....@gmail.com on 15 Sep 2008 at 12:12

[GoogleCodeExporter]

Original comment by charlie....@gmail.com on 15 Sep 2008 at 12:12

• Changed state: Accepted

[GoogleCodeExporter]

I checked into this more and here is the deal, if you replace the 
GWTShellServlet,
you are on your own. ;)

The GWTShellServlet "knows" to get the rpc policy for the shell from 
.gwt-tmp/shell.
When you replace this with Spring, you are subverting this, and you need to get 
the
rpc stuff there yourself somehow.  Sorry, but specialized Spring setups where 
the
shell servlet is replaced are not really the problem domain of GWT-Maven. 

Original comment by charlie....@gmail.com on 16 Sep 2008 at 1:11

• Changed state: Invalid

[GoogleCodeExporter]

Also, it looks like a few people have asked about this in the GWT-SL groups, 
seems
like a GWT-SL issue to me (the response there is probably going to be don't use 
the
shell, but, they are the ones directing out of the shell servlet). 

Original comment by charlie....@gmail.com on 16 Sep 2008 at 1:14

[GoogleCodeExporter]

charlie,

i would like to add to this thread, if possible.
i too see RPC serialization problems in hosted mode, but I think I've figured 
out
why. I do have a source web.xml file (/src/main/webapp/WEB-INF/web.xml) in 
which I
configure up my servlets (the GWT servlets specifically). When I do a "mvn 
package"
everything builds properly and I can deploy to an external tomcat as expected. 
But
when I do a "mvn gwt:gwt" the hosted-mode shell throws the serialization 
exceptions
as above. When I look at the web.xml that is generated by gwt-maven for the
hosted-mode tomcat, I see that it adds the GWTShellServlet and maps it to /*. 
That
means the GWTSHellServlet AND the servlets I had originally specified that map 
to my
GWT RPC servlets are both in the hosted-mode web.xml. When I run hosted mode, 
it must
be trying to use the servlets that I defined (and not the GWTShellServlet) to
complete RPC requests... and it fails on the RPC serialization because the 
*.gwt.rpc
files are not available.

My question: Is there a way to tell hosted mode NOT to use my source web.xml 
file
(and just use a plain basic one)? If I change the <webXml> tag in the gwt-maven
plugin, it changes it for building the WAR too, and I can't have that.

If I take out my servlet declarations from my source web.xml and use the 
mergewebxml
goal to merge, everything works fine (hosted and build-time). However, I must 
have
the source web.xml contain ALL information related to mapping servlets and 
cannot
rely exclusively on the mergewebxml goal to put that together.

Please help!
Thanks!
Christian

Original comment by christia...@gmail.com on 30 Nov 2008 at 4:04

[GoogleCodeExporter]

Don't define your RPC servlets in your source web.xml.  Anything that is an RPC
servlet will still be there when you do package, based on what's defined in the
module XML file, but if you have specific entries that point to some other path 
that
could confuse the shell servlet, yes. 

There is no way to tell GWT-Maven you have a web.xml for some goals, and don't 
one
for others, no.  

Original comment by charlie....@gmail.com on 30 Nov 2008 at 8:42