Hello David!
On 25 Nov 2002 at 9:25, David Brown wrote: > Andreas Probst writes: > > > Hi David, > > > > don't put the class files and jars, which you need for an > > applet, below WEB-INF. Tomcat won't serve these files to the > > user's browser. Just put these files in your webapp's > > directory. If you need the same classes also on the server, > > than you need to have two copies of them. > > > > Hope this solves your problem. > > > > Andreas > > older messages deleted > > > Hello Andreas, thanx 4 the accurate and speedy reply. i (on a > hunch) put my applet class under /webapps and can now load which > ur message confirms (thanx). the history of this applet started > out as a java standalone which works perfectly from any remote > client. however to avoid downloads and client compiles i decided > to convert the standalone to an applet. the applet depends on > classes12.jar (or classes12.zip if on windoz). again, class not > found exception because of classes found in classes12.jar. again, > on a hunch, i unpacked the jar under /webapss along w/ the applet > class (i know this is a poor solution but it helped throw light). > when the applet loads i can see that i completes some of the > init() but eventually hangs w/ the following: Exception: > java.util.MissingResourceException: Can't find bundle for > basename Connection.locale en_US > > i know the best solution is for the applet to find the packed jar > and then all should be ok but how? i have put the jar everywhere: > classpath, build.xml property, $TOMCAT_HOME/lib, > $TOMCAT_HOME/common/lib, etc.. any and all ideas, references, > rants and raves welcomed. david. > I think this sounds like an applet problem, which has nothing to do with Tomcat. You should now design your application to run as a normal applet. Package it and put every resource that it needs where I had described before. I don't know, whether I've understood you right. In case you only need to provide an applet without associated servlets, you won't need Tomcat. A normal web server, which serves static content, will be enough and probably the better performing solution. Regards, Andreas -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
