Unable to find 'MyProject/html.gwt.xml' on your classpath; could be a typo, or maybe you forgot....

[Suresh P]

Hi All,
I am new to GWT. While deploying the application i am getting
this error. Can anybody put in ur ideas for solving it??

Thanks in Advance...

11:51:46,908 INFO [Engine] StandardContext[/MyProject]Request 0:
http://localhost:8080/MyProject/MyProject.html/
11:51:46,908 INFO [Engine] StandardContext[/MyProject]The development
shell servlet received a request to generate a host page for module
'MyProject.html'
11:51:46,908 INFO [Engine] StandardContext[/MyProject]Loading module
'MyProject.html'
11:51:47,595 INFO [Engine] StandardContext[/MyProject]Unable to find
'MyProject/html.gwt.xml' on your classpath; could be a typo, or maybe
you forgot to include a classpath entry for source?

Some Clarifications:
1. Why are we packaging the generated js, html files into a web
archive manually? Dont we have any tool that can do it wihout our
intervention?

Regards
Suresh P

[Ian Bambury]

I'd guess that you have an error in the PROGRAM_ARGUMENTS line in your launch file.

 

After the -out www bit you need to have the package name to the module (*.gwt.xml) file seperated by dots, then a dot and the module file name (without the .gwt.xml extension) then a slash, then the html file. For example, -out www com.foo.bar.Module/index.htm if our module file is Module.gwt.xml .

 

Ian

 

 

 

 

--------------------------------------------

[Suresh P]

Hi,
But could not make out from ur reply. Can you elaborate a little on
this??
Where do I find the "MyProject/html.gwt.xml" in the compiled
directory... Can a file be created with special characters like "/"...
I hope Windows would not allow us to do...

Hopin for a reply..
Suresh P

On Nov 16, 12:25 pm, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> I'd guess that you have an error in the PROGRAM_ARGUMENTS line in your
> launch file.
>
> After the -out www bit you need to have the package name to the module
> (*.gwt.xml) file seperated by dots, then a dot and the module file name
> (without the .gwt.xml extension) then a slash, then the html file. For
> example, -out www com.foo.bar.Module/index.htm if our module file is
> Module.gwt.xml.
>
> Ian
>

> On 16/11/2007, Suresh P <sureshpoo...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Hi All,
> > I am new to GWT. While deploying the application i am getting
> > this error. Can anybody put in ur ideas for solving it??
>
> > Thanks in Advance...
>
> > 11:51:46,908 INFO [Engine] StandardContext[/MyProject]Request 0:
> >http://localhost:8080/MyProject/MyProject.html/
> > 11:51:46,908 INFO [Engine] StandardContext[/MyProject]The development
> > shell servlet received a request to generate a host page for module
> > 'MyProject.html'
> > 11:51:46,908 INFO [Engine] StandardContext[/MyProject]Loading module
> > 'MyProject.html'
> > 11:51:47,595 INFO [Engine] StandardContext[/MyProject]Unable to find
> > 'MyProject/html.gwt.xml' on your classpath; could be a typo, or maybe
> > you forgot to include a classpath entry for source?
>
> > Some Clarifications:
> > 1. Why are we packaging the generated js, html files into a web
> > archive manually? Dont we have any tool that can do it wihout our
> > intervention?
>
> > Regards
> > Suresh P
>
> --
>

> Ian
> --------------------------------------------http://examples.roughian.com
> --------------------------------------------- Hide quoted text -
>
> - Show quoted text -

[Ian Bambury]

Hi Suresh,

 

Look at the last few lines of of the MyProject.launch file for the text -out www com.foo.bar.Module/index.htm. It should be in that format (and will be if you have used the project and application creators).

 

If you haven't messed about with any filenames yourself, then I'd suggest that you create a new project, make sure it works as the Hello World default code, and then cut and paste your own GWT code/classes from your current project to the new one.

 

But if you want to zip it up and sent it to me personally, I'll have a look.

 

--


Ian
--------------------------------------------
http://examples.roughian.com
--------------------------------------------

[Suresh P]

Hi Ian,
Thanks a lot.
The arguments found is:
-out www com.sabre.MyProject/MyProject.html. I hope this what you said
and it is like that...

I ll explain in more what I did..
I wanted GWT stuff to be deployed as a WEB archive.
I read this link : http://www-128.ibm.com/developerworks/opensource/library/os-ad-gwt4/
and almost did the same...
Then I got some problems, This I rectified by removing the javax.*
packaged classes from the WEB archive. I donno why they put all the
javax.* classes in the gwt-*.jars.
After this I got the unable to find the module.xml file...

I am terribly in need to know what happens behind the scenes..
If possible help me on this. It would be grt...

I created a new one and tried deploying it.. Again I got the same
problem..
I am sending u the web archive... Please hav a look at it and let me
know the cause...

Thanks a lot Ian..

[Will]

Hi Suresh,

1) gwt-dev-*.jar is only for using GWTCompiler (Java->JS translation)
and GWTShell (Hosted Mode). Don't include this jar in your web
archive.
2) gwt-user.jar is only used during development and contains the GWT
API. Don't include this jar in your web archive either.
3) gwt-servlet.jar should be the only JAR you need to include with the
WAR, and only if you use RPC.

Regards,
Will

[Eric Ayers]

The following is a preview of a section in the upcoming GWT 1.5 Developer's Guide.  Does this help any? (do you see any problems?)

Deploying RPC

The GWT supplied servlet container is intended only for debugging your application. Once you have written and debugged your application, it is time to deploy to a production server. When you do so, you will need to select a servlet container (also called a web container or web engine) to run the backend. GWT does not provide a servlet container to use in production, but there are many different products available. The following lists just a few commercial and non-commerical offerings:

• Apache Tomcat
• Jetty
• JBoss
• IBM Web Sphere
• Oracle Application Server

In fact, you can choose any  server you like in hosted mode as well. After setting up your server, start up hosted mode with the -noserver option to disable GWT's builtin servlet container.

In the examples below, we use Apache HTTPD and Apache Tomcat as a web engine. Although there are many different implementations of web servers and servlet containers,  Servlet API Specifications define a standard for structuring your project directories so these instructions should apply if you are using another web engine.

Simple Example with Apache Tomcat

The simplest way to deploy your application is to use a single server for both your static content and your servlet classes. These steps assume that you created your project with  applicationCreator:

1. Compile : Compile your code using the <module> -compile file created by applicationCreator. If the compile is sucessful, the compiler output will be placed in a folder called  www/<package>.<modulename>.
2. Create a staging area : Create a temporary folder to stage your files to. In this example, we will call the folder production.
3. Copy compiled files to the staging area : Copy the content files from www/<package>.<modulename> to the production staging area folder. You should now have files named *.nocache.js , *.cache.js, *.cache.xml, *.cache.html and others in the `production staging area folder.
4. Create WEB-INF subdirectory structure : In the production directory, create a new folder called  WEB-INF. Inside this WEB-INF folder create 2 new folders called classes and lib.
5. Create a web.xml file : In the WEB-INF folder create file named  web.xml file. This configures the servlet container.

<!DOCTYPE web-app
   PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
   "http://java.sun.com/dtd/web-app_2_3.dtd
">

<web-app
>
   <!-- Standard Action Servlet Configuration -->

 <servlet>

   <servlet-name>
Foo</servlet-name>

   <servlet-class>
com.example.foo.server.FooImpl</servlet-class
>
   <load-on-startup
>2</load-on-startup
>
 </servlet
>
 <!-- Standard Action Servlet Mapping -->

 <servlet-mapping>

   <servlet-name>
Foo</servlet-name>

   <url-pattern>
/Foo</url-pattern>

 </servlet-mapping>

</web-app>

Make sure that the  <url-pattern> value matches the suffix you used when creating the GWT-RPC service with setServiceEntryPoint(URL) in your client-side code (the same path you would use ini <module>.gwt.xml  for hosted mode.)

1. Compile your servlet classes : By default GWT does not compile the server side classes. Use javac or your IDE of choice to compile the server-side code. You should end up with a directory structure similar to  com/example/foo/server/... that contains Java .class files.
2. Copy the servlet classes : Copy the compiled class files from your project (could be in the bin folder of your project) to the  /WEB-INF/classes folder in the staging area. Make sure you include all of the subdirectories as well.
3. Add the GWT servlet library : Copy the gwt-servlet.jar from the GWT distribution to the  /WEB-INF/lib folder.
4. Copy any third party libraries : If you have any third party libraries, make sure you copy those .jar files to the /WEB-INF/lib folder as well.
5. Create a .zip archive : Use your favorite tool to compress the staging area into an archive. Make sure to preserve the directory strucuture, but do not include the root production/ folder.
6. Rename the file to end in .war : Web Engines deploy from Web Archive Repositories. That is what you have just created. All you need to do is rename the .zip file you just created so that the filename extension is  .war.
7. Copy to Tomcat : Copy your .war file into Tomcat's /webapps folder.

If you have default configuration settings it should automatically unzip the .war file.

If Tomcat is in its default configuration at port 8080, you should be able run your application by entering the url http://<hostname>:8080/Foo/Foo.html into your web browser.

If you have problems, look for the Tomcat logfile. If your web pages display but the RPC does not work, try turnning on access logging on Tomcat. You may find that the URL used by the client side has not been registered by Tomcat.

Using Tomcat with Apache HTTPD and a proxy

The above example is a good way to test, but may not be the best production setup. The Tomcat server is not the fastest web server for static files. Also, you may already have a web infrastructure setup for werving static content that you would like to leverage. This example will show you how to split the Web Engine deployment from from the static content.

When you run <module>-compile, the output generated by the GWT compiler in the 'www/' directory is your static content. Copy this to a subdirectory in your apache configuration's document root. We will call that directory  /var/www/doc/Foo and the resulting URL is http://www.example.com/foo-app/Foo.html.

Let's assume that the tomcat server is on a different host named  servlet.example.com. In this case, there is going to be a problem. Ajax's Single Origin Policy will prevent connections to ports or machines that differ from the original URL. The strategy we are going to use to satisfy the SOP is to configure Apache to proxy a URL to another URL.

Specific directions for configuring Apache and Tomcat for such a proxy setup are at [ http://tomcat.apache.org/tomcat-6.0-doc/proxy-howto.html http://tomcat.apache.org/tomcat-6.0-doc/proxy-howto.html]. The general idea is to setup Apache to redirect from a sub-directory of the foo-app project to the other server such that:

http://foo.example.com/foo-app/rpcs/ --> http://servlet.example.com:8080/Foo/

The following Apache configuration sets up such a rule using a Proxy

ProxyPass /
Foo/rpcs/
  http://servlet.example.com:8080/Foo/

ProxyPassReverse /Foo
/rpcs/  http
://servlet.example.com:8080/Foo/

Inside your client-side code, you will need to use 2 directories to map the proxy director to the server. This proxy setup will strip off one level of directory on the client side, so there is an added twist to setting up the  web.xml file. Suppose you have set the proxy directory to be /rpcs/ and are using a backend servlet named servletName. In setServiceEntryPoint(URL), you should append a path rpcs/serviceName  to the base URL. In the Tomcat configuration, you should set the <url-mapping> tag to map the servlet as simply serviceName.

Now, configure your WAR file using the steps in the example for the previous section above with the following exceptions:

• Change the <url-mapping> as mentioned above.
• You can omit copying the contents of the www/ directory (those files should be deployed to the Apache server instead)

Other Deployment Methods

It should be mentioned that these are just two examples of deployment scenarios. There are many ways to configure your application for deployment:

• Many developers use Ant  or a script to automate the deployment of the .war file.
• Some Web Engines take special directives in web.xml that need to be taken into consideration.
• Some web servers have optimized ways to route servlet calls to a servlet engine ( e.g. mod_jk on Apache)
• Some Web servers and Web Engines have facilities for replication so you can load balance your servlet across many nodes.

http://code.google.com/webtoolkit/

[Will McQueen]

Hi Eric,

Thanks for putting together this doc! :-)

I recommend changing this:

<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">

...to this:

<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

Reasons:
======
1) You mention Tomcat 6.0 in your example, and Tomcat 6.0 follows the
Servlet 2.5 spec [Ref: blue table at http://tomcat.apache.org/]
2) The Servlet 2.5 spec has been in final form since May 10, 2006
[Ref: http://java.sun.com/products/servlet/]
3) For those who use JEE 5 (Java EE 5, previously J2EE), the Java EE 5
spec is built on Servlet 2.5 technology [Ref: "Java EE 5 Schema
Resources" http://java.sun.com/xml/ns/javaee/]
4) XSD schema files are in XML, and XML is much easier to understand
than the DTD files (in my opinion). And the DTD file you mention is
for the Servlet 2.3 spec rather than the 2.5 spec. I would say let's
encourage XSD and Servlet 2.5 spec.
5) The schema file itself [Ref: http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd]
says that the Java EE 5 developer must use the following header:
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="..."
version="2.5">

Notice they leave out what you're supposed to put in quotes for
xsi:schemaLocation. I don't know what this is for (maybe something to
do with public and system identifiers?), but I filled-in the missing
info based on a new servlet project I created with NetBeans 6, so that
it now reads:
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
This change is reflected in my recommendation.

If I create a new servlet project in Eclipse, then the following
attributes are also mysteriously inserted:
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="WebApp_ID"

... and I don't know the purpose of "xmlns:web", and as for "id" I
don't think that's a required attribute in this case. So, I left
these out of my recommendation. Maybe an XML expert can fill-in the
missing pieces and come-up with a canonical web.xml header for use
with your examples? Otherwise, I stick with my original
recommendation.

For further reference, the full Servlet 2.5 spec in all its glory can
be downloaded in searchable PDF form at:
http://jcp.org/aboutJava/communityprocess/mrel/jsr154/index.html

Regards,
Will

On Nov 17, 10:10 am, "Eric Ayers" <zun...@google.com> wrote:
> The following is a preview of a section in the upcoming GWT 1.5 Developer's
> Guide. Does this help any? (do you see any problems?)
>
> Deploying RPC
>
> The GWT supplied servlet container is intended only for debugging your
> application. Once you have written and debugged your application, it is time
> to deploy to a production server. When you do so, you will need to select a
> servlet container (also called a web container or web engine) to run the
> backend. GWT does not provide a servlet container to use in production, but
> there are many different products available. The following lists just a few
> commercial and non-commerical offerings:
>

> - Apache Tomcat
> - Jetty
> - JBoss
> - IBM Web Sphere
> - Oracle Application Server

>
> In fact, you can choose any server you like in hosted

> mode<http://code.google.com/support/bin/answer.py?answer=55200&topic=13017>

> as
> well. After setting up your server, start up hosted mode with the
> -noserver option
> to disable GWT's builtin servlet container.
>
> In the examples below, we use Apache HTTPD and Apache Tomcat as a web
> engine. Although there are many different implementations of web servers and
> servlet containers, Servlet API

> Specifications<http://java.sun.com/products/servlet/download.html>

> define
> a standard for structuring your project directories so these instructions
> should apply if you are using another web engine.
> Simple Example with Apache Tomcat
>
> The simplest way to deploy your application is to use a single server for
> both your static content and your servlet classes. These steps assume that
> you created your project with

> applicationCreator<http://code.google.com/p/bunsenandbeaker/wiki/ApplicationCreator>
> :
>
> 1. *Compile* : Compile your code using the *<module>*-compile file
> created by applicationCreator<http://code.google.com/p/bunsenandbeaker/wiki/ApplicationCreator>.

> If the compile is sucessful, the compiler output will be placed in a folder
> called www/<package>.<modulename>.

> 2. *Create a staging area* : Create a temporary folder to stage your

> files to. In this example, we will call the folder production.

> 3. *Copy compiled files to the staging area* : Copy the content files

> from www/<package>.<modulename> to the production staging area folder.

> You should now have files named *.nocache.js, *.cache.js, *.cache.xml
> , *.cache.html and others in the `production staging area folder.
> 4. *Create WEB-INF subdirectory structure* : In the production directory,

> create a new folder called WEB-INF. Inside this WEB-INF folder create
> 2 new folders called classes and lib.

> 5. *Create a web.xml file* : In the WEB-INF folder create file named

> web.xml file. This configures the servlet container.
>
> <!DOCTYPE web-app
> PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
> "http://java.sun.com/dtd/web-app_2_3.dtd">
>
> <web-app>
> <!-- Standard Action Servlet Configuration -->
> <servlet>
> <servlet-name>Foo</servlet-name>
> <servlet-class>com.example.foo.server.FooImpl</servlet-class>
> <load-on-startup>2</load-on-startup>
> </servlet>
> <!-- Standard Action Servlet Mapping -->
> <servlet-mapping>
> <servlet-name>Foo</servlet-name>
> <url-pattern>/Foo</url-pattern>
> </servlet-mapping>
> </web-app>
>
> Make sure that the <url-pattern> value matches the suffix you used when
> creating the GWT-RPC service with setServiceEntryPoint(URL) in your
> client-side code (the same path you would use ini <module>.gwt.xml for
> hosted mode.)
>

> 1. *Compile your servlet classes* : By default GWT does not compile

> the server side classes. Use javac or your IDE of choice to compile
> the server-side code. You should end up with a directory structure similar
> to com/example/foo/server/... that contains Java .class files.

> 2. *Copy the servlet classes* : Copy the compiled class files from

> your project (could be in the bin folder of your project) to the
> /WEB-INF/classes folder in the staging area. Make sure you include all
> of the subdirectories as well.

> 3. *Add the GWT servlet library* : Copy the gwt-servlet.jar from the

> GWT distribution to the /WEB-INF/lib folder.

> 4. *Copy any third party libraries* : If you have any third party

> libraries, make sure you copy those .jar files to the /WEB-INF/lib folder
> as well.

> 5. *Create a .zip archive* : Use your favorite tool to compress the

> staging area into an archive. Make sure to preserve the directory
> strucuture, but do not include the root production/ folder.

> 6. *Rename the file to end in .war* : Web Engines deploy from Web

> Archive Repositories. That is what you have just created. All you need to do
> is rename the .zip file you just created so that the filename
> extension is .war.

> 7. *Copy to Tomcat* : Copy your .war file into Tomcat's /webapps

> folder.
>
> If you have default configuration settings it should automatically unzip the
> .war file.
>
> If Tomcat is in its default configuration at port 8080, you should be able
> run your application by entering the url
> http://<hostname>:8080/Foo/Foo.html into
> your web browser.
>
> If you have problems, look for the Tomcat logfile. If your web pages display
> but the RPC does not work, try turnning on access logging on Tomcat. You may
> find that the URL used by the client side has not been registered by Tomcat.
> Using Tomcat with Apache HTTPD and a proxy
>
> The above example is a good way to test, but may not be the best production
> setup. The Tomcat server is not the fastest web server for static files.
> Also, you may already have a web infrastructure setup for werving static
> content that you would like to leverage. This example will show you how to
> split the Web Engine deployment from from the static content.
>

> When you run *<module>*-compile, the output generated by the GWT compiler in

> the 'www/' directory is your static content. Copy this to a subdirectory in
> your apache configuration's document root. We will call that directory

> /var/www/doc/Foo and the resulting URL ishttp://www.example.com/foo-app/Foo.html.

>
> Let's assume that the tomcat server is on a different host named
> servlet.example.com. In this case, there is going to be a problem. Ajax's
> Single Origin Policy will prevent connections to ports or machines that
> differ from the original URL. The strategy we are going to use to satisfy
> the SOP is to configure Apache to proxy a URL to another URL.
>
> Specific directions for configuring Apache and Tomcat for such a proxy setup

> are at [http://tomcat.apache.org/tomcat-6.0-doc/proxy-howto.htmlhttp://tomcat.apache.org/tomcat-6.0-doc/proxy-howto.html]. The general idea

> is to setup Apache to redirect from a sub-directory of the foo-app project
> to the other server such that:
>

> http://foo.example.com/foo-app/rpcs/-->http://servlet.example.com:8080/Foo/

>
> The following Apache configuration sets up such a rule using a Proxy
>
> ProxyPass /Foo/rpcs/ http://servlet.example.com:8080/Foo/

> ProxyPassReverse /Foo/rpcs/ http://servlet.example.com:8080/Foo/

>
> Inside your client-side code, you will need to use 2 directories to map the
> proxy director to the server. This proxy setup will strip off one level of
> directory on the client side, so there is an added twist to setting up the
> web.xml file. Suppose you have set the proxy directory to be /rpcs/ and are
> using a backend servlet named servletName. In setServiceEntryPoint(URL), you
> should append a path rpcs/serviceName to the base URL. In the Tomcat
> configuration, you should set the <url-mapping> tag to map the servlet as
> simply serviceName.
>
> Now, configure your WAR file using the steps in the example for the previous
> section above with the following exceptions:
>

> - Change the <url-mapping> as mentioned above.
> - You can omit copying the contents of the www/ directory (those files

> should be deployed to the Apache server instead)
>
> Other Deployment Methods
>
> It should be mentioned that these are just two examples of deployment
> scenarios. There are many ways to configure your application for deployment:
>

> - Many developers use Ant or a script to automate the deployment of
> the .war file.
> - Some Web Engines take special directives in web.xml that need to be
> taken into consideration.
> - Some web servers have optimized ways to route servlet calls to a

> servlet engine (e.g. mod_jk on Apache)

> - Some Web servers and Web Engines have facilities for replication so

> you can load balance your servlet across many nodes.
>

> --
> Eric Z. Ayers - GWT Team - Atlanta, GA USAhttp://code.google.com/webtoolkit/

[Will McQueen]

I would also add this as the first line:
<?xml version="1.0" encoding="UTF-8"?>

So final form of web.xml header is:

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaeehttp://
java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5">

Regards,
Will

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="..."
> version="2.5">

Regards,
Will

On Nov 18, 1:28 am, Will McQueen <willmcqu...@yahoo.com> wrote:
> Hi Eric,
>
> Thanks for putting together this doc! :-)
>
> I recommend changing this:
>
> <!DOCTYPE web-app
> PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
> "http://java.sun.com/dtd/web-app_2_3.dtd">
>
> ...to this:
>
> <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

> xsi:schemaLocation="http://java.sun.com/xml/ns/javaeehttp://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

>
> Reasons:
> ======
> 1) You mention Tomcat 6.0 in your example, and Tomcat 6.0 follows the

> Servlet 2.5 spec [Ref: blue table athttp://tomcat.apache.org/]

> 2) The Servlet 2.5 spec has been in final form since May 10, 2006
> [Ref:http://java.sun.com/products/servlet/]
> 3) For those who use JEE 5 (Java EE 5, previously J2EE), the Java EE 5
> spec is built on Servlet 2.5 technology [Ref: "Java EE 5 Schema
> Resources"http://java.sun.com/xml/ns/javaee/]
> 4) XSD schema files are in XML, and XML is much easier to understand
> than the DTD files (in my opinion). And the DTD file you mention is
> for the Servlet 2.3 spec rather than the 2.5 spec. I would say let's
> encourage XSD and Servlet 2.5 spec.
> 5) The schema file itself [Ref:http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd]
> says that the Java EE 5 developer must use the following header:
> <web-app xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="..."
> version="2.5">
>
> Notice they leave out what you're supposed to put in quotes for
> xsi:schemaLocation. I don't know what this is for (maybe something to
> do with public and system identifiers?), but I filled-in the missing
> info based on a new servlet project I created with NetBeans 6, so that
> it now reads:

> xsi:schemaLocation="http://java.sun.com/xml/ns/javaeehttp://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"

> > are at [http://tomcat.apache.org/tomcat-6.0-doc/proxy-howto.htmlhttp://tomcat...]. The general idea

> > is to setup Apache to redirect from a sub-directory of the foo-app project
> > to the other server such that:
>
> >http://foo.example.com/foo-app/rpcs/-->http://servlet.example.com:8080/Foo/
>
> > The following Apache configuration sets up such a rule using a
>

> ...
>
> read more >>

[Eric Ayers]

Thanks for looking it over and the explanation Will.  I've update the docs as you suggested and tested it out using GWT 1.4, Tomcat 6.0 and FF 2.0 and it all seems to work.

-Eric.

http://code.google.com/webtoolkit/