I believe the issue I was having is because I'm not using the - noserver option as is explained in Google's FAQ. However, the odd thing is that I originally got my GWT Server Library / Spring integration working briefly under the built in Jetty instance. Not sure how this was possible but it worked briefly as I was able to set a breakpoint in the serverside "extends GWTSpringController" class using a Spring DispatcherServlet and the breakpoint was hit. Haven't been able to get it to work since then (that is 404 error on the nochache.js file since it stopped working) and the following FAQ as well as the GWT Server Library FAQ both say that the only way to go is to use the -noserver option and an external server such as Tomcat that supports -server.xml files etc.
http://code.google.com/webtoolkit/doc/1.6/FAQ_DebuggingAndCompiling.html This is a really big "ease of use" issue with respect to GWT. Folks are going to want to use facilities such as the -server.xml stuff. I'm going through the nightmare of using the -noserver option and its a real pain. I'm going to have to copy files manually to the tomcat instance, I will now have to run two programs from within Eclipse (one for client side debugging and another for server side debugging). In order to setup the second project I had to figure out how to manually update my .project files and .settings folder files to bring new natures and such into use. If the GWT developers want this tool to gain mass usage well beyond current usage these sorts of "ease of use" things need to be looked into futher. Can the built in instance be a Tomcat instance for instance? Or at least you could have the Eclipse plugin setup the .project and .settings files so that its ready to run the additional server side program for debugging serverside. Galileo comes with a Tomcat instance already so folks running Eclipse wouldn't have to worry about installing Tomcat. GWT is an awesome tool, I really get the whole facilitating 6 million Java developers to do web development thing and not rebuilding the wheel with respect to IDE's etc, and I have some nightmare JSF experience under my belt to compare it with. GWT really blows away any technology that requires the use of jsp's. I'm trying to sell GWT within my company but when folks that are new to the technology have to spend a bunch of time mucking around with xml files just to get basic debugging working it becomes a hard sell. I'll wait it out but I hope some of the issue above can be addressed within the next couple of years. By the way, here's what I needed to do to get the GWT Server Library portion working (setting aside the -noserver issues). 1) Inherit your RPC class from GWTSpringController instead of RemoteService 2) Add the following to web.xml <servlet> <servlet-name>gwtspringcontroller</servlet-name> <servlet-class> org.springframework.web.servlet.DispatcherServlet </servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping> <servlet-name>gwtspringcontroller</servlet-name> <url-pattern>/gwtserverlibtest2/*</url-pattern> </servlet-mapping> 3) Create the file gwtspringcontroller-server.xml (note that the file name begins with "gwtspringcontroller" which is the same name as the servlet above) and place it in the same directory as web.xml. 4) put the following contents into the gwtspringcontroller-server.xml file <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http:// www.springframework.org/dtd/spring-beans.dtd"> <beans> <bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> <property name="mappings"> <map> <entry key="/greet" value-ref="GreetingServiceImpl" /> </map> </property> </bean> <bean id="GreetingServiceImpl" class="com.pfizer.test.server.GreetingServiceImpl"/> </beans> 5) Additionally you'll need certain spring jar files as well as the gwt server library jar file gwt-sl-1.1.jar. I did find that I was missing a lot of libraries but the errors that showed up in the Eclipse console from Jetty were explicit as to the classes that were missing so it was not too difficult to find those jar files. Here is a list of jar files in my project (not that you'll need all of them). antlr-2.7.6.jar aopalliance-1.0.jar appengine-api-1.0-sdk-1.3.3.1.jar appengine-api-labs-1.3.3.1.jar appengine-jsr107cache-1.3.3.1.jar aspectjweaver-1.6.2.jar beanlib-5.0.2beta.jar beanlib-hibernate-5.0.2beta.jar cglib-nodep-2.1_3.jar commons-collections-3.2.jar commons-dbcp-1.2.2.jar commons-lang-2.2.jar commons-logging-1.1.1.jar commons-pool-1.4.jar csl-security.jar csl-util.jar datanucleus-appengine-1.0.6.final.jar datanucleus-core-1.1.5.jar datanucleus-jpa-1.1.5.jar dom4j-1.6.1.jar geronimo-jpa_3.0_spec-1.1.1.jar geronimo-jta_1.1_spec-1.1.1.jar gilead-core-1.3.0.1169.jar gilead-hibernate-1.3.0.1169.jar gilead4gwt-1.3.0.1169.jar gwt-servlet-2.0.0.jar gwt-servlet.jar gwt-sl-1.1.jar hibernate-3.3.2.jar hsqldb-1.8.0.jar javassist-3.4.GA.jar jboss-serialization-1.0.3GA.jar jdo2-api-2.3-eb.jar jsr107cache-1.1.jar jta-1.1.jar log4j-1.2.15.jar slf4j-api-1.5.10.jar slf4j-log4j12-1.5.10.jar spring-aop-3.0.0.jar spring-asm-3.0.0.jar spring-beans-3.0.0.jar spring-context-3.0.0.jar spring-core-3.0.0.jar spring-expression-3.0.0.jar spring-jdbc-3.0.0.jar spring-orm-3.0.0.jar spring-transaction-3.0.0.jar spring-web-3.0.0.jar spring-web-servlet-3.0.0.jar trove-2.0.4.jar xstream-1.3.jar -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
