AUTO 'Case=931-208'cvs commit: jakarta-tomcat-connectors/jni/native/src pool.c shm.c
Thank you for writing to Baazee.com. This is to acknowledge that we have received your email and we expect to give you a positive response in the next 48 hours. At times it may take more than 48 hours, however you can be assured that we are working to give you the response at the earliest. This is an acknowledgement and hence request not to reply to this email. Thanking you, Baazee Community Care - The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. In such case, you should destroy this message and kindly notify the sender by reply email. Baazee sends e-mails using the domain baazee.com (@baazee.com) and hence any mails received from any other e-mail id except the one mentioned above and stating information about Baazee policies and procedures should be ignored and immediately brought to the attention of the Baazee team. Opinions, conclusions and other information in this message that do not relate to the official business of Baazee.com shall be understood as neither given by the Company nor endorsed by it.
DO NOT REPLY [Bug 33371] - Errors are not reported to user code (servlets).
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33371. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33371 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 09:36 --- As long as setErrorException is set on the response, the exception will be rethrown to the servlet, so it should be ok then. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33357] - DataSourceRealm leaks connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33357.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33357
--- Additional Comments From [EMAIL PROTECTED] 2005-02-03 10:28 ---
(In reply to comment #5)
Why not ...
Do you know the purpose of the
if( !dbConnection.getAutoCommit() ) {
dbConnection.commit();
}
which was in the code before ? I do not see any writes being made.
I'll look into it (by forcing autoCommit off) and let you know if it might have
any impact.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33357] - DataSourceRealm leaks connections
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33357. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33357 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #14165|0 |1 is obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 10:56 --- Created an attachment (id=14168) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14168action=view) o.a.c.realm.DataSourceRealm Indeed, according to jdbc specs, some resources (locks particularly) might not get released when leaving the connection uncommited. I added the required block back in a single place, just before closing the dbConnection (or should I say returning to the pool) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33385] New: - Tags are duplicating the generated HTML
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33385 Summary: Tags are duplicating the generated HTML Product: Tomcat 5 Version: 5.5.4 Platform: PC OS/Version: Windows XP Status: NEW Severity: critical Priority: P1 Component: Jasper AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] I am having a JSP which is composed of three tags. When I access my JSP for the first time after starting my tomcat(5.5.4),the JSP generates(and hence the browser displsys :-)) the HTML properly. However,after resubmitting the JSP,the HTML generated by one of my tags gets duplicated and the whole HTML is doubled in output( e.g one pair of TR and TD is shown as two pairs of TR and TD.).If keep reftreshing/resubmitting my JSP,the HTML output just keeps on multiplying !!! However,when I replace the jar files 1)jasper-compiler.jar and 2)jasper- runtime.jar present in the D:\Program Files\jakarta-tomcat-5.5.4\common\lib directory with the older versions of these files from Tomcat version 4.0.1 and remove the jar file jasper-compiler-jdt.jar,then the problem gets resolved. Also,if I clear the Tomcat's work direcroy for my web application,then the JSP gives proper output on the first hit but the problem starts after second and subsequent hits. I am ensuring from my side that there is no problem with my Tags or my JSP since that used to work in earlier versions of Tomcat(and still working with new Tomcat5.5.4 after changing the jasper jar files as explained above). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33385] - Tags are duplicating the generated HTML
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33385 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 12:46 --- Your tag is likely not compatible with tag reuse. Please consult the specification about tag lifecycle, and see configuration options about tag reuse. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33385] - Tags are duplicating the generated HTML
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33385 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 12:55 --- Also see http://jakarta.apache.org/tomcat/faq/misc.html#tagbroken -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work
Al, I read it thoroughly. Remy Maucharat didn't mention the platform he had tested on until the 7th post and by then Yoav Shapira had already stated that he tested it as well (with no mention of the platform). They also agreed that the case would be re-opened if you could help them to reproduce the problem. My criticism is that you mentioned a developer from the users list who also claimed to have problems shutting down Tocmat which would seem to bolster your case -- except that he never mentioned whether or not he was starting his own threads in his application. You did not, however, mention that I tested on the exact same distribution that you're having problems on with a fresh download of TC and it ran fine. If you're serious about getting to the root of the problem, which I think you are, it's important that all facts are on the table -- even the ones that don't support your argument. -Ben On Thu, 2005-02-03 at 01:43, Al Sutton wrote: Ben, Please re-read my email. It is discussing the initial response I received from the -dev list, and then addressing the issue raised about it being distribution specific. My critisism was that the bug was initially closed when the only attempt to re-produce it I was made aware of was made on a completely different platform and that it initially appeared that the -dev list did not have developers that were willing to investigate the problem. Regards, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 22:25 To: Tomcat Developers List Subject: RE: DO NOT REPLY [Bug 9] - Shutdown script down not work On Wed, 2005-02-02 at 16:54, Al Sutton wrote: In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say Sorry, no-one has FC2, rather than Closed bug, doesn't work on [insert name of totally different platform here]. The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. Just for the record, I tested on FC2 and posted the shell session on the users list. You responded to my email before writing this message. I've also stated that I'm willing to upgrade both the kernel and the JDK to test under an environment that is closer to yours. Please don't omit these details when when writing to either list. At the very least, it's dishonest, at worst it's misleading and could cause people to waste time repeating things that have already been done. -Ben - 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: The FIX - Shutdown not working under SLES8 and FC2
Well I configure my production tomcat to only listen on localhost 127.0.0.1 BTW, be carefull on some Suse system localhost is ::1, so an IPv6 address. As such you should make use of 127.0.0.1 in both server.xml and also in the stop script On Thu, 3 Feb 2005 11:14:01 +0100, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts you've got a strange config, it's your problem, I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address=127.0.0.1 to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine. I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh). Thanks again, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 23:32 To: Tomcat Users List Subject: RE: Shutdown not working under SLES8 and FC2 On Wed, 2005-02-02 at 17:11, Ben Souther wrote: On Wed, 2005-02-02 at 16:43, Al Sutton wrote: Hmmm The latest updates gives me; Linux host 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686 athlon i386 GNU/Linux and I'm on JDK 1.4.2_06 as opposed to _05. Would it be possible for you to upgrade?, I'd like to have the exact same environment, but please don't put yourself out or risk a critical environment. OK, here you go. It turns out that I did have _06 on this machine. I also have 2.6.10-1.9_FC2 (which is no longer the latest BTW ;)). Once again, I started and stopped without a problem. Here is the screen dump: [EMAIL PROTECTED] bin]$ uname -a Linux bsouther 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686 athlon i386 GNU/Linux [EMAIL PROTECTED] bin]$ export JAVA_HOME=/usr/local/j2sdk1.4.2_06 [EMAIL
DO NOT REPLY [Bug 33385] - Tags are duplicating the generated HTML
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33385 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 14:21 --- Thanks a lot.The problem has been resolved I was storing some data in the private member variables of my Tag which were not being reset after the doEndTag() was called. So I reset all the state variables of my class after the doEndTag() and the problem got solved. But the fact that this used to work in Tomcat 4.0.1 means that 4.0.1. did not have tag pooling concept. Can anyone tell me from which version onwards did this Tag reuse/pooling was introduced in Tomcat.Or for that matter,when was it made a part of Servlet/JSP specificaion by Sun. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33385] - Tags are duplicating the generated HTML
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33385. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33385 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 14:38 --- Tag pooling was always allowed as part of the JSP spec. Tomcat 4.1 introduced tag pooling with jasper2. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-site/docs/articles benchmark_summary.pdf
remm2005/02/03 07:12:27
Modified:docs resources.html
xdocs-faq tomcat-faq.xsl
xdocsresources.xml
Added: docs/articles benchmark_summary.pdf
Log:
Add Peter's new article.
Revision ChangesPath
1.32 +6 -0 jakarta-tomcat-site/docs/resources.html
Index: resources.html
===
RCS file: /home/cvs/jakarta-tomcat-site/docs/resources.html,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- resources.html3 Jan 2005 20:15:34 - 1.31
+++ resources.html3 Feb 2005 15:12:26 - 1.32
@@ -206,6 +206,12 @@
ul
li
b
+a href=articles/benchmark_summary.pdfSo Much Static/a
+/b,
+ by Peter Lin
+/li
+li
+ b
a href=http://johnturner.com/howto/apache-tomcat-howto.html;mod_jk
HOWTOs/a
/b,
by John Turner. Please note that this is one of many documents
explaining how to
1.3 +2 -2 jakarta-tomcat-site/xdocs-faq/tomcat-faq.xsl
Index: tomcat-faq.xsl
===
RCS file: /home/cvs/jakarta-tomcat-site/xdocs-faq/tomcat-faq.xsl,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- tomcat-faq.xsl30 Dec 2004 16:37:09 - 1.2
+++ tomcat-faq.xsl3 Feb 2005 15:12:27 - 1.3
@@ -194,7 +194,7 @@
xsl:commentPAGE FOOTER/xsl:comment
trtd colspan=2
div align=centerfont color={$body-link} size=-1em
-Copyright #169; 1999-2003, Apache Software Foundation
+Copyright #169; 1999-2005, Apache Software Foundation
/em/font/div
/td/tr
1.12 +4 -0 jakarta-tomcat-site/xdocs/resources.xml
Index: resources.xml
===
RCS file: /home/cvs/jakarta-tomcat-site/xdocs/resources.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- resources.xml 5 Apr 2004 17:06:12 - 1.11
+++ resources.xml 3 Feb 2005 15:12:27 - 1.12
@@ -31,6 +31,10 @@
ul
li
+ ba href=articles/benchmark_summary.pdfSo Much Static/a/b,
+ by Peter Lin
+/li
+li
ba
href=http://johnturner.com/howto/apache-tomcat-howto.html;mod_jk
HOWTOs/a/b,
by John Turner. Please note that this is one of many documents
explaining how to
connect Apache HTTPD and Tomcat in various environment. A list is
maintained in
1.1 jakarta-tomcat-site/docs/articles/benchmark_summary.pdf
Binary file
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm LocalStrings.properties DataSourceRealm.java
remm2005/02/03 07:14:34
Modified:catalina/src/share/org/apache/catalina/realm
LocalStrings.properties DataSourceRealm.java
Log:
- 33357: Should fix connection leaks with the DataSourceRealm, as well as
improve efficiency.
- I only casually reviewed this.
- Submitted by Dominik Drzewiecki.
Revision ChangesPath
1.11 +3 -3
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/LocalStrings.properties
Index: LocalStrings.properties
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/LocalStrings.properties,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- LocalStrings.properties 15 Jan 2005 17:04:38 - 1.10
+++ LocalStrings.properties 3 Feb 2005 15:14:34 - 1.11
@@ -67,6 +67,6 @@
dataSourceRealm.authenticateSuccess=Username {0} successfully authenticated
dataSourceRealm.close=Exception closing database connection
dataSourceRealm.exception=Exception performing authentication
-datasourceRealm.getPassword.exception=Exception retrieving password for {0}
-datasourceRealm.getRoles.exception=Exception retrieving roles for {0}
+dataSourceRealm.getPassword.exception=Exception retrieving password for {0}
+dataSourceRealm.getRoles.exception=Exception retrieving roles for {0}
dataSourceRealm.open=Exception opening database connection
1.12 +117 -112
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/DataSourceRealm.java
Index: DataSourceRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/realm/DataSourceRealm.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- DataSourceRealm.java 23 Nov 2004 23:14:09 - 1.11
+++ DataSourceRealm.java 3 Feb 2005 15:14:34 - 1.12
@@ -268,8 +268,13 @@
* authenticating this username
*/
public Principal authenticate(String username, String credentials) {
-
-Connection dbConnection = null;
+
+ // No user - can't possibly authenticate, don't bother the database then
+ if (username == null) {
+ return null;
+ }
+
+ Connection dbConnection = null;
try {
@@ -279,34 +284,19 @@
// If the db connection open fails, return not
authenticated
return null;
}
-
+
// Acquire a Principal object for this user
-Principal principal = authenticate(dbConnection,
- username, credentials);
-
-if( !dbConnection.getAutoCommit() ) {
-dbConnection.commit();
-}
-
-// Release the database connection we just used
-close(dbConnection);
-dbConnection = null;
-
-// Return the Principal (if any)
-return (principal);
-
+return authenticate(dbConnection, username, credentials);
+
} catch (SQLException e) {
-
// Log the problem for posterity
container.getLogger().error(sm.getString(dataSourceRealm.exception), e);
-// Close the connection so that it gets reopened next time
-if (dbConnection != null)
-close(dbConnection);
-
// Return not authenticated for this request
return (null);
+} finally {
+ close(dbConnection);
}
}
@@ -329,14 +319,9 @@
*/
protected Principal authenticate(Connection dbConnection,
String username,
- String credentials) {
+ String credentials) throws
SQLException{
-// No user - can't possibly authenticate
-if (username == null) {
-return (null);
-}
-
-String dbCredentials = getPassword(username);
+String dbCredentials = getPassword(dbConnection, username);
// Validate the user's credentials
boolean validated = false;
@@ -351,13 +336,13 @@
container.getLogger().trace(sm.getString(dataSourceRealm.authenticateSuccess,
username));
} else {
-if (container.getLogger().isDebugEnabled())
+if (container.getLogger().isTraceEnabled())
container.getLogger().trace(sm.getString(dataSourceRealm.authenticateFailure,
username));
DO NOT REPLY [Bug 33373] - jspc precompiling jsp with absolute uri in taglib fails
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33373. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33373 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 16:15 --- excellent point :) i downloaded 5.5.7-src.zip and am able to compile it under cygwin on win xp. you are correct that the jsp-examples precompile correctly. once it had all compiled successfully, i dropped one new .jsp into the .../jakarta-tomcat-5.5.7-src/jakarta-servletapi-5/jsr152/examples/tagplugin directory. this jsp is named aaa_breaks_jspprecompile.jsp and contains has one line it: h3no taglib uri reference in first file alphabetically makes jspc die/h3 (note there is no reference to a taglib) i then did a touch *.jsp in that tagplugin directory to make all the .jsp's out of date and re-ran ant and sure enough i get: build-webapps-precompile: BUILD FAILED C:\workspace\toolbelt\tomcat\jakarta-tomcat-5.5.7-src\build.xml:50: The followin g error occurred while executing this line: C:\workspace\toolbelt\tomcat\jakarta-tomcat-5.5.7-src\jakarta-tomcat-5\build.xml :767: The following error occurred while executing this line: C:\workspace\toolbelt\tomcat\jakarta-tomcat-5.5.7-src\jakarta-tomcat-5\build.xml :372: org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/j sp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application i know this sounds crazy, but it appears that as long as the first .jsp file (sorted alphabetically) in any given directory of a webapp does NOT use taglibs, then no other jsp in that same directory that uses taglibs will precompile. hopefully it's easy for you to create the aaa_breaks_jspprecompile.jsp file in the above mentioned directory and replicate the problem in your own build environment. i apologize for not attaching a war file but demonstrating the problem only requires this single .jsp and a touch *.jsp so that all files in that subdir are marked as out of date. thanks! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work
Ben, I made the comments I did largely because of the attitude shown in the initial responses I received upon reporting the bug. Responses such as the following made me beleive no-one on the -dev list actually cared about fixing the problem; - This is always because your code or libraries used by it start and don't terminate non-daemon threads (and then closing the bug as invalid) - which is incorrect as I've now prooved. - Well, I just tested it, and wasted my time ;) (and then closing the bug as invalid) - after testing on completely the wrong platform. - two people (myself being the second) have confirmed that this issue is not reproducible - again incorrect, as you mentioned at least one other person reproduced the issue and I have reproduced on two seperate machines. - don't write statements like which seems to show there are a lot of threads waiting on an object. This doesn't make any sense, and makes the credibility of the report go down. - The original statement is perfectly valid, has been used by many people in many discussions, and originates from Suns own documentation and guidelines. - I just tested with Ubuntu Hoary and Sun JRE 1.5.0_01. Both startup.sh and shutdown.sh work as expected, and Tomcat runs great. - Wrong platform and JDK again. It wasn't until you became involved that there appeared to be any sign of anyone taking this issue seriously. As I hope you can understand I was becomming increasingly frustrated and therefore focused on trying to show how it could be reproduced rather than providing fuel for what seemed to be the prevalent attitude of Doesn't work on my box, not interested. I have since made a post with what I beleive to be potential fixes to resolve the problem. Regards, Al. Ben Souther [EMAIL PROTECTED] wrote on 03.02.2005, 13:14:13: Al, I read it thoroughly. Remy Maucharat didn't mention the platform he had tested on until the 7th post and by then Yoav Shapira had already stated that he tested it as well (with no mention of the platform). They also agreed that the case would be re-opened if you could help them to reproduce the problem. My criticism is that you mentioned a developer from the users list who also claimed to have problems shutting down Tocmat which would seem to bolster your case -- except that he never mentioned whether or not he was starting his own threads in his application. You did not, however, mention that I tested on the exact same distribution that you're having problems on with a fresh download of TC and it ran fine. If you're serious about getting to the root of the problem, which I think you are, it's important that all facts are on the table -- even the ones that don't support your argument. -Ben On Thu, 2005-02-03 at 01:43, Al Sutton wrote: Ben, Please re-read my email. It is discussing the initial response I received from the -dev list, and then addressing the issue raised about it being distribution specific. My critisism was that the bug was initially closed when the only attempt to re-produce it I was made aware of was made on a completely different platform and that it initially appeared that the -dev list did not have developers that were willing to investigate the problem. Regards, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 22:25 To: Tomcat Developers List Subject: RE: DO NOT REPLY [Bug 9] - Shutdown script down not work On Wed, 2005-02-02 at 16:54, Al Sutton wrote: In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say Sorry, no-one has FC2, rather than Closed bug, doesn't work on [insert name of totally different platform here]. The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. Just for the record, I tested on FC2 and posted the shell session on the users list. You responded to my email before writing this message. I've also stated that I'm willing to upgrade both the kernel and the JDK to test under an environment that is closer to yours. Please don't omit these details when when writing to either list. At the very least, it's dishonest, at worst it's misleading and could cause people to waste time repeating things that have already been done. -Ben - 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: RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work
I have since made a post with what I beleive to be potential fixes to resolve the problem. I saw that post. All other bantering aside, it's good you found the problem. I hope you will add your findings to the bug report so someone else with a similar problem doesn't have to retrace all of your steps before finding the solution. I realize you were insulted by the tone of the initial responses you received. I wasn't taking sides on that issue. I just wanted to make sure that, in spite of hurt feelings, all the details were accurately reported in every discussion so that someone else researching the same issue six months from now doesn't miss an important detail. Again, I'm glad you found the problem. Congrats :-D -Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31567] - 505 request error from .NET client
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31567. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31567 [EMAIL PROTECTED] changed: What|Removed |Added Severity|blocker |enhancement Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 17:02 --- (In reply to comment #10) Can you please be more specific? What is wrong with the requests from the client? I can't tell if you have issue with data on the original or second request. The orignal request. See RFC 2616 Section 8.2.3. And, like Remy has said many times, this is invalid, so please stop wasting everybody's time by reopening it. Hello folks, I'm having a problem similar to the piotr's one, but in a different context and concluded that the .net client does not have a bad behavior. Tomcat on the other side isn't behaving improperly, but could behave better. Here goes: On section 8.2.3 it states that a client does not need to wait indefinitively for a server to respond with an 100 Continue message before starting to send it's body content of a request with the expect header. The M$ does it, and I believe they do it for performance reasons (perhaps it's a: we ask if we can, but let's starting sending while the response does not come back, we win time if the response is positive) while the spec says that it's ok to do that because of the compatibility with older implementations of HTTP. It also says that if the server starts to receive data from the client, he may ommit the 100 continue response message. Plus, it also says that, when the server refuses an request with the expect header, and already received data it MAY close the transport connection or it MAY to continue read and then discard the rest of the request. So, TOMCAT doesn't do either, but does half of the second MAY. Now, if 505 error occurs because of the data on input stream (the body of the previous request) that is understood as a new request, I believe that the SPEC is not very clear about the issue and perhaps it should be more 'rule- enforcing'. In that case I believe that the server SHOULD close the transport connection OR it SHOULD read all data AND then discard it. Since TOMCAT already reads it (i supose it is the origin of the 505 error), I believe it also should discard it. That would be great for me, since I wouldn't need to add a if-command in my code :) Best regards, Miguel Figueiredo -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33390] New: - service.bat improvements
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33390. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33390 Summary: service.bat improvements Product: Tomcat 5 Version: Unknown Platform: PC OS/Version: Windows 2000 Status: NEW Severity: enhancement Priority: P2 Component: Native:Integration AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] There are 3 improvements that service.bat should have: 1. At the moment if you install a service using service.bat its startup type is manual. This in my opinion is plain wrong because the whole point of a service is that it is run automatically without user intervention. 2. It should be possible to specify the service description using the service.bat. 3. It should be possible to specify addition JVM parameters such as -Xmx256M. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 31567] - 505 request error from .NET client
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31567. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31567 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 17:14 --- It is obviously implied that the client MUST (caps as per the spec) wait a reasonable amount of time (Tomcat will return the 401 response nearly instantaneaously). If it does not, then there's absolutely no point in using expectations, and they should just remove the header. The spec is great and all, but there's little possibility to determine, if a client announces an expectation but doesn't use it (which isn't explicitely forbidden), if more data is subsequent pipelined requests, or if it's the body which was incorrectly sent. I believe Tomcat's behavior is the intended one. If you want the other behavior, you have one line of code to remove (inputBuffer.setSwallowInput(false); in Http11Processor), or add 401 as a disconnect status code. Tomcat reads the rest of the stream as the next request, so the last part of your comment isn't accurate. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 33339] - Shutdown script down not work
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=9. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=9 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|CLOSED --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 17:35 --- This problem is due to the short hostname not resolving to a local IP address. There are two simple fixes for this; 1) Add address=127.0.0.1 to the definition of the JK Connector in server.xml 2) If your machine is called x.y.z.com the name x must resolve to a local IP address. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c
I assume this is going to be a compile/configure time option ? What about using a different approach - generate multiple .so files, one with common/base/non-optional functionality, and one for each optional library. Compile time options makes it hard to distribute compiled binaries and add more requirements. Costin [EMAIL PROTECTED] wrote: mturk 2005/02/02 23:47:49 Added: jni/native/src ssl.c Log: Add OpenSSL support. Revision ChangesPath 1.1 jakarta-tomcat-connectors/jni/native/src/ssl.c Index: ssl.c === /* Copyright 2000-2004 The Apache Software Foundation * * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an AS IS BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ #include apr.h #include apr_pools.h #include apr_file_io.h #include tcn.h #ifdef HAVE_OPENSSL /* OpenSSL headers */ #include openssl/ssl.h #include openssl/err.h #include openssl/x509.h #include openssl/pem.h #include openssl/crypto.h #include openssl/evp.h #include openssl/rand.h #include openssl/x509v3.h /* Avoid tripping over an engine build installed globally and detected * when the user points at an explicit non-engine flavor of OpenSSL */ #if defined(HAVE_OPENSSL_ENGINE_H) defined(HAVE_ENGINE_INIT) #include openssl/engine.h #endif #else #endif - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The FIX - Shutdown not working under SLES8 and FC2
What about: - add this information to the bug report - send a patch to the FAQ or edit a wiki page ( well, the tc wiki is not very used, but probably google will find this if anyone has a similar problem ). Or post it in your weblog/site/etc for google to find. It should be obvious changing the default configuration only to deal with this case won't happen. If a computer can't locate itself by name - you'll have a lot of other problems. Costin ( BTW - if you plan to participate in any open source project - be prepared for a lot of hurt feelings and negative comments, if you can't handle it, stay out. It happens to all of us. Track the problem, send a patch and friendly reminders if it gets ignored - and be prepared to accept a 'no' ) [EMAIL PROTECTED] wrote: After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts you've got a strange config, it's your problem, I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address=127.0.0.1 to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine. I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh). Thanks again, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 23:32 To: Tomcat Users List Subject: RE: Shutdown not working under SLES8 and FC2 On Wed, 2005-02-02 at 17:11, Ben Souther wrote: On Wed, 2005-02-02 at 16:43, Al Sutton wrote: Hmmm The latest updates gives me; Linux host 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686 athlon i386 GNU/Linux and I'm on JDK 1.4.2_06 as opposed to _05. Would it be possible for you to upgrade?, I'd like to have the exact same environment, but please don't put yourself out or risk a critical environment. OK, here you go. It turns out that I did have _06 on this machine. I also have 2.6.10-1.9_FC2 (which is no longer the latest BTW ;)). Once again, I started and stopped without a problem. Here is the screen dump:
DO NOT REPLY [Bug 33370] - On Tomcat 4.1.24, this works fine but with Tomcat 5, I experience the following
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33370. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33370 --- Additional Comments From [EMAIL PROTECTED] 2005-02-03 18:52 --- Can you provide me with the URL to the Tomcat: user list? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: The FIX - Shutdown not working under SLES8 and FC2
If no address is configured, ChannelSocket attempts the shutdown on InetAddress.getLocalHost(). Personally, I'm not inclined to change this as it points to a network configuration problem if this is unreachable. However, you might try complaining to Sun about how they have implemented getLocalHost on SLES8. - Original Message - From: [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Cc: tomcat-dev@jakarta.apache.org Sent: Thursday, February 03, 2005 2:14 AM Subject: The FIX - Shutdown not working under SLES8 and FC2 After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts you've got a strange config, it's your problem, I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address=127.0.0.1 to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine. I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh). Thanks again, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 23:32 To: Tomcat Users List Subject: RE: Shutdown not working under SLES8 and FC2 On Wed, 2005-02-02 at 17:11, Ben Souther wrote: On Wed, 2005-02-02 at 16:43, Al Sutton wrote: Hmmm The latest updates gives me; Linux host 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686 athlon i386 GNU/Linux and I'm on JDK 1.4.2_06 as opposed to _05. Would it be possible for you to upgrade?, I'd like to have the exact same environment, but please don't put yourself out or risk a critical environment. OK, here you go. It turns out that I did have _06 on this machine. I also have 2.6.10-1.9_FC2 (which is no longer the latest BTW ;)). Once again, I started and stopped without a problem. Here is the screen dump: -- -- [EMAIL PROTECTED] bin]$ uname -a Linux bsouther 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57
RE: The FIX - Shutdown not working under SLES8 and FC2
Is there any reason why it doesn't try localhost first? Using localhost before anything else would have the following benefits; a) Would ensure that only really strange network configs would be affected (i.e. those where localhost is not the local host). b) Make use of the speed advantage some OS's have in their implementation of the loopback address. c) Avoid any wacky differences in the implementation of InetAddress.getLocalHost() between JVMs/OSs/etc. Off the top off my head I can't see the advantages of using the result of InetAddress.getLocalHost() first. Al. -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: 03 February 2005 19:11 To: Tomcat Developers List Subject: Re: The FIX - Shutdown not working under SLES8 and FC2 If no address is configured, ChannelSocket attempts the shutdown on InetAddress.getLocalHost(). Personally, I'm not inclined to change this as it points to a network configuration problem if this is unreachable. However, you might try complaining to Sun about how they have implemented getLocalHost on SLES8. - Original Message - From: [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Cc: tomcat-dev@jakarta.apache.org Sent: Thursday, February 03, 2005 2:14 AM Subject: The FIX - Shutdown not working under SLES8 and FC2 After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts you've got a strange config, it's your problem, I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address=127.0.0.1 to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine. I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh). Thanks again, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 23:32 To: Tomcat Users List Subject: RE: Shutdown not working under SLES8 and FC2 On Wed, 2005-02-02 at 17:11, Ben Souther wrote: On Wed,
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm DataSourceRealm.java LocalStrings.properties
markt 2005/02/03 14:47:07
Modified:catalina/src/share/org/apache/catalina/realm
DataSourceRealm.java LocalStrings.properties
Log:
Port fix for bug 33357 from TC5.
- Fixes connection leaks
- Improves efficiency
- Submitted by Dominik Drzewiecki
Revision ChangesPath
1.5 +100 -88
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/DataSourceRealm.java
Index: DataSourceRealm.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/DataSourceRealm.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- DataSourceRealm.java 27 Nov 2004 18:29:44 - 1.4
+++ DataSourceRealm.java 3 Feb 2005 22:47:07 - 1.5
@@ -245,6 +245,11 @@
*/
public Principal authenticate(String username, String credentials) {
+// No user - can't possibly authenticate, don't bother the database
then
+if (username == null) {
+return null;
+}
+
Connection dbConnection = null;
try {
@@ -257,32 +262,17 @@
}
// Acquire a Principal object for this user
-Principal principal = authenticate(dbConnection,
- username, credentials);
-
-if( !dbConnection.getAutoCommit() ) {
-dbConnection.commit();
-}
-
-// Release the database connection we just used
-close(dbConnection);
-dbConnection = null;
-
-// Return the Principal (if any)
-return (principal);
+return authenticate(dbConnection, username, credentials);
} catch (SQLException e) {
-
// Log the problem for posterity
log(sm.getString(dataSourceRealm.exception), e);
-// Close the connection so that it gets reopened next time
-if (dbConnection != null)
-close(dbConnection);
-
// Return not authenticated for this request
return (null);
+} finally {
+close(dbConnection);
}
}
@@ -305,17 +295,11 @@
*
* @exception SQLException if a database error occurs
*/
-private Principal authenticate(Connection dbConnection,
- String username,
- String credentials) {
-
+protected Principal authenticate(Connection dbConnection,
+ String username,
+ String credentials) throws SQLException
{
-// No user - can't possibly authenticate
-if (username == null) {
-return (null);
-}
-
-String dbCredentials = getPassword(username);
+String dbCredentials = getPassword(dbConnection, username);
// Validate the user's credentials
boolean validated = false;
@@ -336,7 +320,7 @@
return (null);
}
-ArrayList list = getRoles(username);
+ArrayList list = getRoles(dbConnection, username);
// Create and return a suitable Principal for this user
return (new GenericPrincipal(this, username, credentials, list));
@@ -357,6 +341,9 @@
// Close this database connection, and log any errors
try {
+if (!dbConnection.getAutoCommit()) {
+dbConnection.commit();
+}
dbConnection.close();
} catch (SQLException e) {
log(sm.getString(dataSourceRealm.close), e); // Just log it
here
@@ -386,28 +373,6 @@
/**
- * Return a PreparedStatement configured to perform the SELECT required
- * to retrieve user credentials for the specified username.
- *
- * @param dbConnection The database connection to be used
- * @param username Username for which credentials should be retrieved
- *
- * @exception SQLException if a database error occurs
- */
-private PreparedStatement credentials(Connection dbConnection,
-String username)
-throws SQLException {
-
-PreparedStatement credentials =
-dbConnection.prepareStatement(preparedCredentials.toString());
-
-credentials.setString(1, username);
-return (credentials);
-
-}
-
-
-/**
* Return a short name for this Realm implementation.
*/
protected String getName() {
@@ -422,9 +387,6 @@
*/
protected String getPassword(String username) {
-ResultSet rs =
cvs commit: jakarta-tomcat-4.0 tomcat.nsi
markt 2005/02/03 15:39:18
Modified:.tomcat.nsi
Log:
Fix bug 23277. Make clear WebDAV is one of the exmaple web apps in the windows
installer.
- Also upgraded to use modern UI.
Revision ChangesPath
1.39 +57 -35jakarta-tomcat-4.0/tomcat.nsi
Index: tomcat.nsi
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tomcat.nsi,v
retrieving revision 1.38
retrieving revision 1.39
diff -u -r1.38 -r1.39
--- tomcat.nsi9 Sep 2004 20:46:57 - 1.38
+++ tomcat.nsi3 Feb 2005 23:39:18 - 1.39
@@ -1,6 +1,7 @@
; Tomcat 4 script for Nullsoft Installer
; $Id$
+!include MUI.nsh
Name Apache Tomcat 4.1
OutFile tomcat4.exe
@@ -9,38 +10,31 @@
SetCompressor lzma
SetDatablockOptimize on
-BGGradient 00 80 FF
-InstallColors FF8080 00
-InstProgressFlags smooth colored
-
!include StrFunc.nsh
${StrRep}
-PageEx license
- LicenseText You must read the following license before installing:
- LicenseData INSTALLLICENSE
-PageExEnd
-
-PageEx components
- ComponentText This will install the Apache Tomcat 4.1 servlet container
on your computer:
-PageExEnd
-
-PageEx directory
- DirText Please select a location to install Tomcat 4.1 (or use the
default):
-PageExEnd
+!define MUI_COMPONENTSPAGE_SMALLDESC
+
+!insertmacro MUI_PAGE_LICENSE INSTALLLICENSE
+
+!define MUI_COMPONENTSPAGE_TEXT_TOP This will install the Apache Tomcat 4.1
servlet container on your computer:
+!insertmacro MUI_PAGE_COMPONENTS
+
+!define MUI_DIRECTORYPAGE_TEXT_TOP Please select a location to install
Tomcat 4.1 (or use the default):
+!insertmacro MUI_PAGE_DIRECTORY
+
+!insertmacro MUI_PAGE_INSTFILES
-Page instfiles
Page custom configure : Basic settings
-UninstPage uninstConfirm
-UninstPage instfiles
-
-Icon main.ico
-UninstallIcon uninst.ico
+!insertmacro MUI_UNPAGE_CONFIRM
+!insertmacro MUI_UNPAGE_INSTFILES
+
+!insertmacro MUI_LANGUAGE English
InstType Normal
InstType Minimum
-InstType Full (w/ Source Code)
+InstType Full (with source code)
AutoCloseWindow false
ShowInstDetails show
SetOverwrite on
@@ -49,10 +43,14 @@
InstallDir $PROGRAMFILES\Apache Group\Tomcat 4.1
InstallDirRegKey HKLM SOFTWARE\Apache Group\Tomcat\4.1
-SubSection /e Main
- Section Tomcat (required)
+ReserveFile config.ini
+!insertmacro MUI_RESERVEFILE_INSTALLOPTIONS
+!insertmacro MUI_RESERVEFILE_LANGDLL
-SectionIn 1 2 3
+SubSection /e Main Section1
+ Section Tomcat (required) Section2
+
+SectionIn 1 2 3 RO
SetOutPath $INSTDIR
File tomcat.ico
@@ -78,7 +76,7 @@
SectionEnd
- Section NT Service (NT/2k/XP only)
+ Section NT Service (NT/2k/XP only) Section3
SectionIn 3
@@ -94,7 +92,7 @@
SectionEnd
- Section JSP Development Shell Extensions
+ Section JSP Development Shell Extensions Section4
SectionIn 1 2 3
; back up old value of .jsp
@@ -113,7 +111,7 @@
SectionEnd
- Section Tomcat Start Menu Group
+ Section Tomcat Start Menu Group Section5
SectionIn 1 2 3
@@ -144,8 +142,8 @@
SectionEnd
SubSectionEnd
-SubSection Documentation and Examples
- Section Tomcat Documentation
+SubSection Documentation and Examples Section6
+ Section Tomcat Documentation Section7
SectionIn 1 3
SetOutPath $INSTDIR\webapps
@@ -162,7 +160,7 @@
SectionEnd
- Section Example Web Applications
+ Section Example Web Applications Section8
SectionIn 1 3
@@ -177,9 +175,9 @@
SectionEnd
SubSEctionEnd
-SubSection Developer Resources
+SubSection Developer Resources Section9
- Section Tomcat Source Code
+ Section Tomcat Source Code Section10
SectionIn 3
SetOutPath $INSTDIR
@@ -190,6 +188,30 @@
SubSectionEnd
+LangString DESC_Section1 ${LANG_ENGLISH} The core Tomcat components.
+LangString DESC_Section2 ${LANG_ENGLISH} The Tomcat servlet container.
+LangString DESC_Section3 ${LANG_ENGLISH} Additional files and configuration
to enable Tomcat to be run as a Windows service.
+LangString DESC_Section4 ${LANG_ENGLISH} Configure NotePad as the default
editor for JSP files.
+LangString DESC_Section5 ${LANG_ENGLISH} Add Tomcat icons to the Start
menu.
+LangString DESC_Section6 ${LANG_ENGLISH} Optional web applications.
+LangString DESC_Section7 ${LANG_ENGLISH} Deploys the documentation web
aplication.
+LangString DESC_Section8 ${LANG_ENGLISH} Deploys the JSP servlets
examples web application and the WebDAV example web application.
+LangString DESC_Section9 ${LANG_ENGLISH} Optional resource for developers.
+LangString DESC_Section10 ${LANG_ENGLISH} Places the Tomcat and Tomcat
Connector source code as
DO NOT REPLY [Bug 23277] - webDAV doesn't install when examples are deselected from installer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=23277. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=23277 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED OS/Version||All Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-02-04 00:39 --- I have updated the installer to use the modern UI and taken the opportunity to add descriptions for each of the components. The description makes it clear that the examples includes both the JSP/servlet examples and the WebDAV example. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Bootstrap.java BootstrapService.java ClassLoaderFactory.java EmbeddedManager.java EmbeddedManagerMBean.java EngineConfig.java EngineRuleSet.java HostRuleSet.java NamingRuleSet.java TldRuleSet.java Tool.java UserConfig.java
markt 2005/02/03 15:53:43 Modified:catalina/src/share/org/apache/catalina/startup Bootstrap.java BootstrapService.java ClassLoaderFactory.java EmbeddedManager.java EmbeddedManagerMBean.java EngineConfig.java EngineRuleSet.java HostRuleSet.java NamingRuleSet.java TldRuleSet.java Tool.java UserConfig.java Log: Remove unused imports in o.a.c.startup package Revision ChangesPath 1.38 +1 -7 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java Index: Bootstrap.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v retrieving revision 1.37 retrieving revision 1.38 diff -u -r1.37 -r1.38 --- Bootstrap.java26 Aug 2004 21:41:12 - 1.37 +++ Bootstrap.java3 Feb 2005 23:53:43 - 1.38 @@ -19,13 +19,7 @@ import java.io.File; -import java.io.IOException; import java.lang.reflect.Method; -import java.net.MalformedURLException; -import java.net.URL; -import java.util.ArrayList; -import org.apache.catalina.loader.Extension; -import org.apache.catalina.loader.StandardClassLoader; /** 1.19 +1 -7 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java Index: BootstrapService.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- BootstrapService.java 26 Aug 2004 21:41:12 - 1.18 +++ BootstrapService.java 3 Feb 2005 23:53:43 - 1.19 @@ -19,15 +19,9 @@ import java.io.File; -import java.io.IOException; import java.lang.reflect.Method; -import java.net.MalformedURLException; -import java.net.URL; -import java.util.ArrayList; import org.apache.commons.daemon.Daemon; import org.apache.commons.daemon.DaemonContext; -import org.apache.catalina.loader.Extension; -import org.apache.catalina.loader.StandardClassLoader; /** 1.10 +1 -4 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java Index: ClassLoaderFactory.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ClassLoaderFactory.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- ClassLoaderFactory.java 26 Aug 2004 21:41:12 - 1.9 +++ ClassLoaderFactory.java 3 Feb 2005 23:53:43 - 1.10 @@ -19,11 +19,8 @@ import java.io.File; -import java.io.IOException; import java.net.URL; import java.util.ArrayList; -import java.util.jar.JarEntry; -import java.util.jar.JarFile; import org.apache.catalina.loader.StandardClassLoader; 1.6 +1 -7 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java Index: EmbeddedManager.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- EmbeddedManager.java 26 Aug 2004 21:41:12 - 1.5 +++ EmbeddedManager.java 3 Feb 2005 23:53:43 - 1.6 @@ -18,17 +18,11 @@ import java.net.InetAddress; import org.apache.catalina.Connector; -import org.apache.catalina.Container; import org.apache.catalina.Context; import org.apache.catalina.Engine; import org.apache.catalina.Host; -import org.apache.catalina.Lifecycle; -import org.apache.catalina.LifecycleEvent; -import org.apache.catalina.LifecycleException; -import org.apache.catalina.LifecycleListener; import org.apache.catalina.Logger; import org.apache.catalina.Realm; -import org.apache.catalina.connector.http.HttpConnector; import javax.management.NotificationBroadcasterSupport; import javax.management.ObjectName; import javax.management.MBeanServer; 1.6 +1 -7 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/EmbeddedManagerMBean.java Index: EmbeddedManagerMBean.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/EmbeddedManagerMBean.java,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- EmbeddedManagerMBean.java 26 Aug 2004 21:41:13 - 1.5 +++ EmbeddedManagerMBean.java 3 Feb
Re: The FIX - Shutdown not working under SLES8 and FC2
Al Sutton wrote: Is there any reason why it doesn't try localhost first? Using localhost before anything else would have the following benefits; a) Would ensure that only really strange network configs would be affected (i.e. those where localhost is not the local host). b) Make use of the speed advantage some OS's have in their implementation of the loopback address. c) Avoid any wacky differences in the implementation of InetAddress.getLocalHost() between JVMs/OSs/etc. Off the top off my head I can't see the advantages of using the result of InetAddress.getLocalHost() first. What do you mean by 'try localhost first' ? The name 'localhost', or '127.0.0.1' or whatever the number is in IPV6 ? I guess the reason for InetAddress.getLocalHost() is the wacky differences between OSes :-), and if it's broken on a platform - it should be fixed ( by Sun or OS vendor ) Costin Al. -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: 03 February 2005 19:11 To: Tomcat Developers List Subject: Re: The FIX - Shutdown not working under SLES8 and FC2 If no address is configured, ChannelSocket attempts the shutdown on InetAddress.getLocalHost(). Personally, I'm not inclined to change this as it points to a network configuration problem if this is unreachable. However, you might try complaining to Sun about how they have implemented getLocalHost on SLES8. - Original Message - From: [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Cc: tomcat-dev@jakarta.apache.org Sent: Thursday, February 03, 2005 2:14 AM Subject: The FIX - Shutdown not working under SLES8 and FC2 After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts you've got a strange config, it's your problem, I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address=127.0.0.1 to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine. I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh).
DO NOT REPLY [Bug 33307] - jspInit() method is throwing an NamingException when extracting a factory object from a JNDI context
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33307. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33307 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-02-04 05:26 --- I feel, we tried many combinations to see if it is a configurations issue, but of now use. It seems to be a bug in Tomcat it is present in all the versions we tried out. We are declaring it as a bug, let us know if any one has any other suggestions/soln to try out. Thanks in advance, Yogi -Original Message- From: Yogi [mailto:[EMAIL PROTECTED] Sent: Thursday, February 03, 2005 7:47 PM To: 'Tomcat Users List' Subject: RE: jspInit() throwing NamingException when extracting a factory object from JNDI context Appreciate if any one has some inputsWe couldn't decide whether it is a bug or usage issue,... Details @ http://issues.apache.org/bugzilla/show_bug.cgi?id=33307 Problem: jspInit() throwing NamingException when extracting a factory object from JNDI context. Description: When the container has been configured to load the JSP page during startup by including the Load-On-Startup tag in web.xml, the NamingException has been reported( can be viewed in the attachment). The Tomcat Version which we are using is Tomcat 4.1.3. How to Reproduce the problem: - Step 1) create a directory under webapps (say test) and unzip the attached jsppax.zip into the test dir under webapps. Step 2) add the following lines to server.xml Context path=/test docBase=d:\jakarta-tomcat-4.1.30\webapps\test debug=0/ !-- DefaultContext -- DefaultContext reloadable=true crossContext=true useNaming=true !-- bean/MyBeanFactory -- Resource name=bean/MyBeanFactory auth=Container type=com.mycompany.MyBean/ ResourceParams name=bean/MyBeanFactory parameter namefactory/name valueorg.apache.naming.factory.BeanFactory/value /parameter parameter namebar/name value23/value /parameter /ResourceParams /DefaultContext !-- /DefaultContext -- Step 3) start the server During startup, the NamingException has been reported. We tried with couple of other Tomcat versions aswell it is poping that NamingException with them also. Please letus know if you had any issues while reproducing the above exception. You can refer to the bugid :33307 if you need more information. Please let us Know if it is a configuration issue or a bug in JSP-TomCat. Awaiting yor response.. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SVN migration?
Just wondering if the Tomcat community have any thoughts on a migration to Subversion? The process seems pretty easy, though Tomcat may be more complicated than the usual CVS module. Infra have the process documented at: http://www.apache.org/dev/cvs2svn.html The Jakarta status is in the wiki at: http://wiki.apache.org/jakarta/Migrating_20to_20Subversion The aim would be for all the tomcat modules to migrate into asf/repos/jakarta/tomcat/ so that we can have a cleaner top-level structure to the system, within that though the Tomcat community are free to choose whatever strategy fits. I've intentionally left Tomcat until last to nudge about this so as to build up some experience within Jakarta of dealing with SVN as users and as a migration. Some of you are probably already getting to grips with svn following the Commons migration. Just to provide the context for this, the Infra group are looking to move from CVS to SVN in the long term and Jakarta were far and away the main laggards in this. In the last month or so, a third of Jakarta has moved over, so that's now improving. Another question is whether the Tomcat community have any svn expertise in terms of planning svn strategies, or whether we should try to find some other committers to offer opinions. Thanks, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN migration?
Just to add, as far as I know the following are the Tomcat modules: jakarta-servletapi/ jakarta-servletapi-4/ jakarta-servletapi-5/ jakarta-tomcat/ jakarta-tomcat-4.0/ jakarta-tomcat-5/ jakarta-tomcat-catalina/ jakarta-tomcat-connectors/ jakarta-tomcat-jasper/ jakarta-tomcat-service/ jakarta-tomcat-site/ jakarta-tools/ I suspect you'll want to have: repos/asf/jakarta/servletapi/ and repos/asf/jakarta/tomcat/ I'm not sure if jakarta-tools is in anyway alive. The times on the files look very old. Hen On Thu, 3 Feb 2005 23:27:43 -0500, Henri Yandell [EMAIL PROTECTED] wrote: Just wondering if the Tomcat community have any thoughts on a migration to Subversion? The process seems pretty easy, though Tomcat may be more complicated than the usual CVS module. Infra have the process documented at: http://www.apache.org/dev/cvs2svn.html The Jakarta status is in the wiki at: http://wiki.apache.org/jakarta/Migrating_20to_20Subversion The aim would be for all the tomcat modules to migrate into asf/repos/jakarta/tomcat/ so that we can have a cleaner top-level structure to the system, within that though the Tomcat community are free to choose whatever strategy fits. I've intentionally left Tomcat until last to nudge about this so as to build up some experience within Jakarta of dealing with SVN as users and as a migration. Some of you are probably already getting to grips with svn following the Commons migration. Just to provide the context for this, the Infra group are looking to move from CVS to SVN in the long term and Jakarta were far and away the main laggards in this. In the last month or so, a third of Jakarta has moved over, so that's now improving. Another question is whether the Tomcat community have any svn expertise in terms of planning svn strategies, or whether we should try to find some other committers to offer opinions. Thanks, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SVN migration?
Is this mandatory ? I suspect there'll be a lot of build script/doc/habits/tool changes involved. CVS is working reasonably well at the moment, and a lot of tools have (finally) very good support for it. Costin Henri Yandell wrote: Just wondering if the Tomcat community have any thoughts on a migration to Subversion? The process seems pretty easy, though Tomcat may be more complicated than the usual CVS module. Infra have the process documented at: http://www.apache.org/dev/cvs2svn.html The Jakarta status is in the wiki at: http://wiki.apache.org/jakarta/Migrating_20to_20Subversion The aim would be for all the tomcat modules to migrate into asf/repos/jakarta/tomcat/ so that we can have a cleaner top-level structure to the system, within that though the Tomcat community are free to choose whatever strategy fits. I've intentionally left Tomcat until last to nudge about this so as to build up some experience within Jakarta of dealing with SVN as users and as a migration. Some of you are probably already getting to grips with svn following the Commons migration. Just to provide the context for this, the Infra group are looking to move from CVS to SVN in the long term and Jakarta were far and away the main laggards in this. In the last month or so, a third of Jakarta has moved over, so that's now improving. Another question is whether the Tomcat community have any svn expertise in terms of planning svn strategies, or whether we should try to find some other committers to offer opinions. Thanks, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: The FIX - Shutdown not working under SLES8 and FC2
Costin, The answer to your question is all of the above (i.e. start with localhost, then 127.0.0.1, then try the IPv6 localhost). I'm not saying it's the only behaviour, just that trying it first may make more stable than trying a hostname first. It's als less work by fewer people to change Tomcat than to check, test, and modify (if neccessary) all the JVMs in existance. Al. -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache Sent: 04 February 2005 02:28 To: tomcat-dev@jakarta.apache.org Subject: Re: The FIX - Shutdown not working under SLES8 and FC2 Al Sutton wrote: Is there any reason why it doesn't try localhost first? Using localhost before anything else would have the following benefits; a) Would ensure that only really strange network configs would be affected (i.e. those where localhost is not the local host). b) Make use of the speed advantage some OS's have in their implementation of the loopback address. c) Avoid any wacky differences in the implementation of InetAddress.getLocalHost() between JVMs/OSs/etc. Off the top off my head I can't see the advantages of using the result of InetAddress.getLocalHost() first. What do you mean by 'try localhost first' ? The name 'localhost', or '127.0.0.1' or whatever the number is in IPV6 ? I guess the reason for InetAddress.getLocalHost() is the wacky differences between OSes :-), and if it's broken on a platform - it should be fixed ( by Sun or OS vendor ) Costin Al. -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: 03 February 2005 19:11 To: Tomcat Developers List Subject: Re: The FIX - Shutdown not working under SLES8 and FC2 If no address is configured, ChannelSocket attempts the shutdown on InetAddress.getLocalHost(). Personally, I'm not inclined to change this as it points to a network configuration problem if this is unreachable. However, you might try complaining to Sun about how they have implemented getLocalHost on SLES8. - Original Message - From: [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Cc: tomcat-dev@jakarta.apache.org Sent: Thursday, February 03, 2005 2:14 AM Subject: The FIX - Shutdown not working under SLES8 and FC2 After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts you've got a strange config, it's your problem, I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address=127.0.0.1 to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4
Re: SVN migration?
I've not heard anything about it being mandatory yet, but the numbers speak for themselves. The www.apache.org site has 24 coding projects. There are 22 projects listed on the svn.apache.org/viewcvs.cgi page. 2 of those are dead, so 20 out of 24 ASF projects have an svn presence of some kind. The people still left with readable CVS modules are: mod_perl ant 2/3rds of jakarta possibly gump (though they have an svn module too) apache conference most of xml logging half of web services So I assume at some point there'll be pressure to turn off the CVS server. On the command line, svn is pretty much the same as cvs. Some bits are faster, some slower. There are various improved features (http://subversion.tigris.org/ lists them) that people have been asking for for ages with CVS. Habit-wise, the only differences I've hit are: 1) you checkout from a url, not from a cvs-root and a path. 2) tagging/branching is done by copying a directory revision (really creating a symlink-style thing in the database) and isn't applied to every file individually. Tool-wise, Subclipse is an Eclipse plugin that seems to work fine for standard development (checkout, update, diff, commit). I'm unsure whether you can create tags/branches using it as I always do that on the command line, be it cvs or svn. IntelliJ has a plugin and the next version will have it built in. TortoiseSvn is spoken well of, and I can vouch for svn on linux/OS X, I've had no problems in the last year of use. Docs are docs :) Yep, they'll need updating. Build scripts. Do you have scripts that check modules out of cvs? If so I imagine the ant support for svn might be a big deal. Unsure what it's like. Hen On Thu, 03 Feb 2005 21:32:41 -0800, Costin Manolache [EMAIL PROTECTED] wrote: Is this mandatory ? I suspect there'll be a lot of build script/doc/habits/tool changes involved. CVS is working reasonably well at the moment, and a lot of tools have (finally) very good support for it. Costin Henri Yandell wrote: Just wondering if the Tomcat community have any thoughts on a migration to Subversion? The process seems pretty easy, though Tomcat may be more complicated than the usual CVS module. Infra have the process documented at: http://www.apache.org/dev/cvs2svn.html The Jakarta status is in the wiki at: http://wiki.apache.org/jakarta/Migrating_20to_20Subversion The aim would be for all the tomcat modules to migrate into asf/repos/jakarta/tomcat/ so that we can have a cleaner top-level structure to the system, within that though the Tomcat community are free to choose whatever strategy fits. I've intentionally left Tomcat until last to nudge about this so as to build up some experience within Jakarta of dealing with SVN as users and as a migration. Some of you are probably already getting to grips with svn following the Commons migration. Just to provide the context for this, the Infra group are looking to move from CVS to SVN in the long term and Jakarta were far and away the main laggards in this. In the last month or so, a third of Jakarta has moved over, so that's now improving. Another question is whether the Tomcat community have any svn expertise in terms of planning svn strategies, or whether we should try to find some other committers to offer opinions. Thanks, Hen - 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]
The FIX - Shutdown not working under SLES8 and FC2
After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts you've got a strange config, it's your problem, I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address=127.0.0.1 to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine. I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh). Thanks again, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 23:32 To: Tomcat Users List Subject: RE: Shutdown not working under SLES8 and FC2 On Wed, 2005-02-02 at 17:11, Ben Souther wrote: On Wed, 2005-02-02 at 16:43, Al Sutton wrote: Hmmm The latest updates gives me; Linux host 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686 athlon i386 GNU/Linux and I'm on JDK 1.4.2_06 as opposed to _05. Would it be possible for you to upgrade?, I'd like to have the exact same environment, but please don't put yourself out or risk a critical environment. OK, here you go. It turns out that I did have _06 on this machine. I also have 2.6.10-1.9_FC2 (which is no longer the latest BTW ;)). Once again, I started and stopped without a problem. Here is the screen dump: [EMAIL PROTECTED] bin]$ uname -a Linux bsouther 2.6.10-1.9_FC2 #1 Thu Jan 13 17:54:57 EST 2005 i686 athlon i386 GNU/Linux [EMAIL PROTECTED] bin]$ export JAVA_HOME=/usr/local/j2sdk1.4.2_06 [EMAIL PROTECTED] bin]$ ./startup.sh Using CATALINA_BASE: /home/bsouther/tc_test/jakarta-tomcat-5.5.7 Using CATALINA_HOME: /home/bsouther/tc_test/jakarta-tomcat-5.5.7 Using CATALINA_TMPDIR: /home/bsouther/tc_test/jakarta-tomcat-5.5.7/temp Using JRE_HOME: /usr/local/j2sdk1.4.2_06 [EMAIL PROTECTED] bin]$ ./shutdown.sh Using CATALINA_BASE: /home/bsouther/tc_test/jakarta-tomcat-5.5.7 Using CATALINA_HOME:
Re: The FIX - Shutdown not working under SLES8 and FC2
Costin Wrote: ( BTW - if you plan to participate in any open source project - be prepared for a lot of hurt feelings and negative comments, if you can't handle it, stay out. It happens to all of us. Track the problem, send a patch and friendly reminders if it gets ignored - and be prepared to accept a 'no' ) This by all means doesn't mean that all open source developers are not equipped with social skills, its just more common in the Java world :) Filip - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: tomcat-dev@jakarta.apache.org Cc: tomcat-user@jakarta.apache.org Sent: Thursday, February 03, 2005 11:16 AM Subject: Re: The FIX - Shutdown not working under SLES8 and FC2 What about: - add this information to the bug report - send a patch to the FAQ or edit a wiki page ( well, the tc wiki is not very used, but probably google will find this if anyone has a similar problem ). Or post it in your weblog/site/etc for google to find. It should be obvious changing the default configuration only to deal with this case won't happen. If a computer can't locate itself by name - you'll have a lot of other problems. Costin ( BTW - if you plan to participate in any open source project - be prepared for a lot of hurt feelings and negative comments, if you can't handle it, stay out. It happens to all of us. Track the problem, send a patch and friendly reminders if it gets ignored - and be prepared to accept a 'no' ) [EMAIL PROTECTED] wrote: After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts you've got a strange config, it's your problem, I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address=127.0.0.1 to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine. I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh). Thanks again, Al. -Original Message- From:
