David Vinas wrote: > I have a web application which contains an applet which communicates with
> a servlet, and I am having trouble figuring out how to deploy it. > My servlet shares some utility classes with my applet. As per the > Servlet API, the servlet should be deployed in the following location: > > <context>/WEB-INF/classes/servlet Why? You can place your servlet classes anywhere inside <context>/WEB-INF/classes tree or inside a *.jar in a suitable location. For Tomcat (and I imagine other Servlet Containers) the suitable location is <context>/WEB-INF/lib/ > and the utility package: > > <context>/WEB-INF/classes/util Unless the class itself is being used by the Servlet Container itself (or the Web application, via Servlet Container), there is no need to place it under ./WEB-INF/classes. Since it is applet you're talking about, why wouldn't you place it somewhere on the public web tree, like "<context>/applets/my_applet.class"? It is going to be accessed by the browser, if you want it to run your applet, so there's no point in hiding it in ./WEB-INF/ tree. I haven't recently looked at the Servlet Specificiation, but I don't recall it mentioning anything special about Applets. I recall JSP having a <jsp:plugin ...> directive, but I'm not sure if there anything like what you're saying. > But, although the spec mentions "Client side Java applets" (SRV.9.3), it is > completely vague about where to put them. I can only assume they mean that > the applets should reside somewhere like: > > <context>/MyApplet.html > <context>/classes/*.class Looks right to me. > Which creates a problem for the applet to access the utility classes, which > are in a non-public folder. I don't want to have to create copies of these > classes, so I want them to be accessible by both the servlet and applet. I think applet specification is clear about it - all classes needed for an applet to run must be provided to the browser, either as installed or in a JAR file, together with the applet class. > I suppose there might be some way to create a mapping to WEB-INF/classes, > but this would seem to violate the spirit of the API. Indeed. > On the other hand, I > don't think I should put the applet under WEB-INF/classes for the same reason. > The only other way I can think is to put them in WEB-INF/lib, but I don't know > how to give the applet access. Make a double packaging. Use Ant for the manual part of the job. Nix. -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
