Re: Exception starting filter Security Filter
Hi! In fact I was wrong in my last post. As I found out later, it did not work. I found a solution for my problem but I am not sure if it also applies to yours, Dan. Sorry for not sharing my knowledge until now, but it did not seem to interest anyone ;) During debugging I used a hacked version of the logging package and I somehow forgot to put back the original, so I tricked myself and believed it would work. But what I found out is, that in my version of Tomcat (4.0.3) common/lib is defined as endorsed in bin/setclasspath.bat (for the endorsed standards override mechanism see http://java.sun.com/j2se/1.4/docs/guide/standards/). This has the effect, that all jars in this directory are loaded by the bootstrap class loader (at least in J2SE 1.4). You can verify this by printing out the value of the java.endorsed.dirs system property. There you will find all your jars from common/lib. I solved the problem by switching to 4.1, where there is a separate endorsed directory in $CATALINA_HOME/common. All jars from common/lib are then normally loaded by the common class loader. I have no idea why the 4.0 version marks the common/lib directory as endorsed but in my opinon, it is a bug, since it undermines the expected class loader hierarchy. Furthermore the implementation of LogFactory is also buggy. When you look at the source code you can see that it does not take into account that Class.getClassLoader can return null. This is exactly what happens in your case, Dan. The class loader that loads LogFactory is the bootstrap class loader. Check where your commons-logging.jar is located. It is perhaps at some position where it should not be. There is a bug report for this exact issue in the Apache bug database, but interestingly it is marked RESOLVED. I should reopen that again. Regards, Volker Dan Payne wrote: Thanks for the response, Charlie, but it appears our problems are actuall different. I went ahead and tried the solutions prescribed to Volker but to no avail. It appears, by looking at the local_host log, that the package is being found, and the classes loaded no problem. The only thing that is different between my webapps where an exception is not throw and is thrown is that the ones that don't throw the exception are a part of the original tomcat install and the ones that do throw the exception reside within additional tomcat instances, using the CATALINA_BASE env. variable. -Dan -Original Message- From: Cox, Charlie [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 3:38 PM To: 'Tomcat Users List' Subject: RE: Exception starting filter Security Filter someone else had this problem a last week. http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg68531.html Charlie -Original Message- From: Dan Payne [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 1:56 PM To: [EMAIL PROTECTED] Subject: Exception starting filter Security Filter I'm using TC 4.0.4, j2sdk1.4.0_01 and the securityfilter from sourceforge.net, which is a pseudo container managed JDBC/MySQL security realm. it's all running on win2000. i've also upgraded my commons-logging to 1.0.2 to see if that helps, but to no avail (although it did change the stack trace). Here's the problem: it works fine when i deploy it in %CATALINA_HOME\webapps\ROOT, but if i try to deploy any app in a tomcat instance, for example %CATALINA_BASE\webapps\ROOT, an exception is thrown when I try to boot up the tomcat instance. It apears in the localhost log, whose excerpt follows: (additionaly, it may be a problem with the commons-logging. if anyone can tell, please let me know and i'll readress the issue with the appropriate party) Thanks, all. -Dan 2002-10-09 12:16:34 WebappLoader[/manager]: Deploying class repositories to work directory C:\contexts\sotx\work\Standalone\localhost\manager 2002-10-09 12:16:34 StandardManager[/manager]: Seeding random number generator class java.security.SecureRandom 2002-10-09 12:16:34 StandardManager[/manager]: Seeding of random number generator has been completed 2002-10-09 12:16:34 ContextConfig[/manager]: Added certificates - request attribute Valve 2002-10-09 12:16:34 ContextConfig[/manager]: Configured an authenticator for method BASIC 2002-10-09 12:16:35 StandardWrapper[/manager:default]: Loading container servlet default 2002-10-09 12:16:35 default: init 2002-10-09 12:16:35 StandardWrapper[/manager:invoker]: Loading container servlet invoker 2002-10-09 12:16:35 invoker: init 2002-10-09 12:16:35 jsp: init 2002-10-09 12:16:35 WebappLoader[]: Deploying class repositories to work directory C:\contexts\sotx\work\Standalone\localhost\_ 2002-10-09 12:16:35 WebappLoader[]: Deploy JAR /WEB-INF/lib/adrotate.jar to C:\contexts\sotx\webapps\ROOT\WEB-INF\lib\adrotate.jar 2002-10-09 12:16:35 WebappLoader[]: Deploy JAR /WEB-INF/lib/catalina.jar to C:\contexts\sotx\webapps\ROOT\WEB-INF\lib\catalina.jar 2002-10-09 12:16:36 WebappLoader[]: Deploy JAR
Re: Exception starting filter Security Filter
Cox, Charlie wrote: -Original Message- From: Volker Leidl [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 4:14 AM To: Tomcat Users List Subject: Re: Exception starting filter Security Filter Hi! In fact I was wrong in my last post. As I found out later, it did not work. I found a solution for my problem but I am not sure if it also applies to yours, Dan. Sorry for not sharing my knowledge until now, but it did not seem to interest anyone ;) Always post your solution! Unless it's user error. ;) But even then its good to know that it's resolved. I totally agree with you. Next time I will try to overcome my laziness ;) This way other users can look it up in the archives. In most cases you are not the only one with the problem, but maybe the first - especially when integrating other jakarta projects. Charlie Regards, Volker -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Repost: getClassLoader() returns null
Hi Charlie! This was also my first thought, but unfortunately this is not the case. I have just tried the same with a newly written test class, which would be very unlikely to be available to the bootstrap class loader. The remarkable thing is, that when I put the class in a jar in /common/lib, getClassLoader returns null., whereas putting it in /common/classes yields the correct class loader instance. If it had been loaded by the bootstrap classloader, null would have been returned in both cases. By the way, running the JVM with the -verbose:class switch explicitly shows me that the class is loaded from common/lib (or common/classes). Regards, Volker Cox, Charlie wrote: you don't also have the jar under /jre/lib/ext? It would find your jar there before looking in /common/lib; in which case it would be loaded by the jvm's bootstrap and could return null. see the tomcat classloader doc... Charlie -Original Message- From: Volker Leidl [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 12:24 PM To: Tomcat Users List Subject: Repost: getClassLoader() returns null Sorry for the repost, I don't mean to bother you, but can anyone confirm that getClassLoader() on a class loaded by the common class loader of tomcat (4.0.3), particularily from a jar in common/lib, returns null? I'm really puzzled... Thanks in advance, Volker. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Repost: getClassLoader() returns null
This works, in fact! I could swear I've tried that yesterday, and it threw me tons of NoClassDefFoundErrors, but anyway now it works. Thanks a lot for your help Charlie. Anyway I'm still not quite confident. I still have no idea why I get null from getClassLoader() calls on classes in common/lib. Could you Charlie, or perhaps someone else, confirm that this is generally the case, not only because of some faulty configuration in my environment Im not aware of? If this is really the normal behavior I wonder how I can get a class to return null on getClassLoader(), besides exposing it to the bootstrap class loader. Thanks and regards, Volker Cox, Charlie wrote: well, I don't know why that is happening, but it does appear that you can unpack your jar to get it to work. While certainly not ideal, it looks like it may work. Charlie -Original Message- From: Volker Leidl [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 4:02 AM To: Tomcat Users List Subject: Re: Repost: getClassLoader() returns null Hi Charlie! This was also my first thought, but unfortunately this is not the case. I have just tried the same with a newly written test class, which would be very unlikely to be available to the bootstrap class loader. The remarkable thing is, that when I put the class in a jar in /common/lib, getClassLoader returns null., whereas putting it in /common/classes yields the correct class loader instance. If it had been loaded by the bootstrap classloader, null would have been returned in both cases. By the way, running the JVM with the -verbose:class switch explicitly shows me that the class is loaded from common/lib (or common/classes). Regards, Volker Cox, Charlie wrote: you don't also have the jar under /jre/lib/ext? It would find your jar there before looking in /common/lib; in which case it would be loaded by the jvm's bootstrap and could return null. see the tomcat classloader doc... Charlie -Original Message- From: Volker Leidl [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 12:24 PM To: Tomcat Users List Subject: Repost: getClassLoader() returns null Sorry for the repost, I don't mean to bother you, but can anyone confirm that getClassLoader() on a class loaded by the common class loader of tomcat (4.0.3), particularily from a jar in common/lib, returns null? I'm really puzzled... Thanks in advance, Volker. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Repost: getClassLoader() returns null
Sorry for the repost, I don't mean to bother you, but can anyone confirm that getClassLoader() on a class loaded by the common class loader of tomcat (4.0.3), particularily from a jar in common/lib, returns null? I'm really puzzled... Thanks in advance, Volker. ---BeginMessage--- Hi! I just encountered a problem when using the commons-logging package together with Tomcat 4.0.3. When putting commons-loggin.jar (1.0.2) into the $TOMCAT_HOME/common/lib, in order to be available for the server classes as well as for all web apps, a NullPointerException is thrown when trying to retrieve a Log instance. This Exception can be tracked down to some call to LogFactory.class.getClassLoader(), which returns null. Ok, I read the javadocs of java.lang.Class.getClassLoader(), which says that this method may return null, if the class is loaded by the bootstrap class loader, but the LogFactory class is loaded by the common class loader of Tomcat, so I don't quite understand, why null is returned. Is this the expected behaviour? If yes I would really like to know how Tomcat accompishes this. What's even more funny is that a class loaded from $TOMCAT_HOME/common/classes does return the proper class loader instance. Best regards, Volker. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ---End Message--- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
getClassLoader() returns null
Hi! I just encountered a problem when using the commons-logging package together with Tomcat 4.0.3. When putting commons-loggin.jar (1.0.2) into the $TOMCAT_HOME/common/lib, in order to be available for the server classes as well as for all web apps, a NullPointerException is thrown when trying to retrieve a Log instance. This Exception can be tracked down to some call to LogFactory.class.getClassLoader(), which returns null. Ok, I read the javadocs of java.lang.Class.getClassLoader(), which says that this method may return null, if the class is loaded by the bootstrap class loader, but the LogFactory class is loaded by the common class loader of Tomcat, so I don't quite understand, why null is returned. Is this the expected behaviour? If yes I would really like to know how Tomcat accompishes this. What's even more funny is that a class loaded from $TOMCAT_HOME/common/classes does return the proper class loader instance. Best regards, Volker. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: SERVLET CACHING PROBLEM IN TOMCAT- SNODX
Add reloadable=true to your webb apps context tag in server.xml. Volker. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 9:01 AM To: [EMAIL PROTECTED] Subject: SERVLET CACHING PROBLEM IN TOMCAT- SNODX Greetings, I am facing a servlet caching problem in Tomcat. I create a servlet .java file compile it and put it in the webapps folder of the TOMCAT_HOME folder. I start the Tomcat server and invoke the servlet via http://localhost:TomCat port no/servlet/Servlet name in Netscpe. It gets invoked. All is well uptil now. Problem comes when I make changes in the .java file, recompile it, place it in the same TOMCAT_HOME/webapps folder, and again invoke it in Netscape via http://localhost:Tomcat Port No/servlet/Servlet name. The ALTERED sevlet does NOT get invoked, the old servlet is getting invoked. This must mean Tomcat is caching its sevlets somewhere, and it is picking up the servlets from that cache, ignoring the actual .class servlet file in the webapps folder. Maybe the cache gets cleared everytime Tomcat restarts, but I find it inconvenient to frequently restart Tomcat. So what is the one time solution to this servlet caching problem, WITHOUT HAVING TO REGULARLY RESTART TOMCAT? Will a startup servlet running continuosly alongwith Tomcat, performing the servlet cache cleaning operation- regularly say every 10 seconds- solve the problem? If so then what should be the coding of the servlet? Should I use classes of the java.lang.ref package- PhantomReference e.t.c- ( http://java.sun.com/products/jdk/1.2/docs/api/java/lang/ref/packag e-summary.html )? Or can some changes in server.xml do the trick? I have Apache 1.3.19, Tomcat 3.23 installed, configured and running on RedHat Linux 6.2 platform. Waiting for an early response. Thanks in advance. SNODX -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: SERVLET CACHING PROBLEM IN TOMCAT- SNODX
It is reloadable (all lowercase). At least it works in my environment. If it still doesn't work, make sure that the system class loader has no access to your servlet (i.e. no CLASSPATH variable entry to the classes dir, etc.) so that the appropriate tomcat class loader handles these files. Regards, Volker. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 12:29 PM To: [EMAIL PROTECTED] Subject: RE: SERVLET CACHING PROBLEM IN TOMCAT- SNODX Greetings, Thanks for the response. But is it reloadable (all in lowercase) OR reLoadable with the first L in uppercase? SNODX -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Wrong line number in stack trace
Hi all! I repeatedly run into the problem that the stack trace of an exception thrown within a jsp page does not show the appropriate line number. For instance the output of the stack trace says: java.lang.Exception at help._0002fhelp_0002fabout_0005fincl_0002ejspabout_0005fincl_jsp_2._jspServi ce(_0002fhelp_0002fabout_0005fincl_0002ejspabout_0005fincl_jsp_2.java:71) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) Looking at the generated class file (which i found in a subdirectory of $(tomcat_home)/work) 71 is definitely not the correct line where the exception was thrown. In other cases the given line number even exceeds the end of the file. Of cource I should try to keep as much code as possible outside my jsps. But still this problem makes it rather annoying to find the source of an exception. Thanks for you help, Volker. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Wrong line number in stack trace
Sorry, i forgot about that: TC 3.2.3 -Original Message- From: Arnaud Héritier [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 29, 2001 11:20 AM To: 'Tomcat Users List' Subject: RE: Wrong line number in stack trace Which TC release -Message d'origine- De: Ralph Einfeldt [SMTP:[EMAIL PROTECTED]] Date: jeudi 29 novembre 2001 11:17 À: Tomcat Users List Objet: AW: Wrong line number in stack trace Which JDK do you use ? Never experienced something like that with either IBM's JDK or Suns JDK. Was 'class file' just a typo? (It should be the source you looked at) -Ursprüngliche Nachricht- Von: Volker Leidl [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 29. November 2001 10:45 An: Tomcat Users List Betreff: Wrong line number in stack trace Hi all! I repeatedly run into the problem that the stack trace of an exception thrown within a jsp page does not show the appropriate line number. For instance the output of the stack trace says: java.lang.Exception at help._0002fhelp_0002fabout_0005fincl_0002ejspabout_0005fincl_j sp_2._jspServi ce(_0002fhelp_0002fabout_0005fincl_0002ejspabout_0005fincl_jsp _2.java:71) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) Looking at the generated class file (which i found in a subdirectory of $(tomcat_home)/work) 71 is definitely not the correct line where the exception was thrown. In other cases the given line number even exceeds the end of the file. Of cource I should try to keep as much code as possible outside my jsps. But still this problem makes it rather annoying to find the source of an exception. Thanks for you help, Volker. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Wrong line number in stack trace
I'm using Suns jdk 1.3.1 running on Windows NT 4.0. You are right Ralph, I used the wrong vocabulary. In fact I ment source file, since I'm not that good in reading byte code ;). Volker. -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 29, 2001 11:17 AM To: Tomcat Users List Subject: AW: Wrong line number in stack trace Which JDK do you use ? Never experienced something like that with either IBM's JDK or Suns JDK. Was 'class file' just a typo? (It should be the source you looked at) -Ursprüngliche Nachricht- Von: Volker Leidl [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 29. November 2001 10:45 An: Tomcat Users List Betreff: Wrong line number in stack trace Hi all! I repeatedly run into the problem that the stack trace of an exception thrown within a jsp page does not show the appropriate line number. For instance the output of the stack trace says: java.lang.Exception at help._0002fhelp_0002fabout_0005fincl_0002ejspabout_0005fincl_j sp_2._jspServi ce(_0002fhelp_0002fabout_0005fincl_0002ejspabout_0005fincl_jsp _2.java:71) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) Looking at the generated class file (which i found in a subdirectory of $(tomcat_home)/work) 71 is definitely not the correct line where the exception was thrown. In other cases the given line number even exceeds the end of the file. Of cource I should try to keep as much code as possible outside my jsps. But still this problem makes it rather annoying to find the source of an exception. Thanks for you help, Volker. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Wrong line number in stack trace
Thanks a lot! This is exactly the problem. I also used EditPlus to view the code. Switching to Unix file format in EditPlus solves the problem. But obviously Tomcat compiles jsps into servlets containing an inconsisten line break format namely \n\r and solely \n mixed in one document. I can't imagine what's the use of that behaviour. For me it seems like a bug. Anyway, thanks for your help, Volker. -Original Message- From: Shanmugam K [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 29, 2001 12:52 PM To: Tomcat Users List Subject: Re: Wrong line number in stack trace Mr Volker Leidl, I worked on the problem that you posted. I feel that I have found out the cause of the problem that you are facing. I worked on a sample jsp file to get to the root of the problem. What is happening is ? The source file _0002fhelp_0002fabout_0005fincl_0002ejspabout_0005fincl_jsp_2.java has thrown an exception at the line 71 itself (This is very much correct) When you are viewing the source file using some editor, a new line is shown only on occurance of '\n' character by the error message displayer. where as while displaying the line number of the error occurance, there is not only '\n' character that is treated as new line character but also there is some other character(which my editor is not treating it as new line character ) that is taken into account as a new line character. In my editor (I use edit Plus editor ) I could find out that this character was displayed as Square pattern When i added the number of occurances of this character to line number (as displayed by my editor) I got the exact line number where the exception was being thrown. I think this should solve your problem. If you still have problems in understanding this concept please reply, I will try of work on it in a more detail way. regards shanmugam k. Volker Leidl wrote: Hi all! I repeatedly run into the problem that the stack trace of an exception thrown within a jsp page does not show the appropriate line number. For instance the output of the stack trace says: java.lang.Exception at help._0002fhelp_0002fabout_0005fincl_0002ejspabout_0005fincl_jsp_2 ._jspServi ce(_0002fhelp_0002fabout_0005fincl_0002ejspabout_0005fincl_jsp_2.java:71) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) Looking at the generated class file (which i found in a subdirectory of $(tomcat_home)/work) 71 is definitely not the correct line where the exception was thrown. In other cases the given line number even exceeds the end of the file. Of cource I should try to keep as much code as possible outside my jsps. But still this problem makes it rather annoying to find the source of an exception. Thanks for you help, Volker. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Wrong line number in stack trace
I don't think this is correct. I just verified what you suggested, but my source file does not contain any single linefeeds (or carriage returns) only CRLF pairs. Especially all the compiled jsps contain the following line: pageContext = _jspxFactory.getPageContext(this, request, response, , true, 8192, true); with a single linefeed after the third parameter (followed by a view tabs). This is definitely not from my jsp. -Original Message- From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 29, 2001 2:00 PM To: Tomcat Users List Subject: AW: Wrong line number in stack trace AFAIK tomcat only output those characters that are in your JSP. It is not introducing any line feeds on it's own. Is it possible, that the files have been edited (at least once) with different settings for the editor, or under linux ? -Ursprüngliche Nachricht- Von: Volker Leidl [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 29. November 2001 13:52 An: Tomcat Users List; [EMAIL PROTECTED] Betreff: RE: Wrong line number in stack trace Thanks a lot! This is exactly the problem. I also used EditPlus to view the code. Switching to Unix file format in EditPlus solves the problem. But obviously Tomcat compiles jsps into servlets containing an inconsisten line break format namely \n\r and solely \n mixed in one document. I can't imagine what's the use of that behaviour. For me it seems like a bug. Anyway, thanks for your help, Volker. -Original Message- From: Shanmugam K [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 29, 2001 12:52 PM To: Tomcat Users List Subject: Re: Wrong line number in stack trace Mr Volker Leidl, I worked on the problem that you posted. I feel that I have found out the cause of the problem that you are facing. I worked on a sample jsp file to get to the root of the problem. What is happening is ? The source file _0002fhelp_0002fabout_0005fincl_0002ejspabout_0005fincl_jsp_2.java has thrown an exception at the line 71 itself (This is very much correct) When you are viewing the source file using some editor, a new line is shown only on occurance of '\n' character by the error message displayer. where as while displaying the line number of the error occurance, there is not only '\n' character that is treated as new line character but also there is some other character(which my editor is not treating it as new line character ) that is taken into account as a new line character. In my editor (I use edit Plus editor ) I could find out that this character was displayed as Square pattern When i added the number of occurances of this character to line number (as displayed by my editor) I got the exact line number where the exception was being thrown. I think this should solve your problem. If you still have problems in understanding this concept please reply, I will try of work on it in a more detail way. regards shanmugam k. Volker Leidl wrote: Hi all! I repeatedly run into the problem that the stack trace of an exception thrown within a jsp page does not show the appropriate line number. For instance the output of the stack trace says: java.lang.Exception at help._0002fhelp_0002fabout_0005fincl_0002ejspabout_0005fincl_jsp_2 ._jspServi ce(_0002fhelp_0002fabout_0005fincl_0002ejspabout_0005fincl_jsp _2.java:71) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) Looking at the generated class file (which i found in a subdirectory of $(tomcat_home)/work) 71 is definitely not the correct line where the exception was thrown. In other cases the given line number even exceeds the end of the file. Of cource I should try to keep as much code as possible outside my jsps. But still this problem makes it rather annoying to find the source of an exception. Thanks for you help, Volker. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED
