RE: [Fwd: Re: servlet error]
Hi, [EMAIL PROTECTED] has been unsubscribed already. Yoav Shapira Millennium Research Informatics >-Original Message- >From: Paul Mansfield [mailto:[EMAIL PROTECTED] >Sent: Thursday, April 08, 2004 9:52 AM >To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] >Cc: Tomcat Users List >Subject: [Fwd: Re: servlet error] > >error messages from sci.de domain mail system... > >xlink - you're in the RIPE records for the IP address of the mail >handler for sci.de > >some retard signed up to the Tomcat Users List >(<[EMAIL PROTECTED]>) and then killed the mailbox without >unsubscribing > >and now anyone who emails the list gets back the stupid error message >below which is completely useless for removing the subscription > >will the retard in charge of the sci.de mail machine please >a) fix the machine to generate useful error messages >b) find out what the subscribed email address WAS and have it removed? > >List-Unsubscribe: <mailto:[EMAIL PROTECTED]> > > >-----Forwarded Message- >From: . <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: servlet error >Date: Thu, 08 Apr 2004 13:46:22 +0200 > >Das von Ihnen gewählte E-Mail-Postfach ist ungültig. Ihre Email wurde nicht >an den Empfänger weitergeleitet. Für Rückfragen kontaktieren Sie bitte > >The email-address you choose does not exist. >The recipient did not receive your email. For more information please >contact > >SCI Verkehr GmbH >Hardefuststr. 11 - 13 >50677 Köln / Cologne >Germany >Tel. +49 (0) 221 93178 0 > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Fwd: Re: servlet error]
error messages from sci.de domain mail system... xlink - you're in the RIPE records for the IP address of the mail handler for sci.de some retard signed up to the Tomcat Users List (<[EMAIL PROTECTED]>) and then killed the mailbox without unsubscribing and now anyone who emails the list gets back the stupid error message below which is completely useless for removing the subscription will the retard in charge of the sci.de mail machine please a) fix the machine to generate useful error messages b) find out what the subscribed email address WAS and have it removed? List-Unsubscribe: <mailto:[EMAIL PROTECTED]> -Forwarded Message- From: . <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: servlet error Date: Thu, 08 Apr 2004 13:46:22 +0200 Das von Ihnen gewählte E-Mail-Postfach ist ungültig. Ihre Email wurde nicht an den Empfänger weitergeleitet. Für Rückfragen kontaktieren Sie bitte The email-address you choose does not exist. The recipient did not receive your email. For more information please contact SCI Verkehr GmbH Hardefuststr. 11 - 13 50677 Köln / Cologne Germany Tel. +49 (0) 221 93178 0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: servlet error
On Thu, 2004-04-08 at 12:44, Moahmed A. Shalaby wrote: > Hii > I was using Oracle Application sever 4.0.8 to run my servlets , but > When i'm executing my servlet using NetBeans IDE 3.5 and Tomcat it raise > the following error : > > java.lang.NoSuchMethodError: main > Exception in thread "main" > how could i solve it ??? > thank you classpath problem? also check file permissions? look for the full stack trace in a log file? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Servlet Error
Howdy, Ask the BugRat vendor. Yoav Shapira Millennium ChemInformatics >-Original Message- >From: kalyan chakravarti [mailto:[EMAIL PROTECTED] >Sent: Friday, January 02, 2004 1:51 AM >To: [EMAIL PROTECTED] >Subject: Servlet Error > >Sir, > I am using TOMCAT Server on Windows 2000 Professional. I configured >TOMCAT as per the instructions. All Servlet-Examples and JSPsamples are >running fine. I deployed BugRat WAR file and configured the web.xml file as >specified by Bug Rat vendor installation notes. But while asking for the >BugRat View, BurRatReport, BugRatAdmin Servlets system is unble to locate >the servlet classes even though they are loaded in the WebApps directory. >Please suggest me a solution. > >With Regards, >G.V.K.Chakravarti >Software Engineer, >JAVASOFTECH PVT LTD., >Secunderabad. >INDIA >email:[EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Servlet Error "Variable may not have been initialized"
Hi Steven. I'll update to Tomcat 4.1.x. Thanks. -- HIDEAKI KURASHIGE [EMAIL PROTECTED] > -Original Message- > From: Steven Shand [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 27, 2003 6:39 PM > To: Tomcat Users List > Subject: Re: Servlet Error "Variable may not have been initialized" > > > Upgrading to Tomcat 4.1.x with the new Jasper worked for me. > > For what it's worth, I only ever had this problem when compiling jsps > with a large amount of dynamic content. And only ever on Solaris. > > Steven Shand > > On Thursday, March 27, 2003, at 01:57 am, hideaki KURASHIGE wrote: > > > Hi list. > > > > When I modify JSP files,sometimes servlet error occurr as follows. > > > > -- error > > Generated servlet error: > > /opt/tomcat/work/.jsp:487: Variable X may not have been > > initialized. > > > > > > By restarting tomcat,this servlet error disappears and everything > > works okay. > > > > I am using the following setup: > > OS:Solaris 8 > > TOMCAT:4.0.3 > > JRE :1.4.0_01 > > > > - I found same case in Tomcat Bugzilla(BUG#:11882),but I can not find > > any > > solution. > > > > Does somebody know solution? > > > > Best regards. > > > > -- > > HIDEAKI KURASHIGE > > [EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Servlet Error "Variable may not have been initialized"
Upgrading to Tomcat 4.1.x with the new Jasper worked for me. For what it's worth, I only ever had this problem when compiling jsps with a large amount of dynamic content. And only ever on Solaris. Steven Shand On Thursday, March 27, 2003, at 01:57 am, hideaki KURASHIGE wrote: Hi list. When I modify JSP files,sometimes servlet error occurr as follows. -- error Generated servlet error: /opt/tomcat/work/.jsp:487: Variable X may not have been initialized. By restarting tomcat,this servlet error disappears and everything works okay. I am using the following setup: OS:Solaris 8 TOMCAT:4.0.3 JRE :1.4.0_01 - I found same case in Tomcat Bugzilla(BUG#:11882),but I can not find any solution. Does somebody know solution? Best regards. -- HIDEAKI KURASHIGE [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Servlet Error
I think you'll have to look at your servlet code and see where it could be creating a null pointer exception. -Original Message- From: Stuart Shay [mailto:[EMAIL PROTECTED]] Sent: Friday, July 06, 2001 3:35 PM To: [EMAIL PROTECTED] Subject: Servlet Error Hello All: Below is the error code I am recieciving when I run a simple Servlet on my laptop, everything works fine on my test machine so i know the code works. The example servlets run fine, are there any configuration settings that I may have over looked. The version of Tomcat/Apache that I am using is customized version part of a software package. >From the error code below maybe someone can lead me in the right direction. Thanks Stuart Error: 500 Location: /iw/samples/hello.html Internal Servlet Error: java.lang.NullPointerException at java.lang.ClassLoader.resolveClass0(Native Method) at java.lang.ClassLoader.resolveClass(ClassLoader.java:588) at org.apache.tomcat.loader.AdaptiveClassLoader.loadClass(AdaptiveClassLoader.j ava:430) at org.apache.tomcat.loader.AdaptiveServletLoader.loadClass(AdaptiveServletLoad er.java:174) at org.apache.tomcat.core.ServletWrapper.loadServlet(ServletWrapper.java:265) at org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:289) at org.apache.tomcat.core.Handler.service(Handler.java:254) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:484)
RE: servlet error..
> The AWT classes need an x-server to work with images. Worse yet, the server has to be unlocked: you can't connect to a locked server. -- Bill K. > -Original Message- > From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 29, 2001 11:52 PM > To: '[EMAIL PROTECTED]' > Subject: AW: servlet error.. > > > The AWT classes need an x-server to work with images. > > Can it be that there isn't one running, when this error happens ? > > > -Ursprüngliche Nachricht- > > Von: Krishna Kishore Thotakura [mailto:[EMAIL PROTECTED]] > > Gesendet: Mittwoch, 30. Mai 2001 01:05 > > An: [EMAIL PROTECTED] > > Betreff: servlet error.. > > > > > > Hi, > > i am trying to write an image to the outputstream of a > > servlet. The image is > > actually obtained from an invisible awt Canvas. > > I'm using Jimi package to encode the Image into JPEG format > > and writing this > > out to the ServletOutputStream. Sometimes this works fine and > > i see a nice > > image in the browser but at times, i get the following error: > > in tomcat.log > > Xlib: connection to ":0.0" refused by server > > Xlib: Invalid MIT-MAGIC-COOKIE-1 key > > > > in browser --- > > Error: 500 > > Location: /wms/servlet/WmsServlet > > Internal Servlet Error: > > > > java.lang.NoClassDefFoundError > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:120) > > at java.awt.Toolkit$2.run(Toolkit.java:498) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:489) > > at java.awt.Component.getToolkitImpl(Component.java:657) > > at java.awt.Component.getToolkit(Component.java:641) > > at java.awt.Component.createImage(Component.java:2265) > > at stt.View.ViewJava3D.initMem(ViewJava3D.java:190) > > at stt.View.ViewJava3D.(ViewJava3D.java:214) > > at stt.Display.DisplayManager.initView(DisplayManager.java:126) > > at stt.Display.DisplayManager.(DisplayManager.java:64) > > at sttx.Display.GeoDisplayManager.(GeoDisplayManager.java:79) > > at WmsServlet.init(WmsServlet.java:49) > > > > Any comments,suggestions,explanations would be greatly appreciated. > > >
RE: Servlet error
> hi
> i'm trying to send a picture to the browser but i keep
> getting this error
>
> public class GetTiff extends HttpServlet
> {
> protected void doGet(HttpServletRequest req, HttpServletResponse
> res)
> throws ServletException,IOException
> {
> res.setContentType("image/jpeg"); // image/jpeg
>
> OutputStream out=res.getOutputStream();
>
> FileInputStream file=new
> FileInputStream("d:/matrix.jpg");
> int databyte;
> while((databyte=file.read())>=0)
> { out.write(databyte); }
> }
> }
>
> here's the error:
> java.lang.IllegalStateException: Writer is already being used for this
> request
>
> does anyone have a clue how can i fix this problem
>
> thanks for any advice
Something has a handle to the JSPWriter for the response. Try making a
request to the servlet outside of any JSP functionality.
---
Michael Wentzel
Software Developer
Software As We Think - http://www.aswethink.com
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Servlet error I can't seem to resolve
is your web.xml set up correctly for the class? for example: servletname com.pkg.here.ServletName servletname /servletname/ Show the configuration you are using for the servlet in your web.xml if you do already have this set up. I don't believe this is a problem with TOMCAT finding the lib dir but more like TOMCAT not being told where the Servlet is located. --- Michael Wentzel Software Developer http://www.aswethink.com">Software As We Think mailto:[EMAIL PROTECTED]">Michael Wentzel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Servlet error I can't seem to resolve
I got same problem. Someone can help me? Hi, I try to run Servlet from TOMCAT, but it has error. Please give me some help! The Servlet is to access Oracle DB. V8i. from the Travel DB that I download from Oracle site. I use Jdeveloper 3.1.1.2 to create this project. It compiles and runs fine in Jdeveloper. When I try to deploy it to TOMCAT, it has the following error message: Error: 500 Location: /examples/servlet/test/test Internal Servlet Error: java.lang.NullPointerException at java.lang.ClassLoader.resolveClass0(Native Method) at java.lang.ClassLoader.resolveClass(ClassLoader.java:588) at org.apache.tomcat.loader.AdaptiveClassLoader.loadClass(AdaptiveClassLoader.java:430) at org.apache.tomcat.loader.AdaptiveServletLoader.loadClass(AdaptiveServletLoader.java:174) at org.apache.tomcat.core.ServletWrapper.loadServlet(ServletWrapper.java:265) at org.apache.tomcat.core.ServletWrapper.init(ServletWrapper.java:289) at org.apache.tomcat.core.Handler.service(Handler.java:254) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:797) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498) at java.lang.Thread.run(Thread.java:484) It looks to me like Tomcat cannot fine the lib files. Also, the test.jar deployment file has sub directory. If I unzip them to F:\tomcat\jakarta-tomcat-3.2\webapps\examples\WEB-INF\classes, it will create several sub directories and jar files. How can I run the test.class file, if the file is in a sub directory say myproject? Can Tomcat get the lib and attachment file from all the sub directory? Thanks very much. kenny __ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Servlet error I can't seem to resolve
Simon, Wow, more like a few dollars worth! Thank you for your insights. Would you be willing to share the dir structure and the web.xml file for one of your self-contained webapps? This would be incredibly helpful! Thanks again. Peter -Original Message- From: Kitching Simon <[EMAIL PROTECTED]> To: '[EMAIL PROTECTED]' <[EMAIL PROTECTED]> Date: Wednesday, December 27, 2000 9:51 AM Subject: RE: Servlet error I can't seem to resolve > > >> -Original Message- >> From: Jeffry Guttadauro [SMTP:[EMAIL PROTECTED]] >> Sent: Wednesday, December 27, 2000 6:07 PM >> To: [EMAIL PROTECTED] >> Subject: RE: Servlet error I can't seem to resolve >> >> Hi, Simon. >> >> Why would you say that it's a bad idea to put .jar files in the >> classpath? In the case of commonly-used jars, like mail.jar for example, >> why >> would it be better to replicate this in each application's WEB-INF/lib >> directory? >> >> Thanks, >> -Jeff >> > [Kitching Simon] > First of all, it makes it easier to install a webapp. > For example, if you migrate a webapp to a different > machine because it has been wildly successful and > bigger hardware is required, and all required libs are > under WEB-INF/lib, then the move is trivial. Otherwise, > the required libs need to be installed separately. And > remember that this may happen well after the original > developers have left! > > Secondly, it removes inter-webapp version dependencies. > Suppose that one webapp requires an updated version of a > shared lib. If you upgrade the shared lib, then you need to > retest every single webapp, even if only one of them *actually* > needed the upgrade. And with libs in the classpath, it > can be difficult to even know which webapps use a lib > and which don't. > > Thirdly, putting stuff in the classpath interferes with > auto-reloading of changed classes. Each webapp gets its > own classloader, which makes it possible to do things like > dynamically reloading classes that have changed, and > stopping a single webapp context without shutting down > the whole of tomcat. If some of the webapp's code is loaded > from the CLASSPATH (ie is loaded by the system classloader, > not the webapp-specific classloader) then there can > be problems. > > Fourthly, when a class is loaded via the system classpath, > there is only one copy of the class methods, and one copy > of class (ie static) variables for that class. If methods on the > class are synchronized, then there will be contention for the > class lock between webapps. One webapp could possibly > hang another by acquiring & not releasing such a lock. When > a class is loaded by the webapp-specific classloader, this > contention cannot occur - webapps are better isolated from > each other. And of course, if a webapp sets the value of a > static member of the class (eg setMaxFoo(3)) then that > attribute is visible to all webapps in the tomcat instance, > again not providing web application isolation. (note, while > this could be regarded as a "feature" for allowing data > communication between webapps, I thing this is a bad > idea, as it assumes the webapps are running in the same > virtual machine. Communicating via a shared database, > or a shared EJB, or even raw sockets, seems to me to be > a better way for webapps to intercommunicate). > > Fifthly, if you get seriously into security, for example by > defining java security policies, then there may > be implications. I'm not entirely sure about the effects > here, but it seems that having per-webapp copies > of libs, and *not* having extra stuff in the classpath > (eg libs used by other webapps) can only be good. > > Sixthly, I think there are problems with loading resource > files. If you (or shared code) calls getResourceBundle() > or related methods, I suspect the places the JVM looks for > the resource file is different... > > Against that, the "libs in CLASSPATH" approach seems to > offer two benefits: save disk space and save RAM. I think > trying to save a megabyte of disk space (and that's a big jar!) > is really pointless in this age. Saving RAM by only loading > one copy of a class might have some benefit - but I'm not > sure that this doesn't happen anyway. The fact that a class > needs to *behave* as if it were per-classloader doesn't mean > that two copies of the bytecode are loaded (or does it? I > don't know what run-time-linking does to the original bytecode...) > > I guess if you have a really large jar, and dozens of webapps > use it, there is a valid case for the classpath approach, but > in gene
RE: Servlet error I can't seem to resolve
2 cents?? I'd say that was at least a buck fifty... Good points all. Very enlightening. Thanks for the explanation! [EMAIL PROTECTED] on 12/27/2000 11:51:53 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: RE: Servlet error I can't seem to resolve > -Original Message- > From: Jeffry Guttadauro [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, December 27, 2000 6:07 PM > To: [EMAIL PROTECTED] > Subject: RE: Servlet error I can't seem to resolve > > Hi, Simon. > > Why would you say that it's a bad idea to put .jar files in the > classpath? In the case of commonly-used jars, like mail.jar for example, > why > would it be better to replicate this in each application's WEB-INF/lib > directory? > > Thanks, > -Jeff > [Kitching Simon] First of all, it makes it easier to install a webapp. For example, if you migrate a webapp to a different machine because it has been wildly successful and bigger hardware is required, and all required libs are under WEB-INF/lib, then the move is trivial. Otherwise, the required libs need to be installed separately. And remember that this may happen well after the original developers have left! Secondly, it removes inter-webapp version dependencies. Suppose that one webapp requires an updated version of a shared lib. If you upgrade the shared lib, then you need to retest every single webapp, even if only one of them *actually* needed the upgrade. And with libs in the classpath, it can be difficult to even know which webapps use a lib and which don't. Thirdly, putting stuff in the classpath interferes with auto-reloading of changed classes. Each webapp gets its own classloader, which makes it possible to do things like dynamically reloading classes that have changed, and stopping a single webapp context without shutting down the whole of tomcat. If some of the webapp's code is loaded from the CLASSPATH (ie is loaded by the system classloader, not the webapp-specific classloader) then there can be problems. Fourthly, when a class is loaded via the system classpath, there is only one copy of the class methods, and one copy of class (ie static) variables for that class. If methods on the class are synchronized, then there will be contention for the class lock between webapps. One webapp could possibly hang another by acquiring & not releasing such a lock. When a class is loaded by the webapp-specific classloader, this contention cannot occur - webapps are better isolated from each other. And of course, if a webapp sets the value of a static member of the class (eg setMaxFoo(3)) then that attribute is visible to all webapps in the tomcat instance, again not providing web application isolation. (note, while this could be regarded as a "feature" for allowing data communication between webapps, I thing this is a bad idea, as it assumes the webapps are running in the same virtual machine. Communicating via a shared database, or a shared EJB, or even raw sockets, seems to me to be a better way for webapps to intercommunicate). Fifthly, if you get seriously into security, for example by defining java security policies, then there may be implications. I'm not entirely sure about the effects here, but it seems that having per-webapp copies of libs, and *not* having extra stuff in the classpath (eg libs used by other webapps) can only be good. Sixthly, I think there are problems with loading resource files. If you (or shared code) calls getResourceBundle() or related methods, I suspect the places the JVM looks for the resource file is different... Against that, the "libs in CLASSPATH" approach seems to offer two benefits: save disk space and save RAM. I think trying to save a megabyte of disk space (and that's a big jar!) is really pointless in this age. Saving RAM by only loading one copy of a class might have some benefit - but I'm not sure that this doesn't happen anyway. The fact that a class needs to *behave* as if it were per-classloader doesn't mean that two copies of the bytecode are loaded (or does it? I don't know what run-time-linking does to the original bytecode...) I guess if you have a really large jar, and dozens of webapps use it, there is a valid case for the classpath approach, but in general I think having self-contained webapps makes life easier for everyone concerned.. Just my two cents :-) Simon > [EMAIL PROTECTED] on 12/27/2000 10:32:34 AM > Please respond to [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > cc: > Subject: RE: Servlet error I can't seem to resolve > > The stack-trace seems pretty clear to me - the > "sendIt" method of the IridiumSendMail class is > storing a null pointer into a hashtable. > > What you may find is that the IridiumSendMail > class
RE: Servlet error I can't seem to resolve
> -Original Message- > From: Jeffry Guttadauro [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, December 27, 2000 6:07 PM > To: [EMAIL PROTECTED] > Subject: RE: Servlet error I can't seem to resolve > > Hi, Simon. > > Why would you say that it's a bad idea to put .jar files in the > classpath? In the case of commonly-used jars, like mail.jar for example, > why > would it be better to replicate this in each application's WEB-INF/lib > directory? > > Thanks, > -Jeff > [Kitching Simon] First of all, it makes it easier to install a webapp. For example, if you migrate a webapp to a different machine because it has been wildly successful and bigger hardware is required, and all required libs are under WEB-INF/lib, then the move is trivial. Otherwise, the required libs need to be installed separately. And remember that this may happen well after the original developers have left! Secondly, it removes inter-webapp version dependencies. Suppose that one webapp requires an updated version of a shared lib. If you upgrade the shared lib, then you need to retest every single webapp, even if only one of them *actually* needed the upgrade. And with libs in the classpath, it can be difficult to even know which webapps use a lib and which don't. Thirdly, putting stuff in the classpath interferes with auto-reloading of changed classes. Each webapp gets its own classloader, which makes it possible to do things like dynamically reloading classes that have changed, and stopping a single webapp context without shutting down the whole of tomcat. If some of the webapp's code is loaded from the CLASSPATH (ie is loaded by the system classloader, not the webapp-specific classloader) then there can be problems. Fourthly, when a class is loaded via the system classpath, there is only one copy of the class methods, and one copy of class (ie static) variables for that class. If methods on the class are synchronized, then there will be contention for the class lock between webapps. One webapp could possibly hang another by acquiring & not releasing such a lock. When a class is loaded by the webapp-specific classloader, this contention cannot occur - webapps are better isolated from each other. And of course, if a webapp sets the value of a static member of the class (eg setMaxFoo(3)) then that attribute is visible to all webapps in the tomcat instance, again not providing web application isolation. (note, while this could be regarded as a "feature" for allowing data communication between webapps, I thing this is a bad idea, as it assumes the webapps are running in the same virtual machine. Communicating via a shared database, or a shared EJB, or even raw sockets, seems to me to be a better way for webapps to intercommunicate). Fifthly, if you get seriously into security, for example by defining java security policies, then there may be implications. I'm not entirely sure about the effects here, but it seems that having per-webapp copies of libs, and *not* having extra stuff in the classpath (eg libs used by other webapps) can only be good. Sixthly, I think there are problems with loading resource files. If you (or shared code) calls getResourceBundle() or related methods, I suspect the places the JVM looks for the resource file is different... Against that, the "libs in CLASSPATH" approach seems to offer two benefits: save disk space and save RAM. I think trying to save a megabyte of disk space (and that's a big jar!) is really pointless in this age. Saving RAM by only loading one copy of a class might have some benefit - but I'm not sure that this doesn't happen anyway. The fact that a class needs to *behave* as if it were per-classloader doesn't mean that two copies of the bytecode are loaded (or does it? I don't know what run-time-linking does to the original bytecode...) I guess if you have a really large jar, and dozens of webapps use it, there is a valid case for the classpath approach, but in general I think having self-contained webapps makes life easier for everyone concerned.. Just my two cents :-) Simon > [EMAIL PROTECTED] on 12/27/2000 10:32:34 AM > Please respond to [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > cc: > Subject: RE: Servlet error I can't seem to resolve > > The stack-trace se
RE: Servlet error I can't seem to resolve
Your props is a hashtable (its a java.util.Properties which extends the java.util.Hashtable). If I had to guess, your getInitParameter method is not returning values. This would cause your problem because the class variables would then be null and then you try to put them into the Properties object, causing the NullPointer. I don't know why this method is not returning values - your web.xml file looks correct to me, but I don't use this so I could be wrong. A thought, probably off base, you are calling the servlet as /servlet/FormEngineLight from contact.html, but you set the URL-Mapping and Servlet name as /FormEngineLight - maybe its not finding the initialized servlet? Randy -Original Message- From: Brad Siegfreid [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 27, 2000 12:22 PM To: [EMAIL PROTECTED] Subject: RE: Servlet error I can't seem to resolve I saw that. I figured that JavaMail wasn't loading or something. But I've tried it with the mail.jar file in both the WEB-INF/lib directory and in the classpath. I don't deal with any hashtable directly. The params that are loading are going into FormEngineLight. I did a test program to make sure I was loading initParameters correctly and it worked fine on my local machine at least. See a later message for the location of my source files. Brad -- On Wednesday, December 27, 2000, at 09:56 AM, Randy Layman wrote: > > If would seem that you are trying to put a null as either the key or > value into a Hashtable. This is happening in the IridiumSendMail's sendIt > method. Maybe a variable you expect to be in a session or application > object are not set? Or some parameter file is not being loaded? > > Randy > > -Original Message- > From: Brad Siegfreid [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 27, 2000 11:21 AM > To: [EMAIL PROTECTED] > Subject: Servlet error I can't seem to resolve > > > I have a simple form handling servlet (FormEngineLight) that connects to a > email class (IridiumSendMail) that have been working with another host under > JServ 1.0b3. I moved to a new host with Tomcat 3.2 and also now have Tomcat > 3.2 working on a local machine for testing. Now my servlet/class combo fails > to work in either location. They require mail.jar and activation.jar, which > are in the classpath (initially just in the context lib directory, now in > the locations that load at boot). My apps are compiled agains Java 1.18 but > are running on 1.2 for both local and hosted. > > The stackTrace I get from FormEngineLight (emailed back using the > sun.net.smtp classes) is: > > java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:381) > at IridiumSendMail.sendIt(IridiumSendMail.java) > at FormEngineLight.writeToIridiumSendMail(FormEngineLight.java) > at FormEngineLight.sendConfirmation(FormEngineLight.java) > at FormEngineLight.service(FormEngineLight.java) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java:499) > at > org.apache.tomcat.core.ContextManager.service(ContextManager.java:559) > at > org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC > onnectionHandler.java:160) > at > org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:338 > ) > at java.lang.Thread.run(Thread.java:479) > > Both of my files are in jars and reside in the lib directory. The > FormEngineLight servlet is accessible and sends me the error shown above. > Does the IridiumSendMail file have to be listed in the web.xml file even if > its not a servlet. If so, do I list it as if it were a servlet? > > Thanks, > Brad Siegfreid > Iridiumdesign > >
RE: Servlet error I can't seem to resolve
SWEET! Gotta love user groups like this. Fixed up my local machine. Have to wait for the host to recycle (once every hour 'til Enhydra is installed). Now if I can just figure out how to write to a file on the server. I'm sure that is some sort of permissions issue like last time Thanks Kitching! Brad On Wednesday, December 27, 2000, at 11:17 AM, Kitching Simon wrote: > I can spot one problem with your web.xml file... > > An can contain only one name/value pair. > For passing multiple params to a servlet, use multiple > init-param tags. > > This probably causes the smtpServer attribute you pass > to the IridiumSendMail class to be null, hence the problem. > > Wrong: > > foo > fooval > bar > barval > > > Right: > > foo > fooval > > > bar > barval > > > For debugging problems like this, I can highly > recommend using a decent LOGGING module, > such as log4j (downloadable from sourceforge). > This is easier than arranging bug reports to be > emailed! (though log4j could be configured to > email logged problems if desired...) > > Your website looks interesting - I presume it is a > new web-hosting service. Is there any chance the > service is going to be free?? > > > -Original Message- > > From: Brad Siegfreid [SMTP:[EMAIL PROTECTED]] > > Sent: Wednesday, December 27, 2000 6:00 PM > > To: [EMAIL PROTECTED] > > Cc: Kitching Simon > > Subject:RE: Servlet error I can't seem to resolve > > > > That was what I was thinking at first. I've gone back in and double > > checked how I did it before. > > > > These are all placed in WEB-INF/lib: > > FormEngineLight.jar > > IridiumSendMail.jar > > activation.jar (just redownloaded the latest, recompiled my files) > > mail.jar (just redownloaded the latest, recompiled my files) > > > > the web.xml file contains the references to the FormEngineLight servlet. I > > double checked that its picking up its init params by doing a test program > > and comparing how it now grabs its params and that all worked fine. > > > > You can see what I have at: > > > > www.iridiumdesign.com/ > > FormEngineLight.java.txt > > IridiumSendMail.java.txt > > web.xml.txt > > > > The page that starts it all is contact.html > > > > Although I'm not an experienced programmer yet this stuff worked like a > > charm under JServ. Any advice would be appreciated. > > > > Thanks, > > Brad Siegfreid > > Iridiumdesign > > > > On Wednesday, December 27, 2000, at 10:30 AM, Kitching Simon wrote: > > > > > The stack-trace seems pretty clear to me - the > > > "sendIt" method of the IridiumSendMail class is > > > storing a null pointer into a hashtable. > > > > > > What you may find is that the IridiumSendMail > > > class is expecting to load a resource file from > > > somewhere, but not finding it because you > > > forgot to install it, or didn't install it in the > > > right place. > > > > > > Just a note on the location of the "mail.jar" > > > and "activation.jar" files - I think that the > > > correct place for these is where you > > > first had them, in the WEB-INF/lib > > > directory within your web application. > > > Placing jars in the classpath is > > > generally a bad idea with tomcat > > > (though quite a lot of tomcat users > > > don't seem to understand this; presumably > > > they are the same ones that would be > > > using global variables under c++ :-) > > > > > > regards, > > > > > > Simon > > > > -Original Message- > > > > From: Brad Siegfreid [SMTP:[EMAIL PROTECTED]] > > > > Sent: Wednesday, December 27, 2000 5:21 PM > > > > To: [EMAIL PROTECTED] > > > > Subject:Servlet error I can't seem to resolve > > > > > > > > I have a simple form handling servlet (FormEngineLight) that connects > > to a > > > > email class (IridiumSendMail) that have been working with another host > > > > > > under JServ 1.0b3. I moved to a new host with Tomcat 3.2 and also now > > have > > > > Tomcat 3.2 working on a local machine for testing. Now my > > servlet/class > > > > combo fails to work i
RE: Servlet error I can't seem to resolve
I saw that. I figured that JavaMail wasn't loading or something. But I've tried it with the mail.jar file in both the WEB-INF/lib directory and in the classpath. I don't deal with any hashtable directly. The params that are loading are going into FormEngineLight. I did a test program to make sure I was loading initParameters correctly and it worked fine on my local machine at least. See a later message for the location of my source files. Brad -- On Wednesday, December 27, 2000, at 09:56 AM, Randy Layman wrote: > > If would seem that you are trying to put a null as either the key or > value into a Hashtable. This is happening in the IridiumSendMail's sendIt > method. Maybe a variable you expect to be in a session or application > object are not set? Or some parameter file is not being loaded? > > Randy > > -Original Message- > From: Brad Siegfreid [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 27, 2000 11:21 AM > To: [EMAIL PROTECTED] > Subject: Servlet error I can't seem to resolve > > > I have a simple form handling servlet (FormEngineLight) that connects to a > email class (IridiumSendMail) that have been working with another host under > JServ 1.0b3. I moved to a new host with Tomcat 3.2 and also now have Tomcat > 3.2 working on a local machine for testing. Now my servlet/class combo fails > to work in either location. They require mail.jar and activation.jar, which > are in the classpath (initially just in the context lib directory, now in > the locations that load at boot). My apps are compiled agains Java 1.18 but > are running on 1.2 for both local and hosted. > > The stackTrace I get from FormEngineLight (emailed back using the > sun.net.smtp classes) is: > > java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:381) > at IridiumSendMail.sendIt(IridiumSendMail.java) > at FormEngineLight.writeToIridiumSendMail(FormEngineLight.java) > at FormEngineLight.sendConfirmation(FormEngineLight.java) > at FormEngineLight.service(FormEngineLight.java) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java:499) > at > org.apache.tomcat.core.ContextManager.service(ContextManager.java:559) > at > org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC > onnectionHandler.java:160) > at > org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:338 > ) > at java.lang.Thread.run(Thread.java:479) > > Both of my files are in jars and reside in the lib directory. The > FormEngineLight servlet is accessible and sends me the error shown above. > Does the IridiumSendMail file have to be listed in the web.xml file even if > its not a servlet. If so, do I list it as if it were a servlet? > > Thanks, > Brad Siegfreid > Iridiumdesign > >
RE: Servlet error I can't seem to resolve
Hi, Simon. Why would you say that it's a bad idea to put .jar files in the classpath? In the case of commonly-used jars, like mail.jar for example, why would it be better to replicate this in each application's WEB-INF/lib directory? Thanks, -Jeff [EMAIL PROTECTED] on 12/27/2000 10:32:34 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: RE: Servlet error I can't seem to resolve The stack-trace seems pretty clear to me - the "sendIt" method of the IridiumSendMail class is storing a null pointer into a hashtable. What you may find is that the IridiumSendMail class is expecting to load a resource file from somewhere, but not finding it because you forgot to install it, or didn't install it in the right place. Just a note on the location of the "mail.jar" and "activation.jar" files - I think that the correct place for these is where you first had them, in the WEB-INF/lib directory within your web application. Placing jars in the classpath is generally a bad idea with tomcat (though quite a lot of tomcat users don't seem to understand this; presumably they are the same ones that would be using global variables under c++ :-) regards, Simon > -Original Message- > From: Brad Siegfreid [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, December 27, 2000 5:21 PM > To: [EMAIL PROTECTED] > Subject: Servlet error I can't seem to resolve > > I have a simple form handling servlet (FormEngineLight) that connects to a > email class (IridiumSendMail) that have been working with another host > under JServ 1.0b3. I moved to a new host with Tomcat 3.2 and also now have > Tomcat 3.2 working on a local machine for testing. Now my servlet/class > combo fails to work in either location. They require mail.jar and > activation.jar, which are in the classpath (initially just in the context > lib directory, now in the locations that load at boot). My apps are > compiled agains Java 1.18 but are running on 1.2 for both local and > hosted. > > The stackTrace I get from FormEngineLight (emailed back using the > sun.net.smtp classes) is: > > java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:381) > at IridiumSendMail.sendIt(IridiumSendMail.java) > at FormEngineLight.writeToIridiumSendMail(FormEngineLight.java) > at FormEngineLight.sendConfirmation(FormEngineLight.java) > at FormEngineLight.service(FormEngineLight.java) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java:49 > 9) > at > org.apache.tomcat.core.ContextManager.service(ContextManager.java:559) > at > org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(Htt > pConnectionHandler.java:160) > at > org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:3 > 38) > at java.lang.Thread.run(Thread.java:479) > > Both of my files are in jars and reside in the lib directory. The > FormEngineLight servlet is accessible and sends me the error shown above. > Does the IridiumSendMail file have to be listed in the web.xml file even > if its not a servlet. If so, do I list it as if it were a servlet? > > Thanks, > Brad Siegfreid > Iridiumdesign
RE: Servlet error I can't seem to resolve
That was what I was thinking at first. I've gone back in and double checked how I did it before. These are all placed in WEB-INF/lib: FormEngineLight.jar IridiumSendMail.jar activation.jar (just redownloaded the latest, recompiled my files) mail.jar (just redownloaded the latest, recompiled my files) the web.xml file contains the references to the FormEngineLight servlet. I double checked that its picking up its init params by doing a test program and comparing how it now grabs its params and that all worked fine. You can see what I have at: www.iridiumdesign.com/ FormEngineLight.java.txt IridiumSendMail.java.txt web.xml.txt The page that starts it all is contact.html Although I'm not an experienced programmer yet this stuff worked like a charm under JServ. Any advice would be appreciated. Thanks, Brad Siegfreid Iridiumdesign On Wednesday, December 27, 2000, at 10:30 AM, Kitching Simon wrote: > The stack-trace seems pretty clear to me - the > "sendIt" method of the IridiumSendMail class is > storing a null pointer into a hashtable. > > What you may find is that the IridiumSendMail > class is expecting to load a resource file from > somewhere, but not finding it because you > forgot to install it, or didn't install it in the > right place. > > Just a note on the location of the "mail.jar" > and "activation.jar" files - I think that the > correct place for these is where you > first had them, in the WEB-INF/lib > directory within your web application. > Placing jars in the classpath is > generally a bad idea with tomcat > (though quite a lot of tomcat users > don't seem to understand this; presumably > they are the same ones that would be > using global variables under c++ :-) > > regards, > > Simon > > -Original Message- > > From: Brad Siegfreid [SMTP:[EMAIL PROTECTED]] > > Sent: Wednesday, December 27, 2000 5:21 PM > > To: [EMAIL PROTECTED] > > Subject:Servlet error I can't seem to resolve > > > > I have a simple form handling servlet (FormEngineLight) that connects to a > > email class (IridiumSendMail) that have been working with another host > > under JServ 1.0b3. I moved to a new host with Tomcat 3.2 and also now have > > Tomcat 3.2 working on a local machine for testing. Now my servlet/class > > combo fails to work in either location. They require mail.jar and > > activation.jar, which are in the classpath (initially just in the context > > lib directory, now in the locations that load at boot). My apps are > > compiled agains Java 1.18 but are running on 1.2 for both local and > > hosted. > > > > The stackTrace I get from FormEngineLight (emailed back using the > > sun.net.smtp classes) is: > > > > java.lang.NullPointerException > > at java.util.Hashtable.put(Hashtable.java:381) > > at IridiumSendMail.sendIt(IridiumSendMail.java) > > at FormEngineLight.writeToIridiumSendMail(FormEngineLight.java) > > at FormEngineLight.sendConfirmation(FormEngineLight.java) > > at FormEngineLight.service(FormEngineLight.java) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > > at > > org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java:49 > > 9) > > at > > org.apache.tomcat.core.ContextManager.service(ContextManager.java:559) > > at > > org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(Htt > > pConnectionHandler.java:160) > > at > > org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:3 > > 38) > > at java.lang.Thread.run(Thread.java:479) > > > > Both of my files are in jars and reside in the lib directory. The > > FormEngineLight servlet is accessible and sends me the error shown above. > > Does the IridiumSendMail file have to be listed in the web.xml file even > > if its not a servlet. If so, do I list it as if it were a servlet? > > > > Thanks, > > Brad Siegfreid > > Iridiumdesign > >
RE: Servlet error I can't seem to resolve
The stack-trace seems pretty clear to me - the "sendIt" method of the IridiumSendMail class is storing a null pointer into a hashtable. What you may find is that the IridiumSendMail class is expecting to load a resource file from somewhere, but not finding it because you forgot to install it, or didn't install it in the right place. Just a note on the location of the "mail.jar" and "activation.jar" files - I think that the correct place for these is where you first had them, in the WEB-INF/lib directory within your web application. Placing jars in the classpath is generally a bad idea with tomcat (though quite a lot of tomcat users don't seem to understand this; presumably they are the same ones that would be using global variables under c++ :-) regards, Simon > -Original Message- > From: Brad Siegfreid [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, December 27, 2000 5:21 PM > To: [EMAIL PROTECTED] > Subject: Servlet error I can't seem to resolve > > I have a simple form handling servlet (FormEngineLight) that connects to a > email class (IridiumSendMail) that have been working with another host > under JServ 1.0b3. I moved to a new host with Tomcat 3.2 and also now have > Tomcat 3.2 working on a local machine for testing. Now my servlet/class > combo fails to work in either location. They require mail.jar and > activation.jar, which are in the classpath (initially just in the context > lib directory, now in the locations that load at boot). My apps are > compiled agains Java 1.18 but are running on 1.2 for both local and > hosted. > > The stackTrace I get from FormEngineLight (emailed back using the > sun.net.smtp classes) is: > > java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:381) > at IridiumSendMail.sendIt(IridiumSendMail.java) > at FormEngineLight.writeToIridiumSendMail(FormEngineLight.java) > at FormEngineLight.sendConfirmation(FormEngineLight.java) > at FormEngineLight.service(FormEngineLight.java) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java:49 > 9) > at > org.apache.tomcat.core.ContextManager.service(ContextManager.java:559) > at > org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(Htt > pConnectionHandler.java:160) > at > org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:3 > 38) > at java.lang.Thread.run(Thread.java:479) > > Both of my files are in jars and reside in the lib directory. The > FormEngineLight servlet is accessible and sends me the error shown above. > Does the IridiumSendMail file have to be listed in the web.xml file even > if its not a servlet. If so, do I list it as if it were a servlet? > > Thanks, > Brad Siegfreid > Iridiumdesign
RE: Servlet error I can't seem to resolve
If would seem that you are trying to put a null as either the key or value into a Hashtable. This is happening in the IridiumSendMail's sendIt method. Maybe a variable you expect to be in a session or application object are not set? Or some parameter file is not being loaded? Randy -Original Message- From: Brad Siegfreid [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 27, 2000 11:21 AM To: [EMAIL PROTECTED] Subject: Servlet error I can't seem to resolve I have a simple form handling servlet (FormEngineLight) that connects to a email class (IridiumSendMail) that have been working with another host under JServ 1.0b3. I moved to a new host with Tomcat 3.2 and also now have Tomcat 3.2 working on a local machine for testing. Now my servlet/class combo fails to work in either location. They require mail.jar and activation.jar, which are in the classpath (initially just in the context lib directory, now in the locations that load at boot). My apps are compiled agains Java 1.18 but are running on 1.2 for both local and hosted. The stackTrace I get from FormEngineLight (emailed back using the sun.net.smtp classes) is: java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:381) at IridiumSendMail.sendIt(IridiumSendMail.java) at FormEngineLight.writeToIridiumSendMail(FormEngineLight.java) at FormEngineLight.sendConfirmation(FormEngineLight.java) at FormEngineLight.service(FormEngineLight.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.handleRequest(ServletWrapper.java:499) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:559) at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC onnectionHandler.java:160) at org.apache.tomcat.service.TcpConnectionThread.run(SimpleTcpEndpoint.java:338 ) at java.lang.Thread.run(Thread.java:479) Both of my files are in jars and reside in the lib directory. The FormEngineLight servlet is accessible and sends me the error shown above. Does the IridiumSendMail file have to be listed in the web.xml file even if its not a servlet. If so, do I list it as if it were a servlet? Thanks, Brad Siegfreid Iridiumdesign
