Tomcat 6 requires config to run on JSE 5?
I recently got bit by this: http://marc.info/?t=10970926148r=1w=2 So I was looking for some statement somewhere on if that issue is now fixed in 5.0.x and/or if it's an issue in either 5.5 or 6.0, and what JVMs are 'safe' to use in 5.5 and 6.0. That's when I saw this: Tomcat 6.0 is designed to run on JSE 5.0 and later, and requires configuration to run on JSE 5.0. from: http://tomcat.apache.org/tomcat-6.0-doc/RELEASE-NOTES.txt The corresponding note from the previous version is: Tomcat 5.5 is designed to run on J2SE 5.0 and later, and requires configuration to run on J2SE 1.4. Make sure to read the RUNNING.txt file in the fulldocs downloadable file(s) if you are using J2SE 1.4. from: http://tomcat.apache.org/tomcat-5.5-doc/RELEASE-NOTES.txt I'm wondering if someone in the know could confirm that the text of the TC6 release notes is correct? It seems off. Why say it's designed for x, then say it requires config to run on x. Thanks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Avoiding same server to server HTTP calls to generate HTML pages via JSPs
Both incorporate the output of jsps and servlets in the current request's output. Which is not what the OP wanted. They wanted to : essentially slap that [the response] into a MimeBodyPart for sending text/html email messages. I've done something very similar - use an HTTP connection to 'scrape' a page, and then include that output as the contents of a rich email. The only thing I've done to make it easier is bundle up that functionality in my own Util class that has a scrape method that takes the current request, an URL and returns a String. I use it when I want to scrape JSPs for their content. In some cases, I have a few simpler pages that are actually velocity templates. Velocity can be used outside the context of a HTTP request/response cycle, so if you're able to re-do your JSP pages as velocity templates (or similar technology) then it could be your best bet. http://velocity.apache.org - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Confusion between docs and server.xml
Hello, Just got through reading docs and xml comments and thought I'd point out something (minor). This here: http://tomcat.apache.org/tomcat-6.0-doc/jasper-howto.html#Configuration seems to contain out-of-date information, if one compares it to the comments in $CATALINA_BASE/conf/web.xml I believe the web.xml comments are the more correct documentation, but thought I'd send in the comparison to let someone who actually knows confirm my ponits (below). The docs contain the following bullets: * checkInterval - If development is false and reloading is true, background compiles are enabled. checkInterval is the time in seconds between checks to see if a JSP page needs to be recompiled. Default 300 seconds. * development - Is Jasper used in development mode (will check for JSP modification on every access)? true or false, default true. * modificationTestInterval - Checks for modification for a given JSP file (and all its dependent files) will be performed only once every specified amount of seconds. Setting this to 0 will cause the JSP to be checked on every access. Default is 4 seconds. * reloading - Should Jasper check for modified JSPs? true or false, default false. But in $CATALINA_BASE/conf/web.xml, I find these (clearer, less confusing) entries: !-- checkInterval If development is false and checkInterval is -- !-- greater than zero, background compilations are -- !-- enabled. checkInterval is the time in seconds -- !-- between checks to see if a JSP page needs to -- !-- be recompiled. [0] -- !-- -- !-- modificationTestInterval -- !-- Causes a JSP (and its dependent files) to not -- !-- be checked for modification during the -- !-- specified time interval (in seconds) from the -- !-- last time the JSP was checked for -- !-- modification. A value of 0 will cause the JSP -- !-- to be checked on every access. -- !-- Used in development mode only. [4] -- !-- -- !-- development Is Jasper used in development mode? If true, -- !-- the frequency at which JSPs are checked for -- !-- modification may be specified via the -- !-- modificationTestInterval parameter. [true] -- Suggested changes to the documentation (jasper-howto.html) [1] Is 'reloading' a deprecated attribute? If so, it should be removed from the docs. [2] The 'development' attribute should state every modificationTestInterval seconds (or some such description), instead of on every access. [3] The 'modificationTestInterval' attribute should explain it's only used when development=true (to distinguish it from 'checkInterval') [4] 'checkInterval' appears to have the wrong default value (is it 300 or 0?) For both the jasper-howto and the comments: [5] Is the exclusion of ...(and its dependent files)... from the description of checkInterval deliberate? If the checks are the same regardless of 'development' setting, then I think it should be described the same in both 'interval' parameters. Which leads me to... [6] This is totally an internals question, so feel free to flame someone who doesn't contribute code, but: couldn't modificationTestInterval and checkInterval be merged into a single attribute? I'm genuinely curious to know why it would be bad to do so. Thanks, and Happy New Year. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Null
Sigh.
-Original Message-
From: domenico di leo [mailto:[EMAIL PROTECTED]
Sent: Friday, June 29, 2007 1:10 PM
To: Tomcat Users List
Subject: Re: Null
Obviovusily you don't compare two string in this way!
if (null == rs.getString(col_foo))
The right manner is:
if (rs.getString(col_foo).equals(null)){
..
}
Your problem is Java not database
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Programmatically Determine JVM Version used by Tomcat
Can you make something out of this?
public class JavaVer {
public static void main(String[] args) {
System.out.println(java.version: +
System.getProperty(java.runtime.version));
System.out.println(JAVA_HOME: + System.getProperty(JAVA_HOME));
}
}
D:\DEV\classesjava -version
java version 1.6.0_01
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)
D:\DEV\classesjava -DJAVA_HOME=c:\j2sdk1.4.2_10 JavaVer
java.version: 1.6.0_01-b06
JAVA_HOME: c:\j2sdk1.4.2_10
As you can see, java.version gives you what running JVM is currently
using, regardless of what JAVA_HOME says (or any other env var), but
I'm not sure if this is totally borked in Windows Service-land.
You'd then have to compare the two strings to see if they're not equal.
Or if one equals something it shouldn't...
-Original Message-
From: David kerber [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 07, 2007 10:31 AM
To: Tomcat Users List
Subject: Re: Programmatically Determine JVM Version used by Tomcat
bachuba wrote:
Hi,
I'm fairly new to using Tomcat, but need to determine what
JVM version
(or at least the path to it) a running Tomcat service is currently
using on a Windows system. If I run tomcat5w.exe and click on the
Java tab, I notice the informaiton is listed there, but I
would like
to be able to get at that programmatically. We are currently using
Tomcat version 5.0.28. Could somone please describe how
this could be done? Thanks.
The system property java.version will probably give you
what you want.
D
-
To start a new topic, e-mail: users@tomcat.apache.org To
unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: error-page not working
Is it possible you're running into any of : http://issues.apache.org/bugzilla/show_bug.cgi?id=42434 http://issues.apache.org/bugzilla/show_bug.cgi?id=37062#c4 http://issues.apache.org/bugzilla/show_bug.cgi?id=40135 -Original Message- From: David Delbecq [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 23, 2007 3:26 PM To: Tomcat Users List Subject: Re: error-page not working SiSi'mon a écrit : I have the following: error-page exception-typejava.lang.Throwable/exception-type location/web/error/Throwable.jsf/location /error-page but there are myfaces / spring and hibernate exceptions being thrown and it is not being sent to this xhtml page. any ideas? All exceptions that get out of the Servlet that handled a request are redirected to error page by container. However, there is one case, i encountered it using struts tiles, where an exception make it out of servlet but does not reach client screen. It's when servlet already started to flush response to client. At this time it's impossible to send an error page. However, exception does anyway reach the logs. So, for jsf, if your exception occurs in render response face, no way to get it on screen with basic configuration. One way around this is to prevent servlet from sending response to client until it wrote all response to a buffer. You can, for example, add a servlet filter that wrapps the responseWriter to a byteArrayOutputStream. This way, only when servlet returned properly from process you send response to client. But this buffering has a price, if response is 600K you need 600K ram during request. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: I've been trying to unsubscribe from this list for years.
And on a completely unrelated note, ask your sysadmin how to set up server-side Outlook rules. They'll work in both your outlook client and through your webmail. -Original Message- From: Keith Adams [mailto:[EMAIL PROTECTED] Sent: Thursday, May 17, 2007 9:33 PM To: [EMAIL PROTECTED]; users@tomcat.apache.org Subject: I've been trying to unsubscribe from this list for years. No matter how many times I send a blank email to: [EMAIL PROTECTED], like the one I sent at 11.19 Eastern this morning, nothing happens. I use a rule to delete them permanently when I'm in Outlook, but when I use my company's web outlook, it can only move them to the deleted-items folder, which rapidly fills up, making it very hard for me to find things in there if I need to. Please help. Thanks, Keith - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: error-page and TC 5.5.23
Is this just a boring question, or has no-one else run into the problem?
-Original Message-
From: gb1071nx [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 08, 2007 2:22 PM
To: Tomcat Users List
Subject: RE: error-page and TC 5.5.23
I'm just adding to this:
When I remove the mapping for the error-code 500, then I get
the standard tc5.5 error page. So my exception-type
error-page directive is being ignored.
So it does appear that
http://issues.apache.org/bugzilla/show_bug.cgi?id=37062#c4
isn't fixed.
And won't be fixed?
It occurs to me that this should break quite a few working
apps though, so surely someone else has reported it?
Searching further, I found this:
http://issues.apache.org/bugzilla/show_bug.cgi?id=40135
Is it then now a requirement that for JSP's, we *must* use
the errorPage directive? Or is there a way to get the more
generic web.xml error-page config to work?
And can anyone explain what is meant by development mode
(from comment in bug 37062 and how to switch it off (to see
if that makes my error-page's work again)
-Original Message-
From: gb1071nx [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 08, 2007 12:39 PM
To: Tomcat Users List
Subject: error-page and TC 5.5.23
Hello,
I'm starting the process of migrating some of our server from
5.0.29 to 5.5.23, and I've found that the 'nice' useful stacktraces
with
linenumbers are back, and working beautifully in 5.5.23.
But I do find the following issues as well:
I have the following test page:
html
body
%
if (true) {
throw new java.sql.SQLException(TEST); } % /body /html
And the following web.xml:
?xml version=1.0 encoding=ISO-8859-1? web-app
xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
version=2.4
error-page
exception-typejava.sql.SQLException/exception-type
location/error/database.jsp/location
/error-page
error-page
error-code500/error-code
location/error/500.jsp/location
/error-page
/web-app
And when I call the page throwing the SQLException, I get the error
page
for the error-code 500. Tomcat5.0 does not behave like
that, 5.5 does.
Which is the correct behaviour? (or perhaps: is there a way to
configure 5.5 so that it acts like 5.0?) I recall this bug report:
http://issues.apache.org/bugzilla/show_bug.cgi?id=37062#c4 .
Has the bug reported in comment#4 been fixed? Is this the bug I'm
experiencing in my test page?
Also, I can confirm the following bug, I also experience it:
http://issues.apache.org/bugzilla/show_bug.cgi?id=42314
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: error-page and TC 5.5.23
I was under the impression that the exception traps are part of the
spec, somewhere in srv.9.9.
I expect someone here to say:
yes, it's part of the spec that we broke in TC 5.5, and we'll fix it
or :
that's not part of the spec, so who cares that it doesn't work
or:
part of the spec, but who cares.
I just want a response from someone with the power to fix it, that it
will be fixed (or not).
-Original Message-
From: David Smith [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 10, 2007 10:20 AM
To: Tomcat Users List
Subject: Re: error-page and TC 5.5.23
Reading the comments on the bug issue you cited, it looks
like it's fixed, but with side effects -- namely the
exception traps aren't available any more. What do you want
anyone to say here?
--David
gb1071nx wrote:
Is this just a boring question, or has no-one else run into
the problem?
-Original Message-
From: gb1071nx [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 08, 2007 2:22 PM
To: Tomcat Users List
Subject: RE: error-page and TC 5.5.23
I'm just adding to this:
When I remove the mapping for the error-code 500, then I get the
standard tc5.5 error page. So my exception-type error-page
directive
is being ignored.
So it does appear that
http://issues.apache.org/bugzilla/show_bug.cgi?id=37062#c4
isn't fixed.
And won't be fixed?
It occurs to me that this should break quite a few working
apps though, so surely someone else has reported it?
Searching further, I found this:
http://issues.apache.org/bugzilla/show_bug.cgi?id=40135
Is it then now a requirement that for JSP's, we *must* use the
errorPage directive? Or is there a way to get the more generic
web.xml error-page config to work?
And can anyone explain what is meant by development mode
(from comment in bug 37062 and how to switch it off (to see if that
makes my error-page's work again)
-Original Message-
From: gb1071nx [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 08, 2007 12:39 PM
To: Tomcat Users List
Subject: error-page and TC 5.5.23
Hello,
I'm starting the process of migrating some of our server from
5.0.29 to 5.5.23, and I've found that the 'nice' useful
stacktraces
with
linenumbers are back, and working beautifully in 5.5.23.
But I do find the following issues as well:
I have the following test page:
html
body
%
if (true) {
throw new java.sql.SQLException(TEST); } % /body /html
And the following web.xml:
?xml version=1.0 encoding=ISO-8859-1? web-app
xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
version=2.4
error-page
exception-typejava.sql.SQLException/exception-type
location/error/database.jsp/location
/error-page
error-page
error-code500/error-code
location/error/500.jsp/location
/error-page
/web-app
And when I call the page throwing the SQLException, I get
the error
page
for the error-code 500. Tomcat5.0 does not behave like
that, 5.5 does.
Which is the correct behaviour? (or perhaps: is there a way to
configure 5.5 so that it acts like 5.0?) I recall this bug report:
http://issues.apache.org/bugzilla/show_bug.cgi?id=37062#c4 .
Has the bug reported in comment#4 been fixed? Is this the bug I'm
experiencing in my test page?
Also, I can confirm the following bug, I also experience it:
http://issues.apache.org/bugzilla/show_bug.cgi?id=42314
-
To start a new topic, e-mail: users@tomcat.apache.org To
unsubscribe,
e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org To
unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: error-page and TC 5.5.23
I don't like bothering the dev list with things that I'm not 100% sure
are 'real' problems. Same with buzilla; why commit the ultimate
affrontery of entering a bugzilla report, just so someone can close it
with a snipe and an INVALID. And I just can't believe that after all
this time, I'm the first person to 'discover' this bug. That's why I
was asking around here first.
But, perhaps you have enboldened me. ;)
-Original Message-
From: David Smith [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 10, 2007 10:41 AM
To: Tomcat Users List
Subject: Re: error-page and TC 5.5.23
I know there are committers reading this list, but you might
want to ping this question off the dev list. You could also
search for a follow up issue in bugzilla to address the new
problem. If one doesn't exist, go ahead and submit one.
--David
gb1071nx wrote:
I was under the impression that the exception traps are part of the
spec, somewhere in srv.9.9.
I expect someone here to say:
yes, it's part of the spec that we broke in TC 5.5, and
we'll fix it
or :
that's not part of the spec, so who cares that it doesn't work
or:
part of the spec, but who cares.
I just want a response from someone with the power to fix
it, that it
will be fixed (or not).
-Original Message-
From: David Smith [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 10, 2007 10:20 AM
To: Tomcat Users List
Subject: Re: error-page and TC 5.5.23
Reading the comments on the bug issue you cited, it looks like it's
fixed, but with side effects -- namely the exception traps aren't
available any more. What do you want anyone to say here?
--David
gb1071nx wrote:
Is this just a boring question, or has no-one else run into
the problem?
-Original Message-
From: gb1071nx [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 08, 2007 2:22 PM
To: Tomcat Users List
Subject: RE: error-page and TC 5.5.23
I'm just adding to this:
When I remove the mapping for the error-code 500, then I get the
standard tc5.5 error page. So my exception-type error-page
directive
is being ignored.
So it does appear that
http://issues.apache.org/bugzilla/show_bug.cgi?id=37062#c4
isn't fixed.
And won't be fixed?
It occurs to me that this should break quite a few working
apps though, so surely someone else has reported it?
Searching further, I found this:
http://issues.apache.org/bugzilla/show_bug.cgi?id=40135
Is it then now a requirement that for JSP's, we *must* use the
errorPage directive? Or is there a way to get the more generic
web.xml error-page config to work?
And can anyone explain what is meant by development mode
(from comment in bug 37062 and how to switch it off (to
see if that
makes my error-page's work again)
-Original Message-
From: gb1071nx [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 08, 2007 12:39 PM
To: Tomcat Users List
Subject: error-page and TC 5.5.23
Hello,
I'm starting the process of migrating some of our server from
5.0.29 to 5.5.23, and I've found that the 'nice' useful
stacktraces
with
linenumbers are back, and working beautifully in 5.5.23.
But I do find the following issues as well:
I have the following test page:
html
body
%
if (true) {
throw new java.sql.SQLException(TEST); } % /body /html
And the following web.xml:
?xml version=1.0 encoding=ISO-8859-1? web-app
xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
version=2.4
error-page
exception-typejava.sql.SQLException/exception-type
location/error/database.jsp/location
/error-page
error-page
error-code500/error-code
location/error/500.jsp/location
/error-page
/web-app
And when I call the page throwing the SQLException, I get
the error
page
for the error-code 500. Tomcat5.0 does not behave like
that, 5.5 does.
Which is the correct behaviour? (or perhaps: is there a way to
configure 5.5 so that it acts like 5.0?) I recall this
bug report:
http://issues.apache.org/bugzilla/show_bug.cgi?id=37062#c4 .
Has the bug reported in comment#4 been fixed? Is this
the bug I'm
experiencing in my test page?
Also, I can confirm the following bug, I also experience it:
http://issues.apache.org/bugzilla/show_bug.cgi?id=42314
---
--
To start a new topic, e-mail: users@tomcat.apache.org To
unsubscribe,
e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users
error-page and TC 5.5.23
Hello,
I'm starting the process of migrating some of our server from 5.0.29 to
5.5.23, and I've found that the 'nice' useful stacktraces with
linenumbers are back, and working beautifully in 5.5.23.
But I do find the following issues as well:
I have the following test page:
html
body
%
if (true) {
throw new java.sql.SQLException(TEST);
}
%
/body
/html
And the following web.xml:
?xml version=1.0 encoding=ISO-8859-1?
web-app xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
version=2.4
error-page
exception-typejava.sql.SQLException/exception-type
location/error/database.jsp/location
/error-page
error-page
error-code500/error-code
location/error/500.jsp/location
/error-page
/web-app
And when I call the page throwing the SQLException, I get the error page
for the error-code 500. Tomcat5.0 does not behave like that, 5.5 does.
Which is the correct behaviour? (or perhaps: is there a way to
configure 5.5 so that it acts like 5.0?) I recall this bug report:
http://issues.apache.org/bugzilla/show_bug.cgi?id=37062#c4 . Has the
bug reported in comment#4 been fixed? Is this the bug I'm experiencing
in my test page?
Also, I can confirm the following bug, I also experience it:
http://issues.apache.org/bugzilla/show_bug.cgi?id=42314
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Manager vs host-manager
I've found in the $CATALINA_HOME/server/webapps directory these two apps: manager (know what this is) host-manager (don't know what this is) I've searched the contents of http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html but can't find a reference to the TC 5.5 deployed app host-manager. Can someone shed some light?
RE: TOMCAT 5.0.28 stability
This is certainly not a tomcat stability problem, it's the application
that has been coded poorly
syntax to use near 's Time Management workshop
You've got some SQL code somewhere that looks like this:
String sql = INSERT INTO table (foo) VALUES(' + fooVar + ');
And you're inserting data (fooVar variable contains)
Manager's Time Management workshop
Which results in SQL that looks like:
INSERT INTO table (foo) VALUES('Manager's Time Management workshop')
Notice how the single quote results in mal-formed SQL?
-Original Message-
From: Dwight Farris [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 27, 2007 11:34 AM
To: 'Tomcat Users List'
Subject: TOMCAT 5.0.28 stability
Hello Bob,
I made the change in CATALINA_OPTS in catalina.sh; and I
searched the Catalina.out file for exceptions with the
following returning:
java.sql.SQLException: You have an error in your SQL
syntax; check
the manual that corresponds to your MySQL server version
for the right
syntax to use near 's Time Management workshop
java.sql.SQLException: Illegal operation on empty result set...
If I am not mistaken, there appears to be an issue with
resource centered on data manipulation. I am continuously
writing data from a data warehouse to a local MySQL data
repository. I envision receiving a number of these types of
exceptions; however I am beginning to believe TOMCAT 5.0 has
an issue supporting the processes from MySQL.
The premise of this assumption stems from the fact that I
have the same scenario running on a TOMCAT 5.5 development
platform and it will only stop running when the app fails on 5.0.
Hope this makes some sense.
Dwight
__
__
If your webapp(s) really need a gig of memory, I sugggest
changing CATALINA_OPTS
CATALINA_OPTS=$CATALINA_OPTS -Xms1024m -Xmx1024m
Looks like you are using unix/linux. Did you 'grep'
for Exception and Error in catalina.out?
The Cohorts getName() messages don't look familiar to me. Is
there a Cohorts class in one or more of your webapp's?
-Bob
__
__
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
-
To start a new topic, e-mail: users@tomcat.apache.org To
unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org To
unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
migrating from 5.0 to 5.5 - Configuring Contexts, Hosts, etc
I'm just looking into what it takes to both migrate to TC5.5, and switch from configuring everything in server.xml to individual context files. I've read the docs on contexts, hosts, and that Virtual Hosting guide. I have some misunderstandings still about how it all works together. Hoping someone can help. Documentation quotes are from: http://tomcat.apache.org/tomcat-5.5-doc/config/host.html The auto deployer will also track web applications for the following changes: snipped two irrelevant bullets * An update to a XML configuration file will trigger an undeploy (without the removal of any expanded directory), followed by a deployment of the associated web application This is actually the only behaviour of the auto deployer that I'm really interested in, and would be my main motivation for switching from server.xml config to individual context.xml config files. I'd like to be able to change config of an application , without having to bounce the whole server. 1st Q: The only way for tomcat to monitor that context.xml file and have it reload it automatically is to have deployOnStartup=true (the default). True/False? 2nd Q: Can I define a host and *not* set appBase? (I seem to be able to do so with Tomcat 5.0) The next two questions have to do with these two sentences in the docs (they appear one right after the other in the docs) When using automatic deployment, the docBase defined by an XML Context file should be outside of the appBase directory. If this is not the case difficulties may be experienced deploying the web application or the application may be deployed twice. Finally, note that if you are defining contexts explicitly, you should probably turn off automatic application deployment. Otherwise, your context will be deployed twice each, and that may cause problems for your app. 3rd Q: Assume all the following: a) Host appbase=/home/websites/ name=www.mysite.com b) Host appbase=/home/websites/ name=www.mysite2.com c) $CATALINA_HOME/conf/Catalina/www.mysite.com/ROOT.xml with a docBase attribute of /home/websites/www.mysite.com d) $CATALINA_HOME/conf/Catalina/www.mysite2.com/ROOT.xml with a docBase attribute of /home/websites/www.mysite2.com e) deployOnStartup=true Would tomcat then attempt to deploy both www.mysite.com and www.mysite2.com as websites under each Host? I assume that's what the first sentence is warning us about? 4th Q: Is there any circumstance, in which I can get the behaviour I want from my first question, and yet turn off the auto-deploy (as seems to be indicated by the second sentence)? As a secondary question, why is it now _will be_ deployed twice, while the previous sentence talked about _may be_ deployed twice? Will it, or won't it? Thanks. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Anyone know of an up-to-date packager?
So, We (the developers) have been in control of the servers. We download exactly what we want, install it where we need it, and life is good. But our ops guy is making noise about wanting to manage everything through something called yum. Noodling around just a little bit, I see that our yum only has up to TC 5.5.17 available. As I understand it, you can tell yum to get these packages from some other sites, so I guess I'll ask tomcat-user if anyone knows of a super-up-to-date package site? Or... What community would it be better to ask this in? - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] RE: Cannot start tomcat5 service with jrockit
Warning:
rant about 'religion' follows (not quite on par with where the opening '{'
goes, but close!):
I feel like such a fool! I had no idea the way too old mark had been moved
to older than 6 months and/or 3 point releases behind HEAD. Of course,
_everyone_ should _always_ use the most recent version of _every_ software
package, and it's a particularly good idea to use it if it's just been voted
stable within the last 30 days.
Because, we should always trust that there there are no remaining problems in a
newly-declared-as-stable piece of software. That's why 5.0 didn't need 32
point releases, and 5.5 didn't need 23 point releases.
Plus, the maintainers can just finally give up on that antiquated 5.5 branch!
Thanks for your heroic efforts so far, tomcat team.
In the future, I wish people would STFU about get a newer version, unless
they specifically know that the bug someone is asking about (and in this
case, perhaps not even a bug) has been fixed in a newer version. The sooner
people like Mr. Burrus understand that some people are unable or unwilling to
upgrade to the latest and greatest, the sooner my blood pressure will return
to normal.
There, _I_ feel better. anyone else?
signed,
A completely satisifed tomcat 5.0.29 user.
(so there)
From: Mr. Steve Burrus [mailto:[EMAIL PROTECTED]
Sent: Mon 3/12/2007 4:59 PM
To: Tomcat Users List
Subject: Re: Cannot start tomcat5 service with jrockit
look you say that your Tomcat version is 5.5.20. Why don't u
simply try/attempt to get version 6.x of Tomcat by now??? I mean any
kind of version 5 is way too old by now! Capiche? [Understand?]
Igor Shevchenko wrote:
Hello,
I'm experiencing problems with starting tomcat as a service under Win2003
server with jrockit jvm.
Tomcat version is 5.5.20 and it starts successfully using startup.bat
script, but when trying to start it as a service I have the following
output in jakarta-service log:
[2007-03-12 04:45:48] [info] Running Service...
[2007-03-12 04:45:48] [info] Starting service...
[2007-03-12 04:45:48] [173 javajni.c] [error] The specified module could
not be found.
[2007-03-12 04:45:48] [924 prunsrv.c] [error] Failed creating java
C:\jrockit-R27.1.0-jdk1.5.0_08\jre\bin\jrockit\jvm.dll
[2007-03-12 04:45:48] [1179 prunsrv.c] [error] ServiceStart returned 1
[2007-03-12 04:45:48] [info] Run service finished.
[2007-03-12 04:45:48] [info] Procrun finished.
I've tried googling and reading mailing archives but couldn't find a
solution.
Best regards,
---
Igor Shevchenko
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: How do I print out line of code that caused the error?
Respectfully, I submit that the problem is that something works less well
when comparing 5.5 and 5.0
On 5.0.29, the original poster's page provides this error output:
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: 2 in the jsp file: /foobar.jsp
Generated servlet error:
/usr/local/apps/tomcat-5.0.29/work/Catalina/www.foo.com/_/org/apache/jsp/foobar_jsp.java:52:
incompatible types
found : java.lang.Object
required: java.lang.String
String v1 = session.getAttribute(attr);
^
which accurately locates both the 'compiled' source error (line 52 of
/org/apache/jsp/foobar_jsp) *and* identifies and echos the offending line.
It inaccurately identifies the error as occuring on line 2 of the JSP.
I've just installed 5.5.20 and tried out the patch from this website
(previously discussed on this list):
http://www.tfenne.com/jasper/
Unfortunately, I can't get it to work, so I'm either doing something wrong, or
it won't work with 5.5.20
For shiggles, I tried the following source JSP:
%@ page import=java.util.* %
% %
%Object v = new String(b);%
%session.setAttribute(a, v);%
% %
%Enumeration e = session.getAttributeNames(); %
%while (e.hasMoreElements()) { %
%String attr = (String) e.nextElement(); %
%String v1 = session.getAttribute(attr); %
%String v2 = session.getValue(attr); %
%out.println(attr: + attr + v1: + v1 + v2: +v2 +
BR\n); %
%} %
And the output now correctly labelled the line of the JSP in which the error
occured, but again it neither outputs the line in the 'compiled' source nor
echoes the actual line in error, as it did under 5.0.x. Plus, who wants to
write JSP's like that?
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: 9 in the jsp file: /index.jsp
Generated servlet error:
Type mismatch: cannot convert from Object to String
An error occurred at line: 10 in the jsp file: /index.jsp
Generated servlet error:
Type mismatch: cannot convert from Object to String
From: Robert Harper [mailto:[EMAIL PROTECTED]
Sent: Tue 11/28/2006 1:42 PM
To: 'Tomcat Users List'
Subject: RE: How do I print out line of code that caused the error?
The problem is that the JSP is not compiled on the browser. Even if it was,
you would be bound on functionality provided by the particular browser. The
servlet container might send an error in the response but that would be up
to the container provider as well. Because these behaviors are not bound by
standards, you can't count on them to always be there if you once had what
you want. There should be server side logs that will show your problem.
Robert S. Harper
Information Access Technology, Inc.
-Original Message-
From: D. Alvarado [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 28, 2006 12:32 PM
To: Tomcat Users List
Subject: Re: How do I print out line of code that caused the error?
Thanks. So there's absolutely no way within the web browser to print
out the line of code that caused the error? In the example, the line
i would've liked to see in the web browser would have been:
String v1 = session.getAttribute(attr);
Thanks, - Dave
On 11/28/06, Edoardo Panfili [EMAIL PROTECTED] wrote:
D. Alvarado ha scritto:
Hi, I'm using Tomcat 5.5 with Apache 2. Upon getting jsp compilation
errors, I'm not told any inofrmation about the code the causaed the
error and the line printed is incorrect. What do I need to configure
to correct this? For example, this page below:
%@ page import=java.util.* %
%
Object v = new String(b);
session.setAttribute(a, v);
Enumeration e = session.getAttributeNames();
while (e.hasMoreElements()) {
String attr = (String) e.nextElement();
String v1 = session.getAttribute(attr);
session.getAttribute(String) returns an Object
try:
String v1 = (String) session.getAttribute(attr);
String v2 = session.getValue(attr);
out.println(attr: + attr + v1: + v1 + v2: +
v2 + BR\n);
} // while
%
causes this error. You can eventually figure out the problem, but
line 2 is not right.
=begin error
type Exception report
message
description The server encountered an internal error () that prevented
it from fulfilling this request.
exception
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: 2 in the jsp file: /session_vars.jsp
Generated servlet error:
Type mismatch: cannot convert from Object to String
An error occurred at line: 2 in the jsp file: /session_vars.jsp
Generated servlet error:
Type mismatch: cannot convert from Object to String
RE: How do I print out line of code that caused the error?
Well, since my first email, I read the bugzilla (
http://issues.apache.org/bugzilla/show_bug.cgi?id=37062 ) attached to that
website, and apparently this patch was committed to 5.5.13. But... I can't get
it to work. I may or may not have the same problem as the last commentor.
Perhaps I'm not aware of how to put tomcat into development mode.
I've tried putting a context file here:
$CATALINE_HOME\conf\Catalina\localhost\foobar.xml
with :
Context reloadable=true
/Context
And then accessing http://localhost:8080/foobar/index.jsp (index.jsp being the
page that contains the error)
Tomcat doesn't complain about anything on stdout when starting (so assume I got
the context file correct), but it also doesn't show me anything different in
the stacktrace (and yes, I backed out any patched classes I did). So unless
there's some other incantation to put Tomcat into the correct mood ... 5.5.x
compilation error messages are simply not as helpful as 5.0 compilation errors.
While being aware that they are configured quite differently, the 5.x tomcats
support the same JSP/Servlet spec version, so perhaps you can use 5.0 in a
development environment and use 5.5 for production?
From: D. Alvarado [mailto:[EMAIL PROTECTED]
Sent: Tue 11/28/2006 2:56 PM
To: Tomcat Users List
Subject: Re: How do I print out line of code that caused the error?
Wow, how rare that a newer version should lose this feature. So the
answer then, if I want the code and the correct line printed out is to
revert to Tomcat 5.0? - Dave
On 11/28/06, gb1071nx [EMAIL PROTECTED] wrote:
Respectfully, I submit that the problem is that something works less well
when comparing 5.5 and 5.0
On 5.0.29, the original poster's page provides this error output:
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: 2 in the jsp file: /foobar.jsp
Generated servlet error:
/usr/local/apps/tomcat-5.0.29/work/Catalina/www.foo.com/_/org/apache/jsp/foobar_jsp.java:52:
incompatible types
found : java.lang.Object
required: java.lang.String
String v1 = session.getAttribute(attr);
^
which accurately locates both the 'compiled' source error (line 52 of
/org/apache/jsp/foobar_jsp) *and* identifies and echos the offending line.
It inaccurately identifies the error as occuring on line 2 of the JSP.
I've just installed 5.5.20 and tried out the patch from this website
(previously discussed on this list):
http://www.tfenne.com/jasper/
Unfortunately, I can't get it to work, so I'm either doing something wrong,
or it won't work with 5.5.20
For shiggles, I tried the following source JSP:
%@ page import=java.util.* %
% %
%Object v = new String(b);%
%session.setAttribute(a, v);%
% %
%Enumeration e = session.getAttributeNames(); %
%while (e.hasMoreElements()) { %
%String attr = (String) e.nextElement(); %
%String v1 = session.getAttribute(attr); %
%String v2 = session.getValue(attr); %
%out.println(attr: + attr + v1: + v1 + v2: +v2 +
BR\n); %
%} %
And the output now correctly labelled the line of the JSP in which the error
occured, but again it neither outputs the line in the 'compiled' source nor
echoes the actual line in error, as it did under 5.0.x. Plus, who wants to
write JSP's like that?
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: 9 in the jsp file: /index.jsp
Generated servlet error:
Type mismatch: cannot convert from Object to String
An error occurred at line: 10 in the jsp file: /index.jsp
Generated servlet error:
Type mismatch: cannot convert from Object to String
From: Robert Harper [mailto:[EMAIL PROTECTED]
Sent: Tue 11/28/2006 1:42 PM
To: 'Tomcat Users List'
Subject: RE: How do I print out line of code that caused the error?
The problem is that the JSP is not compiled on the browser. Even if it was,
you would be bound on functionality provided by the particular browser. The
servlet container might send an error in the response but that would be up
to the container provider as well. Because these behaviors are not bound by
standards, you can't count on them to always be there if you once had what
you want. There should be server side logs that will show your problem.
Robert S. Harper
Information Access Technology, Inc.
-Original Message-
From: D. Alvarado [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 28, 2006 12:32 PM
To: Tomcat Users List
Subject: Re: How do I print out line of code that caused the error?
Thanks. So there's absolutely no way within the web browser to print
out the line of code that caused the error? In the example, the line
i would've liked to see in the web browser would have been
Tomcat won't die: Help with interpreting this thread dump
Hello and apologies in advance for the HTML formatting (not sure how to turn it off in outlook web access). Our tomcat was non-responsive, and catalina.out had several 'java.lang.OutOfMemory' errors. So this isn't totally unknown to us (our apps leak a bit of memory, plus we're running on a small JVM). I tried to shutdown tomcat and it wouldn't die. Doing a kill -3 (before the eventual kill -9) I got a thread dump. Almost all the TP threads look like this: - TP-Processor44 daemon prio=1 tid=0x09667438 nid=0xd95 in Object.wait() [b2bfe000..b2bff8d8] at java.lang.Object.wait(Native Method) - waiting on 0x45251bb0 (a sun.misc.SoftCache) at java.lang.Object.wait(Object.java:429) at java.util.ResourceBundle.findBundle(ResourceBundle.java:862) - locked 0x45251bb0 (a sun.misc.SoftCache) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:730) at java.util.ResourceBundle.getBundle(ResourceBundle.java:538) at sun.text.resources.LocaleData$1.run(LocaleData.java:113) at java.security.AccessController.doPrivileged(Native Method) at sun.text.resources.LocaleData.getBundle(LocaleData.java:111) at sun.text.resources.LocaleData.getDateFormatZoneData(LocaleData.java:107) at java.text.DateFormatSymbols.cacheLookup(DateFormatSymbols.java:430) at java.text.DateFormatSymbols.initializeData(DateFormatSymbols.java:468) at java.text.DateFormatSymbols.init(DateFormatSymbols.java:103) at java.text.SimpleDateFormat.init(SimpleDateFormat.java:442) at org.apache.coyote.tomcat5.CoyoteRequest.init(CoyoteRequest.java:151) at org.apache.coyote.tomcat5.CoyoteConnector.createRequest(CoyoteConnector.java:1230) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:131) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:300) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:374) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) - So, Tomcat code is waiting for some other code (my code) to release a lock? - waiting on 0x45251bb0 (a sun.misc.SoftCache) Is that the correct interpretation? If so, I'd need to find a stacktrace that contains *my* code that has this object locked? Because I did find one, but I'm not sure what it's telling me. Or can anything be told, since the VM threw an OOME and now all bets are off? www.foo.com http://www.foo.com - /prod/order.jsp?orderID=225 daemon prio=1 tid=0x080ac938 nid=0x5f1a in Object.wait() [b61fd000..b61ff8d8] at java.lang.Object.wait(Native Method) - waiting on 0x45251bb0 (a sun.misc.SoftCache) at java.lang.Object.wait(Object.java:429) at java.util.ResourceBundle.findBundle(ResourceBundle.java:862) - locked 0x45251bb0 (a sun.misc.SoftCache) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:730) at java.util.ResourceBundle.getBundle(ResourceBundle.java:538) at sun.text.resources.LocaleData$1.run(LocaleData.java:113) at java.security.AccessController.doPrivileged(Native Method) at sun.text.resources.LocaleData.getBundle(LocaleData.java:111) at sun.text.resources.LocaleData.getDateFormatZoneData(LocaleData.java:107) at java.text.DateFormatSymbols.cacheLookup(DateFormatSymbols.java:430) at java.text.DateFormatSymbols.initializeData(DateFormatSymbols.java:468) at java.text.DateFormatSymbols.init(DateFormatSymbols.java:103) at java.text.SimpleDateFormat.init(SimpleDateFormat.java:442) at java.util.Date.toString(Date.java:981) at java.lang.String.valueOf(String.java:2131) at java.lang.StringBuffer.append(StringBuffer.java:370) - locked 0x4b94e2e8 (a java.lang.StringBuffer) at com.xx.LineItem.setProductionDate(LineItem.java:1181) at com.xx.ItemGroup.setProductionDate(ItemGroup.java:1468) at com.xx.ItemGroup.addLineItem(ItemGroup.java:126) at com.xx.OrderHistory.load(OrderHistory.java:445) at com.xx.OrderHistory.init(OrderHistory.java:201) at org.apache.jsp.prod.order_jsp._jspService(order_jsp.java:174) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at
