RE: mod_jk problem

2004-02-03 Thread Guy Rouillier
Lukas Larsson wrote:
> I already put the Include statement in httpd.conf, and then
> put JkMount in mod_jk.conf. But it still doesn't work. Is
> there anything I have to do in server.xml to make it work.
> I've added two lines  debug="0"> #this line is above  className="org.apache.ajp.tomcat4.config.ApacheConfig"
> modJk="/opt/apache/modules/mod_jk.so" /> #this line I added
> 
> and
>  unpackWARs="true" autoDeploy="true"> #this line is above
>  append="true" forwardAll="false"
> modJk="/opt/apache/modules/mod_jk.so" /> #the line i added
> 
> and that's all the configurations I did id you include adding
> the include statement in httpd.conf. Is there anything else I
> have to do? There should be as I still can't get tomcat to
> format jsp files.

Lukas, got busy, didn't mean to leave you in the lurch.  Where do you
stand?  I deleted the rest of the message because this is getting much
too involved - it shouldn't be that hard.  I didn't have to add any kind
of listener statements to server.xml.  All I did there was (1) make sure
the port assignments are unique (only a concern if you are using more
than one instance) and (2) set up a context properly.  I would suggest
you start with a completely fresh Tomcat.  Put your test.jsp into the
existing contexts and verify that works.  (I think you said you already
did that.)  Please respond if you are still having difficulties with
this, and I'll tell you the very basic setup I used to get started.

> 
> ./Lukas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: mod_jk problem

2004-01-28 Thread Guy Rouillier
garaz_user wrote:
> Hello,
> 
> I put the test.jsp in ROOT folder, and I put JKMount in
> the mod_jk.conf file, which I probably shound't do but
> all is working now (except apache integration :'( ) so
> I'm sataisfied with the tomcat setup. Now if I just
> could get it to intergrate with apache it would make my
> day. Becuase port 8080 is blocked by my firewall and I
> can't open that port until atleast a week from now. So
> right now I'm using links to do all my jsp test ^^.

In order to integrate with Apache, you've got to get the JkMount
commands into Apache's httpd.conf.  There are two ways to do this:

(1) Just type them in directly
(2) Put them in some file in the Tomcat directory, then in httpd.conf,
add an include directive like this:

Include TOMCAT_HOME/conf/auto/mod_jk.conf

Just putting the JkMount's in mod_jk.conf, without putting the include
directive in httpd.conf, won't accomplish anything.  Apache is the one
who needs the JkMount command, not Tomcat.

> 
> ./Lukas
> 
> 
>  Guy Rouillier <[EMAIL PROTECTED]>:
> 
>> Lukas Larsson wrote:
>>> Thx for the replies. I'm using 4.1.29. I haven't played anything
>>> with the structure at all. The strange thing is that
>>> when I put the test.jsp file in the examples folder in webapps I can
>>> display it and it works like a charm,
> but if I
>>> put it anywhere else it wont work. Putting it in ROOT does
>>> not help this at all.
>>> 
>>> So what permissions do I need to have on the file?
>>> 
>>> this is my web.xml file
>>> 
>>> 
>>> >> Application 2.3//EN"
> "http://java.sun.com/dtd/web-app_2_3.dtd";>
>>>Welcome to Tomcat  
>>>   Welcome to Tomcat
>>>   
>>> 
>>> 
>>> I haven't changed anything in it.
>>> 
>>> Adding JkMount /*.jsp aj13 to my mod_jk.conf had the wanted
>>> effect. I can now see
> http://localhost:8080/test.jsp . But
>>> there's still no formatation on test.jsp on port 80 :(, atleast now
>>> we know that tomcat is working properly.
>>> 
>>> Guy Rouillier said before that I have to make sure that 'tomcat is
>>> set up properly by going directly to it
> for the
>>> JSP page, bypassing Apache', how would I check this? And how
>>> do I set it up?
>> 
>> You accomplished that when you went to :8080.  So now you know
>> Tomcat is working.  Where did you put test.jsp when you successfully
>> viewed it at http://localhost:8080/test.jsp?  If you have an
>> unaltered Tomcat installation, you would have had to place test.jsp
>> in the ROOT directory. 
>> 
>> How are you including those JkMount's into Apache's httpd.conf?
>> 
>>> 
>>> ./Lukas
>>> 
>>> - Original Message -
>>> From: "Jeff Tulley" <[EMAIL PROTECTED]>
>>> To: <[EMAIL PROTECTED]>
>>> Sent: Monday, January 26, 2004 11:25 PM
>>> Subject: Re: mod_jk problem
>>> 
>>> 
>>>> Lukas,
>>>>I haven't been following this thread too closelyso maybe
>>>> I've missed some of your earlier explanation... If you are going
>>>> through port 8080, there is no mod_jk or mod_jk2 involved, and the
>>>> problem is probably elsewhere - for instance maybe your web
>>>> application is not set up properly(wrong directory structure?), or
>>>> there are file permission problems on your directories or your
>>>> web.xml file.  I have a coworker who had these type of file
>>>> permission problems twice in the last few weeks, and it was not
>>>> immediately obvious that this was the problem.  Or maybe your
>>>> web.xml is not valid. 
>>>> 
>>>> When you go back to using mod_jk, be aware that the command in
>>>> apache for mod_jk is more like:
>>>> 
>>>> JkMount /*.jsp ajp13
>>>> 
>>>> You do not embed this in a location tag necessarily.
>>>> 
>>>> But get things working through port 8080 first before tackling
>>>> Apache integration.  Like you said you just want to get started
>>>> with JSP without the battle. 
>>>> 
>>>> 
>>>>>>> [EMAIL PROTECTED] 1/26/04 2:35:24 PM >>>
>>>> Ok, now I'm really getting confused, I put the test.jsp file in
>>>> $CATALINE_HOME/webapps/test.jsp and when doing
>>>> http://localhost:8080/test.jsp in li

RE: mod_jk problem

2004-01-27 Thread Guy Rouillier
Lukas Larsson wrote:
> Thx for the replies. I'm using 4.1.29. I haven't played
> anything with the structure at all. The strange thing is that
> when I put the test.jsp file in the examples folder in
> webapps I can display it and it works like a charm, but if I
> put it anywhere else it wont work. Putting it in ROOT does
> not help this at all.
> 
> So what permissions do I need to have on the file?
> 
> this is my web.xml file
> 
> 
>  Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd";>
>Welcome to Tomcat
>   
>  Welcome to Tomcat
>   
> 
> 
> I haven't changed anything in it.
> 
> Adding JkMount /*.jsp aj13 to my mod_jk.conf had the wanted
> effect. I can now see http://localhost:8080/test.jsp . But
> there's still no formatation on test.jsp on port 80 :(,
> atleast now we know that tomcat is working properly.
> 
> Guy Rouillier said before that I have to make sure that
> 'tomcat is set up properly by going directly to it for the
> JSP page, bypassing Apache', how would I check this? And how
> do I set it up?

You accomplished that when you went to :8080.  So now you know Tomcat is
working.  Where did you put test.jsp when you successfully viewed it at
http://localhost:8080/test.jsp?  If you have an unaltered Tomcat
installation, you would have had to place test.jsp in the ROOT
directory.

How are you including those JkMount's into Apache's httpd.conf?

> 
> ./Lukas
> 
> - Original Message -
> From: "Jeff Tulley" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, January 26, 2004 11:25 PM
> Subject: Re: mod_jk problem
> 
> 
>> Lukas,
>>I haven't been following this thread too closelyso maybe I've
>> missed some of your earlier explanation... If you are going through
>> port 8080, there is no mod_jk or mod_jk2 involved, and the problem is
>> probably elsewhere - for instance maybe your web application is not
>> set up properly(wrong directory structure?), or there are file
>> permission problems on your directories or your web.xml file.  I have
>> a coworker who had these type of file permission problems twice in
>> the last few weeks, and it was not immediately obvious that this was
>> the problem.  Or maybe your web.xml is not valid.
>> 
>> When you go back to using mod_jk, be aware that the command in
>> apache for mod_jk is more like: 
>> 
>> JkMount /*.jsp ajp13
>> 
>> You do not embed this in a location tag necessarily.
>> 
>> But get things working through port 8080 first before tackling Apache
>> integration.  Like you said you just want to get started with JSP
>> without the battle. 
>> 
>> 
>>>>> [EMAIL PROTECTED] 1/26/04 2:35:24 PM >>>
>> Ok, now I'm really getting confused, I put the test.jsp file in
>> $CATALINE_HOME/webapps/test.jsp and when doing
>> http://localhost:8080/test.jsp in links (can't open my 8080 port
>> yet...) I get a file cannot be found message, but when I look at the
>> example folder they show as they should. Anyone who knows what I'm
>> doing wrong? 
>> 
>> Also when adding
>> 
>> 
>> JkUriSet worker ajp13:localhost:8009
>> 
>> 
>> to my http.conf file I got an error message that said that apache
>> couldn't recongnixe JkUriSet. Is that because JkUriSet is only
>> availabel in jk2 or??? 
>> 
>> ./Lukas
>> 
>> - Original Message -
>> From: "Guy Rouillier" <[EMAIL PROTECTED]>
>> To: "Tomcat Users List" <[EMAIL PROTECTED]>
>> Sent: Monday, January 26, 2004 9:39 PM
>> Subject: RE: mod_jk problem
>> 
>> 
>> Lukas Larsson wrote:
>>> Thx for the reply. I folloes your second link and found this site
>>> (http://johnturner.com/howto/apache2-tomcat4127-jk-rh9-howto.h
>>> tml) on how to configure mod_jk but I still get the same problem.
>>> Apache says that it is working with mod_jk, but it does not
>>> translate *.jsp pages (see
> http://garazdawi.homeftp.net/test.jsp for
>>> an > example
> of what I mean). Can someone please tell me what I'm
>>> doing wrong. I would really want to get started with jsp without
>>> having to battle with mod_jk.
>> 
>> Make sure your Tomcat is set up properly by going directly to it for
>> the JSP page, bypassing Apache, e.g.,
>> http://garazdawi.homeftp.net:8080/test.jsp (assuming you left Tomcat
>> on the default HTTP port.)  If that doesn't work, then the problem
>> is in Tomcat configuration not in mod_jk.
>> 
>> Jeff Tulley  ([EMAIL PROTECTED])
>> (801)861-5322
>> Novell, Inc., The Leading Provider of Net Business Solutions
>> http://www.novell.com 
>> 
>> 
> -
>> 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: Classloading issue: common/lib/servlet-api.jar

2004-01-27 Thread Guy Rouillier
Jeanfrancois Arcand wrote:
> Can you post the entire stack trace? This exception usually
> occurs when
> a doPrivileged block is missing (when -security). I will try to
> reproduce the problem since it is a bug in Tomcat.

Jeanfrancois, I'll include the entire stack trace at the bottom on this
message.  Before spending time on this, let me get ahold of the jars
this page uses and recompile them with the Tomcat 5 servlet jars.  Yoav
gave me the impression that version differences between compile and run
time can cause this error.  If that doesn't make this go away, I'll
report back again.  Thanks for your offer.

> 
> Do you have the same exception if you don't turn security on?
> What your
> servlet is trying to do?

Yes, I see the same thing without -security.  Not clear on why it would
still be using a SecureClassloader if I'm not running with -security.

> 
> Thanks
> 
> -- Jeanfrancois
> 
> Guy Rouillier wrote:
> 
>> I found this message in the archives from Michael Duffy that is
>> relevant to my question: 
>> 
>> 
>> 
>> When Tomcat starts, it assumes the CLASSPATH for your
>> Web app consists of:
>> 
>> (1) The rt.jar, of course,
>> (2) All the JARs in TOMCAT_HOME/common/lib, which are
>> visible to all apps,
>> (3) All the JARs in the TOMCAT_HOME/server/lib, which
>> are visible only to Tomcat,
>> (4) All the JARs in your WEB-INF/lib, which are
>> visible only to your app,
>> (5) All the .class files in your WEB-INF/classes,
>> which are visible only to your app.
>> 
>> That's it.
>> 
>> If your Web app needs a JAR, put it in the WEB-INF/lib
>> and you should be all set. - MOD
>> <<
>> 
>> My page (which is running with a security manager, i.e, -security) is
>> getting the following error (partial stack trace):
>> 
>> java.lang.NoClassDefFoundError:
>> javax/servlet/http/HttpSessionBindingListener
>>at java.lang.ClassLoader.defineClass0(Native Method)
>>at java.lang.ClassLoader.defineClass(ClassLoader.java:537)   
>> at java.security.SecureClassLoader.defineClass(SecureClassLoader
>> .java:123 ) 
>> 
>> I found that common/lib/servlet-api.jar contains this class, and if I
>> manually add it to the classpath (by editing catalina.sh), my page
>> will then work.  According to the note above, all jars on common/lib
>> should be automatically available to my pages.  I haven't touched
>> catalina.properties. 
>> 
>> Any idea why this jar is not being picked up automatically out of
>> common/lib?  Thanks. 

Stack trace

java.lang.NoClassDefFoundError:
javax/servlet/http/HttpSessionBindingListener at
java.lang.ClassLoader.defineClass0(Native Method) at
java.lang.ClassLoader.defineClass(ClassLoader.java:537) at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:251) at
java.net.URLClassLoader.access$100(URLClassLoader.java:55) at
java.net.URLClassLoader$1.run(URLClassLoader.java:194) at
java.security.AccessController.doPrivileged(Native Method) at
java.net.URLClassLoader.findClass(URLClassLoader.java:187) at
java.lang.ClassLoader.loadClass(ClassLoader.java:289) at
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at
java.lang.ClassLoader.loadClass(ClassLoader.java:235) at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader
.java:1296) at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader
.java:1230) at
org.apache.jasper.servlet.JasperLoader$1.run(JasperLoader.java:176) at
java.security.AccessController.doPrivileged(Native Method) at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:174)
at
org.apache.jasper.servlet.JasperLoader.loadClass(JasperLoader.java:110)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at
org.apache.jsp.scc.myservices.html.mpm_jsp._jspService(mpm_jsp.java:841)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:133)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:311) at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39) at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:284)
at java.security.Acces

RE: Classloading issue: common/lib/servlet-api.jar

2004-01-27 Thread Guy Rouillier
Shapira, Yoav wrote:
> Howdy,
> 
>> ClassNotFoundException - class you explicitly asked for is not found
>> NoClassDefFoundError - a class required by your class (through a new,
>> e.g.) was available at compile time but cannot be found now.
> 
> I know what the errors mean, thanks ;)  The most common cause
> for the latter is version skew: a class was found with the
> same name but not the same interfaces as the class you had at
> compile-time.  For example, a version of
> javax.servlet.http.HttpServletRequest from a servlet
> specification 2.3 jar was found on a tomcat 5 classpath.

The jars that this page uses were definitely compiled with an earlier
version of servlet.jar than Tomcat 5 contains.  That would produce
NoClassDefFoundError?  Why would the error go away if I explicitly
include the subject jar in the classpath?  Sorry, I have read all the
JBoss classloading docs, but have not yet read the Tomcat classloader
ref you supplied - I will.

> 
>> I have no servlet jars other than the ones Tomcat 5.0.18 supplies. 
>> I do have jboss-j2ee.jar in my classpath, and the code will not
>> compile without it: "javax\ejb\CreateException.class not found".  I
>> moved the 
> 
> Are you running tomcat standalone or JBoss with embedded
> tomcat?  

Standalone, though JBoss is running on the same box in a different JVM.

> Does the jboss-j2ee.jar have the servlet classes in it?

No.

Yoav, thanks for your time.  I don't want to ask for any more of it
until I can get the chance to recompile the jars with the same servlet
jars Tomcat 5 is using (and I've read the classloader docs.)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Classloading issue: common/lib/servlet-api.jar

2004-01-27 Thread Guy Rouillier
Shapira, Yoav wrote:
> Howdy,
> - NoClassDefFoundError is different from
> ClassNotFoundException.  Make sure you understand the
> difference.  Then make sure you remove extra copies of the
> servlet APIs from the classpath, specifically if you have
> j2ee.jar or servlet.jar somewhere.

Yoav, thanks for the reply.

ClassNotFoundException - class you explicitly asked for is not found 
NoClassDefFoundError - a class required by your class (through a new,
e.g.) was available at compile time but cannot be found now.

I have no servlet jars other than the ones Tomcat 5.0.18 supplies.  I do
have jboss-j2ee.jar in my classpath, and the code will not compile
without it: "javax\ejb\CreateException.class not found".  I moved the
JBoss jars I put in Tomcat's classpath to a directory outside the JBoss
directory, just to make sure it wasn't picking up classes from that
directory I didn't know about (turns out it was, the JBoss security
classes.)  I think the problem is probably in one of the classes that
reside in jars we build and that are invoked on this page.

At any rate, I can add the subject jar to the Tomcat classpath
explicitly - that is a good-enough solution for now.

> 
> - In addition to Senor Duffy's post, read the Classloader
> How-To in the tomcat documentation.
> 
> Yoav Shapira
> Millennium ChemInformatics
> 
> 
>> -Original Message-
>> From: Guy Rouillier [mailto:[EMAIL PROTECTED]
>> Sent: Monday, January 26, 2004 4:17 PM
>> To: Tomcat Users List
>> Subject: Classloading issue: common/lib/servlet-api.jar
>> 
>> I found this message in the archives from Michael Duffy that is
>> relevant to my question: 
>> 
>>>> 
>> When Tomcat starts, it assumes the CLASSPATH for your
>> Web app consists of:
>> 
>> (1) The rt.jar, of course,
>> (2) All the JARs in TOMCAT_HOME/common/lib, which are
>> visible to all apps,
>> (3) All the JARs in the TOMCAT_HOME/server/lib, which
>> are visible only to Tomcat,
>> (4) All the JARs in your WEB-INF/lib, which are
>> visible only to your app,
>> (5) All the .class files in your WEB-INF/classes,
>> which are visible only to your app.
>> 
>> That's it.
>> 
>> If your Web app needs a JAR, put it in the WEB-INF/lib
>> and you should be all set. - MOD
>> <<
>> 
>> My page (which is running with a security manager, i.e, -security) is
>> getting the following error (partial stack trace):
>> 
>> java.lang.NoClassDefFoundError:
>> javax/servlet/http/HttpSessionBindingListener
>>at java.lang.ClassLoader.defineClass0(Native Method)
>>at java.lang.ClassLoader.defineClass(ClassLoader.java:537)   
>> at java.security.SecureClassLoader.defineClass(SecureClassLoader
>> .java:123 ) 
>> 
>> I found that common/lib/servlet-api.jar contains this class, and if I
>> manually add it to the classpath (by editing catalina.sh), my page
>> will then work.  According to the note above, all jars on common/lib
>> should be automatically available to my pages.  I haven't touched
>> catalina.properties. 
>> 
>> Any idea why this jar is not being picked up automatically out of
>> common/lib?  Thanks. 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: mod_jk problem

2004-01-26 Thread Guy Rouillier
Lukas Larsson wrote:
> Ok, now I'm really getting confused, I put the test.jsp file
> in $CATALINE_HOME/webapps/test.jsp and when doing
> http://localhost:8080/test.jsp in links (can't open my 8080
> port yet...) I get a file cannot be found message, but when I
> look at the example folder they show as they should. Anyone
> who knows what I'm doing wrong?

$CATALINE_HOME/webapps/ is not your default context location.  If you
haven't changed anything, the default context is here (this is Tomcat 5,
sorry, I've forgotten which version you are using):

  

> 
> Also when adding
> 
> 
> JkUriSet worker ajp13:localhost:8009
> 
> 
> to my http.conf file I got an error message that said that
> apache couldn't recongnixe JkUriSet. Is that because JkUriSet
> is only availabel in jk2 or???

Yes, this syntax is for jk2.  For jk, use JkMount.

> 
> ./Lukas
> 
> - Original Message -
> From: "Guy Rouillier" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: Monday, January 26, 2004 9:39 PM
> Subject: RE: mod_jk problem
> 
> 
> Lukas Larsson wrote:
>> Thx for the reply. I folloes your second link and found this site
>> (http://johnturner.com/howto/apache2-tomcat4127-jk-rh9-howto.h
>> tml) on how to configure mod_jk but I still get the same problem.
>> Apache says that it is working with mod_jk, but it does not translate
>> *.jsp pages (see http://garazdawi.homeftp.net/test.jsp for an >
>> example of what I mean). Can someone please tell me what I'm doing
>> wrong. I would really want to get started with jsp without having to
>> battle with mod_jk.
> 
> Make sure your Tomcat is set up properly by going directly to
> it for the JSP page, bypassing Apache, e.g.,
> http://garazdawi.homeftp.net:8080/test.jsp (assuming you left
> Tomcat on the default HTTP port.)  If that doesn't work, then
> the problem is in Tomcat configuration not in mod_jk.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Classloading issue: common/lib/servlet-api.jar

2004-01-26 Thread Guy Rouillier
I found this message in the archives from Michael Duffy that is relevant
to my question:

>>
When Tomcat starts, it assumes the CLASSPATH for your
Web app consists of: 

(1) The rt.jar, of course,
(2) All the JARs in TOMCAT_HOME/common/lib, which are
visible to all apps,
(3) All the JARs in the TOMCAT_HOME/server/lib, which
are visible only to Tomcat,
(4) All the JARs in your WEB-INF/lib, which are
visible only to your app,
(5) All the .class files in your WEB-INF/classes,
which are visible only to your app.

That's it.

If your Web app needs a JAR, put it in the WEB-INF/lib
and you should be all set. - MOD
<<

My page (which is running with a security manager, i.e, -security) is
getting the following error (partial stack trace):

java.lang.NoClassDefFoundError:
javax/servlet/http/HttpSessionBindingListener
at java.lang.ClassLoader.defineClass0(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:537)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123
)

I found that common/lib/servlet-api.jar contains this class, and if I
manually add it to the classpath (by editing catalina.sh), my page will
then work.  According to the note above, all jars on common/lib should
be automatically available to my pages.  I haven't touched
catalina.properties.

Any idea why this jar is not being picked up automatically out of
common/lib?  Thanks.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: mod_jk problem

2004-01-26 Thread Guy Rouillier
Lukas Larsson wrote:
> Thx for the reply. I folloes your second link and found this site
> (http://johnturner.com/howto/apache2-tomcat4127-jk-rh9-howto.h
> tml) on how to configure mod_jk but I still get the same
> problem. Apache says that it is working with mod_jk, but it
> does not translate *.jsp pages (see
> http://garazdawi.homeftp.net/test.jsp for an > example of what
> I mean). Can someone please tell me what I'm doing wrong. I
> would really want to get started with jsp without having to
> battle with mod_jk.

Make sure your Tomcat is set up properly by going directly to it for the
JSP page, bypassing Apache, e.g.,
http://garazdawi.homeftp.net:8080/test.jsp (assuming you left Tomcat on
the default HTTP port.)  If that doesn't work, then the problem is in
Tomcat configuration not in mod_jk.

> 
> Thx
> 
> Lukas
> - Original Message -
> From: "Mark Eggers" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: Sunday, January 25, 2004 10:03 PM
> Subject: Re: mod_jk problem
> 
> 
>> Please see the following:
>> 
>> http://nagoya.apache.org/wiki/apachewiki.cgi?TomcatWeb
>> 
>> or
>> 
>> http://nagoya.apache.org/wiki/apachewiki.cgi?Tomcat/Links
>> 
>> Lots of information, including several step-by-step documents.
>> 
>> HTH
>> 
>> /mde/
>> just my two cents . . . .
>> 
>> 
>> __
>> Do you Yahoo!?
>> Yahoo! SiteBuilder - Free web site building tool. Try it!
>> http://webhosting.yahoo.com/ps/sb/
>> 
>> 
> -
>> 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: Removing ROOT as default path to tomcat 5

2004-01-23 Thread Guy Rouillier
Drinkwater, GJ (Glen) wrote:
> Hi
> 
> 
> I wish to remove ROOT as the default path to Tomcat 5, I have
> added  default $CATALINA_HOME/webapps/ROOT/index.jsp page still
> appears with http://localhost:8080.  This is how I did it
> with tomcat 4, has anything changed??

This worked for me, at the bottom of server.xml:



  
  
> 
> 
> 
> 
> 
> -
> 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: Starting up a particular configuration

2004-01-22 Thread Guy Rouillier
Shapira, Yoav wrote:
> Howdy,
> Use the -config {pathname} argument to specify a server.xml
> file to use. And please be careful in your wording, as this quote:
> 
>> According to RUNNING.txt, "you can pass a
>> "-Dcatalina.base=$CATALINA_BASE" argument when executing the startup
>> command" to run a specified configuration.
> 
> is completely out of context or alternatively you completely
> misunderstood it.  Setting CATALINA_BASE (different from
> CATALINA_HOME) applies only to multiple instances sharing the
> same base.

Yoav, thanks for the reply.  I am indeed running two instances of Tomcat
from one installation directory.  I've created a subdirectory (called
secure) under CATALINA_HOME and created the required directories (work,
conf, temp) there.  To run the first instance, I just run startup.  To
run the second instance, I tried this:

startup -Dcatalina.base=C:\\tomcat-jakarta-5.0.16\secure

and got the message I originally posted ("usage: java
org.apache.catalina.startup.Catalina [ -config {pathname} ] [ -debug ] [
-nonaming ] { start | stop }").  That's what I understand RUNNING.txt to
mean when it says "executing the startup command."  However, I very well
may be misunderstanding what it says, as I see in catalina.bat that it
uses the following:

%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS%
-Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%"
-Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%"
-Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS%
%ACTION%

So it looks like the -Dcatalina.base option is used by catalina.bat when
it invokes org.apache.catalina.startup.Bootstrap.  I think RUNNING.txt
could be clearer on this, as the end user would never supply this option
if he/she is using the supplied startup scripts/batch files.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Starting up a particular configuration

2004-01-21 Thread Guy Rouillier
According to RUNNING.txt, "you can pass a
"-Dcatalina.base=$CATALINA_BASE" argument when
executing the startup command" to run a specified configuration.  Yet
when I try I get this:

C:\jakarta-tomcat-5.0.16\bin>startup
-Dcatalina.base=c:\jakarta-tomcat-5.0.16\secure
Using CATALINA_BASE:   ..
Using CATALINA_HOME:   ..
Using CATALINA_TMPDIR: ..\temp
Using JAVA_HOME:   c:\jdk1.4.2
usage: java org.apache.catalina.startup.Catalina [ -config {pathname} ]
[ -debug ] [ -nonaming ] { s
tart | stop }

and it just runs the default configuration.  I have found I can do this
to run a specified configuration (in a startup-secure.bat batch file
under Win2K):

setlocal
set CATALINA_BASE=C:\jakarta-tomcat-5.0.16\secure
call startup -security

I looked in catalina.bat, and it looks like it pulls CATALINA_BASE only
out of the environment, so I can't see how passing it startup.bat will
accomplish the desired goal.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Mozilla showing JSP source code

2004-01-21 Thread Guy Rouillier
Jeff Greenland wrote:
> I'm sure this doesn't help, but we had the same problem with
> the 3.x series.  It went away when we upgraded to 4.x and 5.x.

Yoo-hoo!  Just struggled my way through setting up Tomcat 5.0.16 (never
could figure out how to get mod_jk2 to work, so fell back to mod_jk).
And the problem seems to have disappeared.  Don't really understand how,
as I mentioned in my original note if I bypass Apache and go to directly
to Tomcat (3.2.3), via :8080, I didn't see the problem.  That led me to
conclude that Tomcat wasn't the problem.  But I'm not going to argue
with success.  Thanks, Jeff (and all others who offered a suggestion.)

> 
> Good luck,
> 
> Jeff
> 
> 
> -Original Message-
> From: Guy Rouillier [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 19, 2004 5:36 PM
> To: Tomcat Users List
> Subject: Mozilla showing JSP source code
> 
> 
> I've tried to do due diligence on this issue, searching the
> archives as well as Google.  I'm sure it is a common problem,
> but I found several questions and no definitive responses, so
> here goes.  Our website works fine with IE, but we're having
> a significant problem with Mozilla (and derivatives like
> Galeon).  I've tried various versions, including 1.5 as well
> as the brand new 1.6.  I'm seeing this problem both from a
> Windows XP/2000 host and a Solaris host.  I've tried Mozilla
> both on Windows XP clients and Mandrake Linux 9.2 i586
> clients.  All exhibit the same behavior.
> 
> As the title says, when using Mozilla, I'll frequently see
> source code in the browser window.  If I hit reload, in most
> cases, I'll see the page properly displayed (99% of the time -
> rarely, I'll see the source again.)  We are still using Apache
> 1.3.27, Tomcat 3.2.3 and 
> mod_jk 1.2.4.  Here, for example, is one I can produce very
> regularly: === HTTP/1.1 200
> Date: Tue, 20 Jan 2004 00:14:25 GMT
> Server: Apache/1.3.26 (Unix) mod_jk mod_ssl/2.8.9 OpenSSL/0.9.6c
> Keep-Alive: timeout=15, max=99
> Connection: Keep-Alive
> Transfer-Encoding: chunked
> Content-Type: text/html;charset=ISO-8859-1
> 
> 1172
> 
> 
> ===
> 
> I'm still working on getting Tomcat 5.0.19 configured with
> JK2, in the hopes this will magically go away, but I've
> having problems getting JK2 configured properly.  Here are
> some things I've tried or noticed:
> 
> (1) I first tried going directly to Tomcat, bypassing Apache (using
>> 8080) and this works.  All our pages are displayed in
> Mozilla without any problem.  That leads me to conclude that
> the problem is either in Tomcat delivering the pages to
> Apache via mod_jk, or in Apache delivering the pages to the
> browser.  The first seems more likely.
> 
> (2) We specify no buffer clause on our page directive.  On
> some pages, specifying buffer="64kb" seems to work.
> Frustratingly, this solution seems to work on some pages but
> not others, and on some systems and not others for the same page.
> 
> (3) I also tried changing the KeepAliveTimeout in Apache
> httpd.conf. The default value is 15.  As a test, I upped it
> to 150.  Again, this solved the problem on some pages on some
> clients, but not reliably or predictably.  It also caused
> Mozilla to spin its wheels for about the whole 2 1/2 minutes.
> 
> (4) The most reliable way to see this fail is via a redirect.
>  This happens most frequently on the secure half of our
> website (https).  On those pages, we have an authentication
> header at the top of each page:
> 
> <%@ include file="/includes/authenheader.jspf" %>
> 
> Inside this file, we check some session variables, and if
> they don't have the right set of values (or those values
> don't exist) we
> response.sendRedirect() to a login page.  During this redirect, I
> *always* see the source for the login page - the login page
> has not come up cleanly one time.  This page is very small,
> and neither the buffer or timeout changes help.
> 
> If anyone has any ideas on how to address this problem, I'm
> willing to try anything.  I really am out of ideas and don't
> know where to go next. Thanks for any help.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: FORM based authentication referer

2004-01-21 Thread Guy Rouillier
Ricardo GarcĂ­a wrote:
> Here's some starting context for my question 
> 
> I have a war file that has been configured to use FORM based
> authentication. I have set the  in the
> web.xml of the war file to point to a jsp file in my war
> file.  When a user invokes any jsp without being logged
> in the login jsp is displayed.  The user enters the
> userid/password submits the page to j_security_check, is
> validated and redirected to the requested page.
> 
> My question is ...
> 
> Has anyone ever tried discovering the page that the user is
> trying to access from within the jsp page referenced as the
> ?  I have tried checking the HTTP headers
> and session, but have not discovered it being saved anywhere.
>  Usually when a page invokes another page the HTTP header
> REFERER exists with the URL to the previous page.  I have
> noticed that once the user posts the login form on my
> login.jsp to j_security_check and is authenticated they are
> redirect to the correct location .. correct location being
> back to the page they wanted to access originally.  This
> would mean that it has to be somewhere, but where??

We do this manually instead of using the  mechanism.  In the header 
included at the top of every page for authentication, we capture

session.setAttribute("login.target", request.getRequestURI() );

before redirecting to the login page.  If you wait until you get to the page that is 
processing your login request, you've already lost the original request.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Mozilla showing JSP source code

2004-01-20 Thread Guy Rouillier
Jeff Greenland wrote:
> I'm sure this doesn't help, but we had the same problem with
> the 3.x series.  It went away when we upgraded to 4.x and 5.x.

Thanks, I am trying to get Tomcat 5 up to see if the problem will go
away, having a little trouble getting mod_jk2 configured properly.
Found some examples on the web, but can't get them to work.  I'll keep
plugging away.

> 
> Good luck,
> 
> Jeff
> 
> 
> -Original Message-
> From: Guy Rouillier [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 19, 2004 5:36 PM
> To: Tomcat Users List
> Subject: Mozilla showing JSP source code
> 
> 
> I've tried to do due diligence on this issue, searching the
> archives as well as Google.  I'm sure it is a common problem,
> but I found several questions and no definitive responses, so
> here goes.  Our website works fine with IE, but we're having
> a significant problem with Mozilla (and derivatives like
> Galeon).  I've tried various versions, including 1.5 as well
> as the brand new 1.6.  I'm seeing this problem both from a
> Windows XP/2000 host and a Solaris host.  I've tried Mozilla
> both on Windows XP clients and Mandrake Linux 9.2 i586
> clients.  All exhibit the same behavior.
> 
> As the title says, when using Mozilla, I'll frequently see
> source code in the browser window.  If I hit reload, in most
> cases, I'll see the page properly displayed (99% of the time -
> rarely, I'll see the source again.)  We are still using Apache
> 1.3.27, Tomcat 3.2.3 and 
> mod_jk 1.2.4.  Here, for example, is one I can produce very
> regularly: === HTTP/1.1 200
> Date: Tue, 20 Jan 2004 00:14:25 GMT
> Server: Apache/1.3.26 (Unix) mod_jk mod_ssl/2.8.9 OpenSSL/0.9.6c
> Keep-Alive: timeout=15, max=99
> Connection: Keep-Alive
> Transfer-Encoding: chunked
> Content-Type: text/html;charset=ISO-8859-1
> 
> 1172
> 
> 
> ===
> 
> I'm still working on getting Tomcat 5.0.19 configured with
> JK2, in the hopes this will magically go away, but I've
> having problems getting JK2 configured properly.  Here are
> some things I've tried or noticed:
> 
> (1) I first tried going directly to Tomcat, bypassing Apache (using
>> 8080) and this works.  All our pages are displayed in
> Mozilla without any problem.  That leads me to conclude that
> the problem is either in Tomcat delivering the pages to
> Apache via mod_jk, or in Apache delivering the pages to the
> browser.  The first seems more likely.
> 
> (2) We specify no buffer clause on our page directive.  On
> some pages, specifying buffer="64kb" seems to work.
> Frustratingly, this solution seems to work on some pages but
> not others, and on some systems and not others for the same page.
> 
> (3) I also tried changing the KeepAliveTimeout in Apache
> httpd.conf. The default value is 15.  As a test, I upped it
> to 150.  Again, this solved the problem on some pages on some
> clients, but not reliably or predictably.  It also caused
> Mozilla to spin its wheels for about the whole 2 1/2 minutes.
> 
> (4) The most reliable way to see this fail is via a redirect.
>  This happens most frequently on the secure half of our
> website (https).  On those pages, we have an authentication
> header at the top of each page:
> 
> <%@ include file="/includes/authenheader.jspf" %>
> 
> Inside this file, we check some session variables, and if
> they don't have the right set of values (or those values
> don't exist) we
> response.sendRedirect() to a login page.  During this redirect, I
> *always* see the source for the login page - the login page
> has not come up cleanly one time.  This page is very small,
> and neither the buffer or timeout changes help.
> 
> If anyone has any ideas on how to address this problem, I'm
> willing to try anything.  I really am out of ideas and don't
> know where to go next. Thanks for any help.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Mozilla showing JSP source code

2004-01-20 Thread Guy Rouillier
Sean Utt wrote:
> Hi,
> 
> I used to see this when doing a response.sendRedirect()
> without following it with a return(), but didn't see jsp
> source, just html source. I did have a problem with mod_jk
> showing .jsp source when the URI contained a // in the path
> like http://dom.ain/context//file.jsp, but that sounds like a
> different problem and an upgrade of mod_jk fixed that.

Sean, thanks for the reply.  Now that you mention it, I am indeed seeing
HTML source, not JSP source.  We do a *pretty* good job of putting
returns after our redirects, though I find an occasional missing return.
On all the pages I'm investigating, sendRedirect is followed by a
return.  And of course there is always the problem of Tomcat not
*allowing* you to put a return if the sendRedirect is the last statement
on the page; you get a "code not reachable" on the curly brace that
follows it .

Were you able to resolve the showing of the HTML source?

> 
> Sean
> 
> Web Solutions That Work Developing custom web solutions
> designed specifically to accomplish the unique objectives of
> our clients. Phone 503-639-2727 Fax 503-639-0807
> - Original Message -
> From: Guy Rouillier [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 19, 2004 5:36 PM
> To: Tomcat Users List
> Subject: Mozilla showing JSP source code
> 
> 
> [snip]
> 
> (4) The most reliable way to see this fail is via a redirect.
>  This happens most frequently on the secure half of our
> website (https).  On those pages, we have an authentication
> header at the top of each page:
> 
> <%@ include file="/includes/authenheader.jspf" %>
> 
> Inside this file, we check some session variables, and if
> they don't have the right set of values (or those values
> don't exist) we
> response.sendRedirect() to a login page.  During this redirect, I
> *always* see the source for the login page - the login page
> has not come up cleanly one time.  This page is very small,
> and neither the buffer or timeout changes help.
> 
> If anyone has any ideas on how to address this problem, I'm
> willing to try anything.  I really am out of ideas and don't
> know where to go next. Thanks for any help.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Mozilla showing JSP source code

2004-01-19 Thread Guy Rouillier
I've tried to do due diligence on this issue, searching the archives as
well as Google.  I'm sure it is a common problem, but I found several
questions and no definitive responses, so here goes.  Our website works
fine with IE, but we're having a significant problem with Mozilla (and
derivatives like Galeon).  I've tried various versions, including 1.5 as
well as the brand new 1.6.  I'm seeing this problem both from a Windows
XP/2000 host and a Solaris host.  I've tried Mozilla both on Windows XP
clients and Mandrake Linux 9.2 i586 clients.  All exhibit the same
behavior.

As the title says, when using Mozilla, I'll frequently see source code
in the browser window.  If I hit reload, in most cases, I'll see the
page properly displayed (99% of the time - rarely, I'll see the source
again.)  We are still using Apache 1.3.27, Tomcat 3.2.3 and mod_jk
1.2.4.  Here, for example, is one I can produce very regularly:
===
HTTP/1.1 200 
Date: Tue, 20 Jan 2004 00:14:25 GMT
Server: Apache/1.3.26 (Unix) mod_jk mod_ssl/2.8.9 OpenSSL/0.9.6c
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html;charset=ISO-8859-1

1172


===

I'm still working on getting Tomcat 5.0.19 configured with JK2, in the
hopes this will magically go away, but I've having problems getting JK2
configured properly.  Here are some things I've tried or noticed:

(1) I first tried going directly to Tomcat, bypassing Apache (using
:8080) and this works.  All our pages are displayed in Mozilla without
any problem.  That leads me to conclude that the problem is either in
Tomcat delivering the pages to Apache via mod_jk, or in Apache
delivering the pages to the browser.  The first seems more likely.

(2) We specify no buffer clause on our page directive.  On some pages,
specifying buffer="64kb" seems to work.  Frustratingly, this solution
seems to work on some pages but not others, and on some systems and not
others for the same page.

(3) I also tried changing the KeepAliveTimeout in Apache httpd.conf.
The default value is 15.  As a test, I upped it to 150.  Again, this
solved the problem on some pages on some clients, but not reliably or
predictably.  It also caused Mozilla to spin its wheels for about the
whole 2 1/2 minutes.

(4) The most reliable way to see this fail is via a redirect.  This
happens most frequently on the secure half of our website (https).  On
those pages, we have an authentication header at the top of each page:

<%@ include file="/includes/authenheader.jspf" %>

Inside this file, we check some session variables, and if they don't
have the right set of values (or those values don't exist) we
response.sendRedirect() to a login page.  During this redirect, I
*always* see the source for the login page - the login page has not come
up cleanly one time.  This page is very small, and neither the buffer or
timeout changes help.

If anyone has any ideas on how to address this problem, I'm willing to
try anything.  I really am out of ideas and don't know where to go next.
Thanks for any help.

-- 
Guy Rouillier

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: maxProcessors vs maxThreads

2004-01-19 Thread Guy Rouillier
Apu Shah wrote:
> thanks yoav.
> 
> this begs another question... under what circumstances would
> one choose to use the ajp connector? i am assuming it's
> probably a more compact and efficient protocol compared to
> http (not sure about that).
> 
> in any case, if one never needs to access tomcat directly
> from a browser (tomcat is always hidden behind apache on an
> internal network not accessible from the outside) what
> parameters should i use to judge whether to use http or ajp
> connectors? 
> 
> it seems like http is better (due to the fact that you can
> customize settings like maxThreads) but i was always under
> the impression that ajp should be preferred over http (i
> guess i was wrong)
> 
> any thoughts on this?

AJP and HTTP serve different purposes.  AJP is used for Apache to talk
to Tomcat.  They could use HTTP, I suppose, but AJP is a more efficient
protocol.  You cannot use directly from your browser to Tomcat using AJP
- browsers don't support that protocol.  Apache has a module (the
mod_jk.dll or the equivalent on Unix) that enables it to communicate
using that protocol.

You can indeed communicate with Tomcat directly from your browser.  If
you have it enabled, you can use port 8080 (default value, you can
change), so a URL might look like http://yourserver:8080/yourpage.jsp.
If you want, you can even cut Apache out completely, and tell Tomcat to
handle port 80.  Not advisable, though, as Apache has had thousands of
hours invested to make it efficient at delivering static content.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: NullPointerException on exception in ErrorPage.jsp

2002-12-24 Thread Guy Rouillier
I figured this one out.  Somebody had coded a sendRedirect("errorpage.jsp").
Sorry for the noise.

- Original Message -----
From: "Guy Rouillier" <[EMAIL PROTECTED]>
To: "Tomcat User" <[EMAIL PROTECTED]>
Sent: Tuesday, December 24, 2002 2:20 PM
Subject: NullPointerException on exception in ErrorPage.jsp


I've been notified of a really weird exception.  I've searched the archives
to no avail.  I provide the actual code at the bottom of this message.  In
summary, some error on our web site is causing invocation of the designated
JSP error page.  The error page is apparently getting a NullPointerException
on the implicit exception object.  How is it possible to get to the error
page with a null exception object?  My understanding is that the only time
the error page gets invoked is if some unhandled exception occurs on a
non-error page.  So I can't understand how the exception can be null on the
error page.  By the way, this same error page has successfully reported
errors on numerous occasions in the past; this is the first time I've
received a report of a failure on the error page itself.

Here is the reported exception (cut down for readability) and the source
(located on the translated .java file, but shown from errorpage.jsp):

java.lang.NullPointerException
at
common.html._0002fcommon_0002fhtml_0002ferrorpage_0002ejsperrorpage_jsp_0._j
spService(_0002fcommon_0002fhtml_0002ferrorpage_0002ejsperrorpage_jsp_0.java
:75)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)

<%
exception.printStackTrace(new PrintWriter(out));
%>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




NullPointerException on exception in ErrorPage.jsp

2002-12-24 Thread Guy Rouillier
I've been notified of a really weird exception.  I've searched the archives to no 
avail.  I provide the actual code at the bottom of this message.  In summary, some 
error on our web site is causing invocation of the designated JSP error page.  The 
error page is apparently getting a NullPointerException on the implicit exception 
object.  How is it possible to get to the error page with a null exception object?  My 
understanding is that the only time the error page gets invoked is if some unhandled 
exception occurs on a non-error page.  So I can't understand how the exception can be 
null on the error page.  By the way, this same error page has successfully reported 
errors on numerous occasions in the past; this is the first time I've received a 
report of a failure on the error page itself.

Here is the reported exception (cut down for readability) and the source (located on 
the translated .java file, but shown from errorpage.jsp):

java.lang.NullPointerException
at 
common.html._0002fcommon_0002fhtml_0002ferrorpage_0002ejsperrorpage_jsp_0._jspService(_0002fcommon_0002fhtml_0002ferrorpage_0002ejsperrorpage_jsp_0.java:75)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)

<%
exception.printStackTrace(new PrintWriter(out));
%>