Re: Cluster startContext() SimpleTcpCluster

[Peter Rossbach]

Hey,

a)   current tomcat 5.5.12 cluster implementation is a message 
infrastructure.
b)   The Context can used this message infrastructure to implement 
remote session replication
c)   When a Context start the DeltaManager sync with other nodes. That 
means that all
  sessions are transfered form an other node. All lost messages 
before are dropped and

  not really important.
d)   With tomcat 5.5.12 I implemented a message buffering for all 
messages that received, when ALL_SESSION are transfered

  This message are replayed after nodes is in sync.

Why you implemented your own session replication?  It's very hard way :-)

Regards
Peter

local-underground schrieb:


Hello,

I am very curious why a Cluster does not make sure the context it is defined in 
is
actually started before listening?  This is proving to be a serious bug for me. 
 I am
implementing session replication where nested objects are defined via JNDI in 
my context.
But when a new cluster member is added, it immediately receives a session and 
attempts
to deserialize the sessions before loading my context.. which is causing errors 
due to
classes not being found.

I see a startContext() defined in SimpleTcpCluser but it appears to be 
depracted and is
blank.  


I do realize I can make a global Resource and reference this JNDI within my 
context, but
I dont wanna move a huge chunk of my web application in global scope just to 
have these
references visible when the cluster starts.

Can some one explain the logic of why the Context is not loaded before the 
cluster
starts?  Can some one advise me on a quick fix to achieve this?


thanks in advance


chris
  






__ 
Yahoo! FareChase: Search multiple travel sites in one click.

http://farechase.yahoo.com

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




 




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

svn commit: r329055 - /tomcat/sandbox/README.txt

[costin]

Author: costin
Date: Thu Oct 27 20:01:20 2005
New Revision: 329055

URL: http://svn.apache.org/viewcvs?rev=329055&view=rev
Log:
A small comment on source organization. 

Modified:
tomcat/sandbox/README.txt

Modified: tomcat/sandbox/README.txt
URL: 
http://svn.apache.org/viewcvs/tomcat/sandbox/README.txt?rev=329055&r1=329054&r2=329055&view=diff
==
--- tomcat/sandbox/README.txt (original)
+++ tomcat/sandbox/README.txt Thu Oct 27 20:01:20 2005
@@ -33,6 +33,16 @@
 svn mkdir https://svn.apache.org/repos/asf/tomcat/sandbox/component/branches

 svn mkdir https://svn.apache.org/repos/asf/tomcat/sandbox/component/tags

 

+Alternatively, you can use the java/ directory. If possible:

+1. create a new package ( or few ) for each module

+2. if you have an external dependency for an optional component - create a new 
package.

+3. Update the top level build.xml file with targets for your module - use 
 patterns instead

+of exclude. 

+

+The single tree may help increase visibility of the source code. We are in 
2005 ( or more ), build tools

+and IDEs have very good support for include/exclude patterns, we have tools to 
find dependencies between

+packages, and we have a single community, so we don't need fragmented source 
trees and more, at least in 

+sandbox.

 

 Releases

 




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

svn commit: r329054 - in /tomcat/sandbox/java/org/apache/tomcat: ./ util/ util/log/ util/log/JdkLoggerConfig.java util/log/JdkLoggerFormatter.java

[costin]

Author: costin
Date: Thu Oct 27 19:56:34 2005
New Revision: 329054

URL: http://svn.apache.org/viewcvs?rev=329054&view=rev
Log:
Handler and config for java.util.logging. 



Added:
tomcat/sandbox/java/org/apache/tomcat/
tomcat/sandbox/java/org/apache/tomcat/util/
tomcat/sandbox/java/org/apache/tomcat/util/log/
tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerConfig.java
tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerFormatter.java

Added: tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerConfig.java
URL: 
http://svn.apache.org/viewcvs/tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerConfig.java?rev=329054&view=auto
==
--- tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerConfig.java (added)
+++ tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerConfig.java Thu Oct 
27 19:56:34 2005
@@ -0,0 +1,108 @@
+/*
+ * Copyright 2001-2004 The Apache Software Foundation.
+ * Copyright 2004 Costin Manolache
+ * 
+ * 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.
+ */ 
+
+package org.apache.tomcat.util.log;
+
+import java.io.File;
+import java.io.FileInputStream;
+import java.io.FileNotFoundException;
+import java.io.IOException;
+import java.io.InputStream;
+import java.net.URL;
+import java.util.logging.LogManager;
+
+/**
+ */
+public class JdkLoggerConfig {
+
+public JdkLoggerConfig() {
+InputStream is=getConfig( "logging" );
+if( is!=null ) {
+try {
+LogManager.getLogManager().readConfiguration(is);
+} catch (SecurityException e) {
+e.printStackTrace();
+} catch (IOException e) {
+e.printStackTrace();
+}
+}
+}
+
+/** Locate a config stream:
+ * 
+ *  Uses:
+ *   - logging.configuration system property
+ *   - ./logging.properties file
+ *   - conf/logging.properties
+ *   - logging.properties in classpath
+ * 
+ * @return
+ */
+public static InputStream getConfig(String base) {
+//String base="logging"; // "log4j"
+// Initialize:
+// 1. Find config file name 
+String confF=System.getProperty(base + ".configuration");
+if( confF!=null ) {
+// Check if it is a path
+} else {
+confF=base + ".properties";
+}
+
+// URL
+try {
+URL url=new URL( confF );
+InputStream is=url.openStream();
+if( is!=null ) return is;
+} catch( Throwable t ) {
+
+}
+
+// 2. Try to get the config from a file ( or conf/ )
+File f=new File( confF );
+if( ! f.exists() ) {
+f=new File( "conf/" + confF );
+}
+
+if( f.exists() ) {
+try {
+return new FileInputStream( f );
+} catch (FileNotFoundException e) {
+// ignore
+}
+}
+
+// 3. Load it from CLASSPATH
+InputStream is=JdkLoggerConfig.class.getResourceAsStream( confF );
+
+//No thread class loader 
+if( is!= null ) return is;
+
+f=new File( System.getProperty("java.home"));
+f=new File( f, "lib/logging.properties");
+if( f.exists() ) {
+try {
+return new FileInputStream(f);
+} catch (FileNotFoundException e) {
+//e.printStackTrace();
+}
+} 
+System.err.println("default logging doesn't exists" + f);
+
+return null;
+}
+}

Added: tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerFormatter.java
URL: 
http://svn.apache.org/viewcvs/tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerFormatter.java?rev=329054&view=auto
==
--- tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerFormatter.java 
(added)
+++ tomcat/sandbox/java/org/apache/tomcat/util/log/JdkLoggerFormatter.java Thu 
Oct 27 19:56:34 2005
@@ -0,0 +1,109 @@
+/*
+ * Copyright 2001-2004 The Apache Software Foundation.
+ * Copyright 2004 Costin Manolache
+ * 
+ * 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

svn commit: r329053 - in /tomcat/sandbox/java: ./ org/ org/apache/ org/apache/commons/ org/apache/commons/logging/

[costin]

Author: costin
Date: Thu Oct 27 19:55:08 2005
New Revision: 329053

URL: http://svn.apache.org/viewcvs?rev=329053&view=rev
Log:
Implementation of commons-logging that doesn't use any discovery or
tricks, just plain java.util.logging.

There is a trick actually - at startup it'll try to load a different
handler ( without 2-lines logs ) and a different config ( from classpath
like log4j ). I'll probably remove this later, but I can't stand the
default handler and behavior

Added:
tomcat/sandbox/java/
tomcat/sandbox/java/org/
tomcat/sandbox/java/org/apache/
tomcat/sandbox/java/org/apache/commons/
tomcat/sandbox/java/org/apache/commons/logging/
tomcat/sandbox/java/org/apache/commons/logging/DirectJDKLog.java
tomcat/sandbox/java/org/apache/commons/logging/Log.java

tomcat/sandbox/java/org/apache/commons/logging/LogConfigurationException.java
tomcat/sandbox/java/org/apache/commons/logging/LogFactory.java

Added: tomcat/sandbox/java/org/apache/commons/logging/DirectJDKLog.java
URL: 
http://svn.apache.org/viewcvs/tomcat/sandbox/java/org/apache/commons/logging/DirectJDKLog.java?rev=329053&view=auto
==
--- tomcat/sandbox/java/org/apache/commons/logging/DirectJDKLog.java (added)
+++ tomcat/sandbox/java/org/apache/commons/logging/DirectJDKLog.java Thu Oct 27 
19:55:08 2005
@@ -0,0 +1,185 @@
+/*
+ * Copyright 2001-2004 The Apache Software Foundation.
+ * Copyright 2004 Costin Manolache
+ * 
+ * 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.
+ */ 
+
+package org.apache.commons.logging;
+
+import java.util.logging.ConsoleHandler;
+import java.util.logging.Formatter;
+import java.util.logging.Handler;
+import java.util.logging.Level;
+import java.util.logging.Logger;
+
+
+/** 
+ * Hardcoded java.util.logging commons-logging implementation.
+ * 
+ * In addition, it curr 
+ * 
+ */
+class DirectJDKLog implements Log {
+// no reason to hide this - but good reasons to not hide
+public Logger logger;
+
+/** Alternate config reader and console format 
+ */
+private static final String 
SIMPLE_FMT="org.apache.tomcat.util.log.JdkLoggerFormatter";
+private static final String 
SIMPLE_CFG="org.apache.tomcat.util.log.JdkLoggerConfig";
+
+static {
+if( System.getProperty("java.util.logging.config.class") ==null  &&
+System.getProperty("java.util.logging.config.file") ==null ) {
+// default configuration - it sucks. Let's override at least the 
+// formatter for the console
+try {
+Class.forName(SIMPLE_CFG).newInstance();
+} catch( Throwable t ) {
+}
+try {
+Formatter 
fmt=(Formatter)Class.forName(SIMPLE_FMT).newInstance();
+// it is also possible that the user modifed 
jre/lib/logging.properties - 
+// but that's really stupid in most cases
+Logger root=Logger.getLogger("");
+Handler handlers[]=root.getHandlers();
+for( int i=0; i< handlers.length; i++ ) {
+// I only care about console - that's what's used in 
default config anyway
+if( handlers[i] instanceof  ConsoleHandler ) {
+handlers[i].setFormatter(fmt);
+}
+}
+} catch( Throwable t ) {
+// maybe it wasn't included - the ugly default will be used.
+t.printStackTrace();
+}
+
+} else {
+System.out.println(System.getProperties());
+}
+}
+
+public DirectJDKLog(String name ) {
+logger=Logger.getLogger(name);
+}
+
+public final boolean isErrorEnabled() {
+return logger.isLoggable(Level.SEVERE);
+}
+
+public final boolean isWarnEnabled() {
+return logger.isLoggable(Level.WARNING); 
+}
+
+public final boolean isInfoEnabled() {
+return logger.isLoggable(Level.INFO);
+}
+
+public final boolean isDebugEnabled() {
+return logger.isLoggable(Level.FINE);
+}
+
+public final boolean isFatalEnabled() {
+return logger.isLoggable(Level.SEVERE);
+}
+
+public final boolean isTraceEnabled() {
+return logger.isLoggable(Level.FINER);
+}
+
+public final void debug(Objec

svn commit: r329043 - /tomcat/connectors/trunk/jni/native/os/unix/system.c

[costin]

Author: costin
Date: Thu Oct 27 19:32:35 2005
New Revision: 329043

URL: http://svn.apache.org/viewcvs?rev=329043&view=rev
Log:
On some systems, LOG_WARN doesn't exist - it is called LOG_WARNING. (
for example - current versions of Suse, Redhat )

Modified:
tomcat/connectors/trunk/jni/native/os/unix/system.c

Modified: tomcat/connectors/trunk/jni/native/os/unix/system.c
URL: 
http://svn.apache.org/viewcvs/tomcat/connectors/trunk/jni/native/os/unix/system.c?rev=329043&r1=329042&r2=329043&view=diff
==
--- tomcat/connectors/trunk/jni/native/os/unix/system.c (original)
+++ tomcat/connectors/trunk/jni/native/os/unix/system.c Thu Oct 27 19:32:35 2005
@@ -38,6 +38,10 @@
 #include 
 #include 
 
+#ifndef LOG_WARN
+#define LOG_WARN LOG_WARNING
+#endif
+
 #if defined(sun)
 #define MAX_PROC_PATH_LEN 64
 #define MAX_CPUS 512



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

Re: tomcat source / eclipse project

[Jean-frederic Clere]

hasssip satang wrote:

Hi, 




I'm trying to setup a tomcat eclipse project. Looking through the list
archive I've seen that some of you have been sharing their .project and
.classpath files. 




If you could send me these files as well (or point me to a resource where I
can download them) that would be really helpful. Setting it up from scratch
seems like a really time consuming task.

Eclipse obviously does not find all source trees and jars correctly after
setting up new projects as stated in
http://tomcat.apache.org/tomcat-5.5-doc/building.html . I get tons of error
messages. 
 

Try to use 
http://svn.apache.org/repos/asf/tomcat/build/tc5.5.x/resources/build.xml 
(it worked for me with ant but I have not yet tried it with eclipse).

If that helps, I will the build.xml in web site.




Also is there a build.xml which is working on the subversion repository
already? For my first tests I used the one mentioned in the article found
under the link above. This, however, is working on the 'old' CVS repository.




Thanks,

Thomas




 




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

DO NOT REPLY [Bug 37262] - JDBC datasources are never released

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37262





--- Additional Comments From [EMAIL PROTECTED]  2005-10-28 00:16 ---
I'm not talking about resources from server.xml but rather context.xml which are
not shared with other webapps.

-- 
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 37262] - JDBC datasources are never released

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37262





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 23:51 ---
(In reply to comment #9)
> Glen, of course I close my connections. But the datasource uses a connection
> pool and the underlying JDBC connection in not really closed but just returned
> to the pool. 

I know -- SRV10.2.2 was just a "for example" -- it implies the types of things
the Developer can/should do, such as create a listener to close the DBCP when
the webapp is shut down.

However, I can't see how this would be doable within Tomcat, given that the
object is created within server.xml.  The Developer does not have access to the
Java object external to the Tomcat source code; they have to recode Tomcat as
you've done here.

> It is the responsibility of the container who manages the
> datasource to call close() (on the datasource, not the connection) when the
> context is stopped.

Well, this seems to be too specific--the Servlet 2.4 spec doesn't mention data
sources and close() methods specifically.  So I'm not so certain how much of a
container requirement this is.


> 
> Part of the problem is that javax.sql.DataSource does not provide a close()
> method, only the DBCP DataSource does. But this makes sense to me, because
> javax.sql.DataSource is an interface for the users, and the appserver should 
> use
> its own means to cleanup the datasource. 

If that were the case, I think there would have to be a standard definition for
a data source, as well as a "close()" method that it must implement within the
Servlet spec.

> The users should not be able to close a
> datasource, because it is meant to be managed by the appserver.

OK--but what if a datasource is shared by multiple applications/instances of
Tomcat, etc.?  (possible?) Then we wouldn't want it to be closed automatically
whenever a webapp is shut down.


> 
> Here is a quote from the JDBC 3.0 spec the mentions that an appserver
> implementation closes a datasource.
> 
> "A connection pool manager shuts down a physical connection by calling the
> method PooledConnection.close. This method is typically called only in
> certain circumstances: when the application server is undergoing an orderly
> shutdown, when the connection cache is being reinitialized, or when the
> application server receives an event indicating that an unrecoverable error 
> has
> occurred on the connection." 
> 

But this doesn't seem to rule out that the developer won't be creating an
application event listener that is activated to specifically shut down the data
source (data source API's vary, so I don't see how the app server can do this in
a common manner for all data sources.)  But again, I don't see how this is
doable within Tomcat in an server.xml-created connection pool.

> The connection manager is DBCP but it has no way of knowing that the tomcat
> context is stopped. That's why, for a proper integration there needs to be 
> some
> glueing code that listens to tomcat lifecycle events and notifies DBCP. It
> doesn't strictly belong to Tomcat, it doesn't strictly belong to DBCP, so 
> that's
> why it does not exist.

I think there are two problems here (again, newbie speaking here):
1.)  The application developer does not have programmatic access to the
connection pool created in server.xml, so he/she cannot call close() on it from
a developer-created application event listener even if he/she wanted to.  (Your
opinion is that this should not need to be done anyway, it should be automatic.)

2.)  Tomcat integrates DBCP enough to allow for creation of a connection pool
from server.xml, but is not calling close() on those connection pools after the
webapp is shut down.  

I don't have an opinion either way on this; I'm just trying to understand the
issue, although I wonder if other users have complained about this as well, and
if not, why not.

Glen


-- 
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 37284] - guess JDK location on Mac OS X

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37284





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 23:33 ---
Created an attachment (id=16824)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16824&action=view)
The patch (same as in report text)


-- 
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 37285] New: - POST of document through CGI

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37285

   Summary: POST of document through CGI
   Product: Tomcat 5
   Version: 5.5.12
  Platform: All
OS/Version: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: Servlets:CGI
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


If an XML document is posted through CGI the CGIServlet is prepending the 
content with the query parameters from the URL.  Since the content is expected 
to be well formed XML (as specified by specifying "Content-Type: text/xml") the 
prepended query parameters cause the XML parsing to fail.  Assuming a test.sh 
script has been configured for Tomcat which contains:

  java test <&0 >test.out

where test.java simply echoes the input (there is probably an easier way to do 
this) as follows:

  public class test {
public static void main(String[] args) {
  try {
int c = System.in.read();
while(c > 0) {
  System.out.print((char)c);
  c = System.in.read();
}
  } catch(Exception e) {e.printStackTrace();}
}
  }

Then exercise the Tomcat server by launching a telnet session for the Tomcat 
host and port, such as "telnet localhost 8080", and enter the following:

  POST /test/cgi-bin/test.sh?a=123&b=xyz HTTP/1.1
  Host: localhost:8080
  Content-type: text/xml; charset=UTF-8
  Content-length: 250
  Connection: close

  
  
  2005-10-27 00:00:00
  

The resulting test.out file will contain the submitted XML document prepended 
with a line containing the query parameters (a=123&b=xyz).  Unfortunately the 
XML parser that is recieving this data is expecting XML data and the query 
parameters cause an exception (since they are invalid XML).  Note also that 
since the query parameters are included their size is also counted against the 
provided Content-length value which results in truncating the document when the 
Content-length is specified as the size of the XML document.

-- 
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 37284] New: - guess JDK location on Mac OS X

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37284

   Summary: guess JDK location on Mac OS X
   Product: Tomcat 5
   Version: Unknown
  Platform: Macintosh
OS/Version: Mac OS X 10.4
Status: NEW
  Severity: trivial
  Priority: P2
 Component: Native:Packaging
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Under Mac OS X there is defined standard JDK location. JDK 1.5 shipped by Apple 
is always installed to 
/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home.

Simple patch checks whether this JDK exists if JAVA_HOME and JRE_HOME are unset.

===
--- ./catalina.sh.orig  2005-10-28 01:12:12.0 +0400
+++ ./catalina.sh   2005-10-28 01:11:38.0 +0400
@@ -45,9 +45,11 @@
 # OS specific support.  $var _must_ be set to either true or false.
 cygwin=false
 os400=false
+darwin=false
 case "`uname`" in
 CYGWIN*) cygwin=true;;
 OS400*) os400=true;;
+Darwin*) darwin=true;;
 esac
 
 # resolve links - $0 may be a softlink
--- ./setclasspath.sh.orig  2005-10-28 01:10:05.0 +0400
+++ ./setclasspath.sh   2005-10-28 01:19:52.0 +0400
@@ -10,9 +10,13 @@
 
 # Make sure prerequisite environment variables are set
 if [ -z "$JAVA_HOME" -a -z "$JRE_HOME" ]; then
-  echo "Neither the JAVA_HOME nor the JRE_HOME environment variable is defined"
-  echo "At least one of these environment variable is needed to run this 
program"
-  exit 1
+  if $darwin && [ -d 
"/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home" ]; then
+export 
JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home"
+  else
+echo "Neither the JAVA_HOME nor the JRE_HOME environment variable is 
defined"
+echo "At least one of these environment variable is needed to run this 
program"
+exit 1
+  fi
 fi
 if [ -z "$JAVA_HOME" -a "$1" = "debug" ]; then
   echo "JAVA_HOME should point to a JDK in order to run in debug mode."
--- ./startup.sh.orig   2005-10-28 01:10:30.0 +0400
+++ ./startup.sh2005-10-28 01:11:01.0 +0400
@@ -7,9 +7,11 @@
 
 # Better OS/400 detection: see Bugzilla 31132
 os400=false
+darwin=false
 case "`uname`" in
 CYGWIN*) cygwin=true;;
 OS400*) os400=true;;
+Darwin*) darwin=true;;
 esac
 
 # resolve links - $0 may be a softlink
===

-- 
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 36976] - Tomcat VM does not shutdown with remote jmx enabled

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=36976


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Windows XP  |All




--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 23:23 ---
This affects all operating systems. Here's the simple catalina.sh equivalent of
Comment #5

--- apache-tomcat-5.5.12/bin/catalina.sh2005-09-23 08:42:02.0 
-0500
+++ catalina.sh 2005-10-27 16:12:58.0 -0500
@@ -266,7 +266,7 @@
 FORCE=1
   fi

-  "$_RUNJAVA" $JAVA_OPTS $CATALINA_OPTS \
+  "$_RUNJAVA" $CATALINA_OPTS \
 -Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" -classpath "$CLASSPATH" \
 -Dcatalina.base="$CATALINA_BASE" \
 -Dcatalina.home="$CATALINA_HOME" \


-- 
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 37277] - long delay in Tomcat startup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37277





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 22:34 ---
Created an attachment (id=16823)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16823&action=view)
Patch for tc5.5.x/container/webapps/docs/config/context.xml

Minor addition to the docs for processTlds based on Tim's comment #3.

-- 
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: [Fwd: JSP Precompilation vs. JSR-45 Debugging]

[Jess Holle]

The issue is that at least in 5.5.9 this attribute appears to be 
*hard-wired* in JspC so that you can't override the default via a simple 
Ant task attribute or command line argument.


I guess I should double check the latest sources.  Otherwise I'm 
inclined to change this in our own Tomcat distro.


--
Jess Holle

Kin-man Chung wrote:


I believe Smap is suppressed by default in JSPC.  There is
a switch to term it on (-smap ?).  Don't remember what the
ant task attribute name is (smapSuppressed="false" ??).

-Kin-man

On Thu, 2005-10-27 at 09:14, Jess Holle wrote:
 


Is this a more appropriate question for the dev list?

--
Jess Holle


__

From: Jess Holle <[EMAIL PROTECTED]>
To: Tomcat Users List 
Subject: JSP Precompilation vs. JSR-45 Debugging
Date: 27 Oct 2005 08:45:47 -0500

Return-path: [EMAIL PROTECTED]
Received: from hq-ex3fe1.ptcnet.ptc.com ([132.253.201.60])
by HQ-MAIL3.ptcnet.ptc.com with Microsoft SMTPSVC(6.0.3790.1830);   Thu,
27 Oct 2005 09:46:17 -0400
Received: from relay1.ptc.com ([12.11.148.121]) by hq-ex3fe1.ptcnet.ptc.com
with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 27 Oct 2005 09:46:17 -0400
Received: from hermes.apache.org (HELO mail.apache.org) ([209.237.227.199])
by relay1.ptc.com with SMTP; 27 Oct 2005 09:43:38 -0400
Received: (qmail 4564 invoked by uid 500); 27 Oct 2005 13:43:36 -
Received: (qmail 4547 invoked by uid 500); 27 Oct 2005 13:43:35 -
Received: (qmail 4543 invoked by uid 99); 27 Oct 2005 13:43:35 -
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Oct 2005 06:43:35 -0700
Received: from [12.11.148.122] (HELO relay2.ptc.com) (12.11.148.122)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Oct 2005 06:43:29 -0700
Received: from hq-ex3fe2.ptcnet.ptc.com ([132.253.201.63])
by relay2.ptc.com with ESMTP; 27 Oct 2005 09:43:11 -0400
Received: from hq-ex3fe1.ptcnet.ptc.com ([132.253.201.60])
by HQ-EX3FE2.ptcnet.ptc.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu,
27 Oct 2005 09:45:49 -0400
Received: from [132.253.11.50] ([132.253.11.50]) by hq-ex3fe1.ptcnet.ptc.com
with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 27 Oct 2005 09:45:48 -0400
Date: Thu, 27 Oct 2005 08:45:47 -0500
From: Jess Holle <[EMAIL PROTECTED]>
Subject: JSP Precompilation vs. JSR-45 Debugging
In-reply-to: <[EMAIL PROTECTED]>
To: Tomcat Users List 
Reply-to: "Tomcat Users List" 
Message-id: <[EMAIL PROTECTED]>
X-Envelope-from: [EMAIL PROTECTED]
X-Envelope-to: @bedge2-mail1.central.sun.com:[EMAIL PROTECTED]
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
Precedence: bulk
Delivered-to: mailing list users@tomcat.apache.org
Delivered-to: [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Received-SPF: pass (asf.osuosl.org: local policy)
X-Account-Key: account1
X-BrightmailFiltered: true
X-Brightmail-Tracker: AQAAA+k=
X-IronPort-AV: i="3.97,258,1125892800";   d="scan'208";
a="86074334:sNHT20043712"
X-ASF-Spam-Status: No, hits=0.5 required=10.0   tests=DNS_FROM_RFC_ABUSE
X-Spam-Check-By: apache.org
X-IronPort-AV: i="3.97,258,1125892800";   d="scan'208";
a="105871541:sNHT15778616"
X-Virus-Checked: Checked by ClamAV on apache.org
References: <[EMAIL PROTECTED]>
List-Post: 
List-Unsubscribe: 
List-Help: 
List-Id: 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-OriginalArrivalTime: 27 Oct 2005 13:45:48.0759 (UTC)
FILETIME=[BD025E70:01C5DAFC]

I have noticed that when I use an Ant script based on that documented in 
the Tomcat docs to precompile all my JSPs the resulting JSPs do not 
support source-level (JSR-45) debugging.


I thought I was doing something wrong so I looked through the JspC 
source code and I can't see how I could feed it anything more information.


As an added complication I have an extra directory that I need in the 
compilation classpath.  I have extended the web app classloader to 
handle this and added a line to the javac classpath in the Ant script.  
Thus things work fine in that respect but I need that to keep working -- 
I just want to have an option to do source-level JSP debugging as well.


What am I missing?

--
Jess Holle

-
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: [Fwd: JSP Precompilation vs. JSR-45 Debugging]

[Jess Holle]

Okay, I belatedly checked 5.5.x head.

All the changes I'm looking for are there.  They're recent as they're 
not in either 5.0.30 or 5.5.9.


--
Jess Holle

Jess Holle wrote:

The issue is that at least in 5.5.9 this attribute appears to be 
*hard-wired* in JspC so that you can't override the default via a 
simple Ant task attribute or command line argument.


I guess I should double check the latest sources.  Otherwise I'm 
inclined to change this in our own Tomcat distro.


--
Jess Holle

Kin-man Chung wrote:


I believe Smap is suppressed by default in JSPC.  There is
a switch to term it on (-smap ?).  Don't remember what the
ant task attribute name is (smapSuppressed="false" ??).

-Kin-man

On Thu, 2005-10-27 at 09:14, Jess Holle wrote:
 


Is this a more appropriate question for the dev list?

--
Jess Holle


__

From: Jess Holle <[EMAIL PROTECTED]>
To: Tomcat Users List 
Subject: JSP Precompilation vs. JSR-45 Debugging
Date: 27 Oct 2005 08:45:47 -0500

Return-path: [EMAIL PROTECTED]
Received: from hq-ex3fe1.ptcnet.ptc.com ([132.253.201.60])
by HQ-MAIL3.ptcnet.ptc.com with Microsoft SMTPSVC(6.0.3790.1830);   Thu,
27 Oct 2005 09:46:17 -0400
Received: from relay1.ptc.com ([12.11.148.121]) by hq-ex3fe1.ptcnet.ptc.com
with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 27 Oct 2005 09:46:17 -0400
Received: from hermes.apache.org (HELO mail.apache.org) ([209.237.227.199])
by relay1.ptc.com with SMTP; 27 Oct 2005 09:43:38 -0400
Received: (qmail 4564 invoked by uid 500); 27 Oct 2005 13:43:36 -
Received: (qmail 4547 invoked by uid 500); 27 Oct 2005 13:43:35 -
Received: (qmail 4543 invoked by uid 99); 27 Oct 2005 13:43:35 -
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Oct 2005 06:43:35 -0700
Received: from [12.11.148.122] (HELO relay2.ptc.com) (12.11.148.122)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Oct 2005 06:43:29 -0700
Received: from hq-ex3fe2.ptcnet.ptc.com ([132.253.201.63])
by relay2.ptc.com with ESMTP; 27 Oct 2005 09:43:11 -0400
Received: from hq-ex3fe1.ptcnet.ptc.com ([132.253.201.60])
by HQ-EX3FE2.ptcnet.ptc.com with Microsoft SMTPSVC(6.0.3790.1830);  Thu,
27 Oct 2005 09:45:49 -0400
Received: from [132.253.11.50] ([132.253.11.50]) by hq-ex3fe1.ptcnet.ptc.com
with Microsoft SMTPSVC(6.0.3790.1830);  Thu, 27 Oct 2005 09:45:48 -0400
Date: Thu, 27 Oct 2005 08:45:47 -0500
From: Jess Holle <[EMAIL PROTECTED]>
Subject: JSP Precompilation vs. JSR-45 Debugging
In-reply-to: <[EMAIL PROTECTED]>
To: Tomcat Users List 
Reply-to: "Tomcat Users List" 
Message-id: <[EMAIL PROTECTED]>
X-Envelope-from: [EMAIL PROTECTED]
X-Envelope-to: @bedge2-mail1.central.sun.com:[EMAIL PROTECTED]
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
Precedence: bulk
Delivered-to: mailing list users@tomcat.apache.org
Delivered-to: [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Received-SPF: pass (asf.osuosl.org: local policy)
X-Account-Key: account1
X-BrightmailFiltered: true
X-Brightmail-Tracker: AQAAA+k=
X-IronPort-AV: i="3.97,258,1125892800";   d="scan'208";
a="86074334:sNHT20043712"
X-ASF-Spam-Status: No, hits=0.5 required=10.0   tests=DNS_FROM_RFC_ABUSE
X-Spam-Check-By: apache.org
X-IronPort-AV: i="3.97,258,1125892800";   d="scan'208";
a="105871541:sNHT15778616"
X-Virus-Checked: Checked by ClamAV on apache.org
References: <[EMAIL PROTECTED]>
List-Post: 
List-Unsubscribe: 
List-Help: 
List-Id: 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-OriginalArrivalTime: 27 Oct 2005 13:45:48.0759 (UTC)
FILETIME=[BD025E70:01C5DAFC]

I have noticed that when I use an Ant script based on that documented in 
the Tomcat docs to precompile all my JSPs the resulting JSPs do not 
support source-level (JSR-45) debugging.


I thought I was doing something wrong so I looked through the JspC 
source code and I can't see how I could feed it anything more information.


As an added complication I have an extra directory that I need in the 
compilation classpath.  I have extended the web app classloader to 
handle this and added a line to the javac classpath in the Ant script.  
Thus things work fine in that respect but I need that to keep working -- 
I just want to have an option to do source-level JSP debugging as well.


What am I missing?

--
Jess Holle

-
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]
   




--

DO NOT REPLY [Bug 37281] New: - Current Status Summary is misleading

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37281

   Summary: Current Status Summary is misleading
   Product: Tomcat 5
   Version: 5.0.28
  Platform: Other
   URL: http://tomcat.apache.org/tomcat-5.0-doc/status.html
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


EXPECT: Tomcat 5.0.28 is identified as the latest stable release and 5.0.29 is
not mentioned (since it is not stable and 5.0.30 is more recent, if you are
going to mention something "unstable")

ACTUAL: "Tomcat 5.0.29 was released on October 6th, 2004. Work on the 5.0 branch
is primarily for maintenance and bug fixes. It is still considered the best
branch for production use, but Tomcat 5.5 is rapidly nearing a stable release."

-- 
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 37277] - long delay in Tomcat startup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37277





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 21:19 ---
A couple of other details in case they should help...
1) The server where this problem occurs is in the DMZ.
2) We did not see this problem happening under Tomcat 5.0.27 on this server
(though I couldn't guarantee that we had things configured the same way as we do
under Tomcat 5.5.9).

-- 
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 37277] - long delay in Tomcat startup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37277





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 21:15 ---
(In reply to comment #2)
Thanks for your quick response.
> Get thread dumps while the startup is in progress.
Can you tell me how or give me a pointer to instructions?

> If all your listeners are in web.xml - you can bypass this via
> processTlds=false.
> http://tomcat.apache.org/tomcat-5.5-doc/config/context.html

I don't know about listeners being in web.xml.
I have my  elements in server.xml. I added processTlds="false" to both
 elements. This did not fix the problem (no discernable change).

-- 
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 37277] - long delay in Tomcat startup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37277





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 20:24 ---
The slow startup is probably due to tomcat looking for tld files (that have
listeners) inside of jar files and in the file system (as required by the spec).

If all your listeners are in web.xml - you can bypass this via 
processTlds=false.

http://tomcat.apache.org/tomcat-5.5-doc/config/context.html



-- 
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]

Cluster startContext() SimpleTcpCluster

[local-underground]

Hello,

I am very curious why a Cluster does not make sure the context it is defined in 
is
actually started before listening?  This is proving to be a serious bug for me. 
 I am
implementing session replication where nested objects are defined via JNDI in 
my context.
 But when a new cluster member is added, it immediately receives a session and 
attempts
to deserialize the sessions before loading my context.. which is causing errors 
due to
classes not being found.

I see a startContext() defined in SimpleTcpCluser but it appears to be 
depracted and is
blank.  

I do realize I can make a global Resource and reference this JNDI within my 
context, but
I dont wanna move a huge chunk of my web application in global scope just to 
have these
references visible when the cluster starts.

Can some one explain the logic of why the Context is not loaded before the 
cluster
starts?  Can some one advise me on a quick fix to achieve this?


thanks in advance


chris
   





__ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

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

DO NOT REPLY [Bug 37247] - Busy workers counter doesn't count down

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37247





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 20:10 ---
I can confirm the restart under load resulting in large negative values.


-- 
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 37247] - Busy workers counter doesn't count down

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37247





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 20:09 ---
Version is the latest release, 1.2.14 running on an apache2 (2.0.52) in prefork
mode.

-- 
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 37246] - Election method T weirdness under constant heavy load

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37246





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 20:06 ---
Version is the latest release, 1.2.14 running on an apache2 in prefork mode.

Average response time of the page is about 3ms.

I could observe this behaviour for a few minutes - didn't run it much longer.
How long would make a difference?

-- 
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 37277] - long delay in Tomcat startup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37277





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 19:54 ---
Get thread dumps while the startup is in progress.

-- 
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: [Fwd: JSP Precompilation vs. JSR-45 Debugging]

[Kin-man Chung]

I believe Smap is suppressed by default in JSPC.  There is
a switch to term it on (-smap ?).  Don't remember what the
ant task attribute name is (smapSuppressed="false" ??).

-Kin-man

On Thu, 2005-10-27 at 09:14, Jess Holle wrote:
> Is this a more appropriate question for the dev list?
> 
> --
> Jess Holle
> 
> 
> __
> 
> From: Jess Holle <[EMAIL PROTECTED]>
> To: Tomcat Users List 
> Subject: JSP Precompilation vs. JSR-45 Debugging
> Date: 27 Oct 2005 08:45:47 -0500
> 
> Return-path: [EMAIL PROTECTED]
> Received: from hq-ex3fe1.ptcnet.ptc.com ([132.253.201.60])
>  by HQ-MAIL3.ptcnet.ptc.com with Microsoft SMTPSVC(6.0.3790.1830);Thu,
>  27 Oct 2005 09:46:17 -0400
> Received: from relay1.ptc.com ([12.11.148.121]) by hq-ex3fe1.ptcnet.ptc.com
>  with Microsoft SMTPSVC(6.0.3790.1830);   Thu, 27 Oct 2005 09:46:17 -0400
> Received: from hermes.apache.org (HELO mail.apache.org) ([209.237.227.199])
>  by relay1.ptc.com with SMTP; 27 Oct 2005 09:43:38 -0400
> Received: (qmail 4564 invoked by uid 500); 27 Oct 2005 13:43:36 -
> Received: (qmail 4547 invoked by uid 500); 27 Oct 2005 13:43:35 -
> Received: (qmail 4543 invoked by uid 99); 27 Oct 2005 13:43:35 -
> Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
>  by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Oct 2005 06:43:35 -0700
> Received: from [12.11.148.122] (HELO relay2.ptc.com) (12.11.148.122)
>  by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Oct 2005 06:43:29 -0700
> Received: from hq-ex3fe2.ptcnet.ptc.com ([132.253.201.63])
>  by relay2.ptc.com with ESMTP; 27 Oct 2005 09:43:11 -0400
> Received: from hq-ex3fe1.ptcnet.ptc.com ([132.253.201.60])
>  by HQ-EX3FE2.ptcnet.ptc.com with Microsoft SMTPSVC(6.0.3790.1830);   Thu,
>  27 Oct 2005 09:45:49 -0400
> Received: from [132.253.11.50] ([132.253.11.50]) by hq-ex3fe1.ptcnet.ptc.com
>  with Microsoft SMTPSVC(6.0.3790.1830);   Thu, 27 Oct 2005 09:45:48 -0400
> Date: Thu, 27 Oct 2005 08:45:47 -0500
> From: Jess Holle <[EMAIL PROTECTED]>
> Subject: JSP Precompilation vs. JSR-45 Debugging
> In-reply-to: <[EMAIL PROTECTED]>
> To: Tomcat Users List 
> Reply-to: "Tomcat Users List" 
> Message-id: <[EMAIL PROTECTED]>
> X-Envelope-from: [EMAIL PROTECTED]
> X-Envelope-to: @bedge2-mail1.central.sun.com:[EMAIL PROTECTED]
> MIME-version: 1.0
> Content-type: text/plain; format=flowed; charset=ISO-8859-1
> Content-transfer-encoding: 7BIT
> X-Accept-Language: en-us, en
> Precedence: bulk
> Delivered-to: mailing list users@tomcat.apache.org
> Delivered-to: [EMAIL PROTECTED]
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Received-SPF: pass (asf.osuosl.org: local policy)
> X-Account-Key: account1
> X-BrightmailFiltered: true
> X-Brightmail-Tracker: AQAAA+k=
> X-IronPort-AV: i="3.97,258,1125892800";   d="scan'208";
>  a="86074334:sNHT20043712"
> X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE
> X-Spam-Check-By: apache.org
> X-IronPort-AV: i="3.97,258,1125892800";   d="scan'208";
>  a="105871541:sNHT15778616"
> X-Virus-Checked: Checked by ClamAV on apache.org
> References: <[EMAIL PROTECTED]>
> List-Post: 
> List-Unsubscribe: 
> List-Help: 
> List-Id: 
> User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
> X-OriginalArrivalTime: 27 Oct 2005 13:45:48.0759 (UTC)
>  FILETIME=[BD025E70:01C5DAFC]
> 
> I have noticed that when I use an Ant script based on that documented in 
> the Tomcat docs to precompile all my JSPs the resulting JSPs do not 
> support source-level (JSR-45) debugging.
> 
> I thought I was doing something wrong so I looked through the JspC 
> source code and I can't see how I could feed it anything more information.
> 
> As an added complication I have an extra directory that I need in the 
> compilation classpath.  I have extended the web app classloader to 
> handle this and added a line to the javac classpath in the Ant script.  
> Thus things work fine in that respect but I need that to keep working -- 
> I just want to have an option to do source-level JSP debugging as well.
> 
> What am I missing?
> 
> --
> Jess Holle
> 
> -
> 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]

DO NOT REPLY [Bug 37277] - long delay in Tomcat startup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37277





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 19:39 ---
P.S. Interesting correlation...
When I had Tomcat configured to run one instance of a Cocoon webapp, it took 24
minutes to start. When there were two instances of Cocoon, it took 48 minutes. 
Hmm!

-- 
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: [Fwd: JSP Precompilation vs. JSR-45 Debugging]

[Jess Holle]

Not to reply to my own e-mail but after reading the sources this would 
appear to be squarely a Tomcat developer issue.


JspC.isSmapSuppressed() always returns true -- affording no opportunity 
to precompile while still generating JSR-45 debug info.


While that's a great default for production, I for one would really like 
the ability to set this to false in development so I can precompile 
*and* do JSP source level debugging.


Thoughts?  [Or is this already in 5.5.12?  I'm still at 5.5.9.]

--
Jess Holle

Jess Holle wrote:


Is this a more appropriate question for the dev list?

--
Jess Holle




Subject:
JSP Precompilation vs. JSR-45 Debugging
From:
Jess Holle <[EMAIL PROTECTED]>
Date:
Thu, 27 Oct 2005 08:45:47 -0500
To:
Tomcat Users List 

To:
Tomcat Users List 


I have noticed that when I use an Ant script based on that documented 
in the Tomcat docs to precompile all my JSPs the resulting JSPs do not 
support source-level (JSR-45) debugging.


I thought I was doing something wrong so I looked through the JspC 
source code and I can't see how I could feed it anything more 
information.


As an added complication I have an extra directory that I need in the 
compilation classpath.  I have extended the web app classloader to 
handle this and added a line to the javac classpath in the Ant 
script.  Thus things work fine in that respect but I need that to keep 
working -- I just want to have an option to do source-level JSP 
debugging as well.


What am I missing?

--
Jess Holle

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

Re: [Fwd: JSP Precompilation vs. JSR-45 Debugging]

[Jess Holle]

P.S. If this is as simple as adding a field for this property and a 
setter, then I'll go ahead and do this in my own Tomcat distro if 
nothing else...


--
Jess Holle

Jess Holle wrote:

Not to reply to my own e-mail but after reading the sources this would 
appear to be squarely a Tomcat developer issue.


JspC.isSmapSuppressed() always returns true -- affording no 
opportunity to precompile while still generating JSR-45 debug info.


While that's a great default for production, I for one would really 
like the ability to set this to false in development so I can 
precompile *and* do JSP source level debugging.


Thoughts?  [Or is this already in 5.5.12?  I'm still at 5.5.9.]

--
Jess Holle

Jess Holle wrote:


Is this a more appropriate question for the dev list?

--
Jess Holle




Subject:
JSP Precompilation vs. JSR-45 Debugging
From:
Jess Holle <[EMAIL PROTECTED]>
Date:
Thu, 27 Oct 2005 08:45:47 -0500
To:
Tomcat Users List 

To:
Tomcat Users List 


I have noticed that when I use an Ant script based on that documented 
in the Tomcat docs to precompile all my JSPs the resulting JSPs do 
not support source-level (JSR-45) debugging.


I thought I was doing something wrong so I looked through the JspC 
source code and I can't see how I could feed it anything more 
information.


As an added complication I have an extra directory that I need in the 
compilation classpath.  I have extended the web app classloader to 
handle this and added a line to the javac classpath in the Ant 
script.  Thus things work fine in that respect but I need that to 
keep working -- I just want to have an option to do source-level JSP 
debugging as well.


What am I missing?

--
Jess Holle

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

DO NOT REPLY [Bug 37277] New: - long delay in Tomcat startup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37277

   Summary: long delay in Tomcat startup
   Product: Tomcat 5
   Version: 5.5.12
  Platform: PC
   URL: http://forum.java.sun.com/thread.jspa?messageID=3951945
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connector:Coyote
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I'm using Tomcat 5.5.9, but I see from
http://forum.java.sun.com/thread.jspa?messageID=3951945 that it's still an issue
in 5.5.12. JDK1.5

When Tomcat starts without webapps, it starts quickly: within a few seconds I
can type http://localhost/manager/html/list in a browser and get a response.
But when I put webapps in (either with a  in server.xml or by dropping
them in the webapps folder), Tomcat can take 14 min, 24 min, or even longer to
start up. During that time, browser requests are met with an endlessly circling
throbber.
The webapp I'm using is Cocoon, but others (see above link) have reported the
same problem with other webapps. The problem has been intermittent for us, but
right now on our production server, it is happening every time.

There are no errors in the Cocoon logs.
An excerpt from the Tomcat stderr log shows where it took over 24 minutes to get
from
   Oct 27, 2005 10:21:59 AM org.apache.catalina.core.StandardHost start
   INFO: XML validation disabled
to 
   Oct 27, 2005 10:46:06 AM org.apache.coyote.http11.Http11Protocol start
   INFO: Starting Coyote HTTP/1.1 on http-8080

Oct 27, 2005 10:21:58 AM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
Oct 27, 2005 10:21:58 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 1031 ms
Oct 27, 2005 10:21:59 AM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Oct 27, 2005 10:21:59 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5.9
Oct 27, 2005 10:21:59 AM org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
Oct 27, 2005 10:46:06 AM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Oct 27, 2005 10:46:06 AM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
Oct 27, 2005 10:46:06 AM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/46  config=null
Oct 27, 2005 10:46:06 AM org.apache.catalina.storeconfig.StoreLoader load
INFO: Find registry server-registry.xml at classpath resource
Oct 27, 2005 10:46:06 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 1448022 ms

Thinking the delay might be caused by the XML parser trying to chase down DTD
urls in XML config files, I removed such DOCTYPE declarations where I could find
them. But it didn't help.
I really don't know if this is a Tomcat bug, but it's a serious problem.

Incidentally, we upped our Java memory settings to 512MB (init) and 1024MB
(max), but that didn't help.

-- 
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 37186] - Add path/filename of xml config file that failed parsing at catalina startup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37186


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|enhancement |normal




--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 19:13 ---
I have been bitten by similar er... problems in the past and would agree with
the OP that his point #1 is a very significant one. Yes, as Markus pointed out,
XML has strict well-formedness rules. But the purpose of those rules is to make
syntax errors/inconsistencies stand out early, so they can be fixed. Reporting
ill-formed XML without reporting the file it occurred in falls far short of this
purpose. I have spent valuable time trying to track down Tomcat's reported XML
parsing problems in the past, and eventually gave up.

I propose changing the severity of this issue from "enhancement" to "normal" or
at least "minor".

-- 
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 37262] - JDBC datasources are never released

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37262





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 18:28 ---
Glen, of course I close my connections. But the datasource uses a connection
pool and the underlying JDBC connection in not really closed but just returned
to the pool. It is the responsibility of the container who manages the
datasource to call close() (on the datasource, not the connection) when the
context is stopped.

Part of the problem is that javax.sql.DataSource does not provide a close()
method, only the DBCP DataSource does. But this makes sense to me, because
javax.sql.DataSource is an interface for the users, and the appserver should use
its own means to cleanup the datasource. The users should not be able to close a
datasource, because it is meant to be managed by the appserver.

Here is a quote from the JDBC 3.0 spec the mentions that an appserver
implementation closes a datasource.

"A connection pool manager shuts down a physical connection by calling the
method PooledConnection.close. This method is typically called only in
certain circumstances: when the application server is undergoing an orderly
shutdown, when the connection cache is being reinitialized, or when the
application server receives an event indicating that an unrecoverable error has
occurred on the connection." 

The connection manager is DBCP but it has no way of knowing that the tomcat
context is stopped. That's why, for a proper integration there needs to be some
glueing code that listens to tomcat lifecycle events and notifies DBCP. It
doesn't strictly belong to Tomcat, it doesn't strictly belong to DBCP, so that's
why it does not exist.

-- 
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]

[Fwd: JSP Precompilation vs. JSR-45 Debugging]

[Jess Holle]

Is this a more appropriate question for the dev list?

--
Jess Holle

--- Begin Message ---
I have noticed that when I use an Ant script based on that documented in 
the Tomcat docs to precompile all my JSPs the resulting JSPs do not 
support source-level (JSR-45) debugging.


I thought I was doing something wrong so I looked through the JspC 
source code and I can't see how I could feed it anything more information.


As an added complication I have an extra directory that I need in the 
compilation classpath.  I have extended the web app classloader to 
handle this and added a line to the javac classpath in the Ant script.  
Thus things work fine in that respect but I need that to keep working -- 
I just want to have an option to do source-level JSP debugging as well.


What am I missing?

--
Jess Holle

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


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

DO NOT REPLY [Bug 37273] - Under stress, tomcat generates multiple threads/processors for the same request

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37273


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 17:59 ---
You will need to provide a hard proof of this, or investigate more. I think the
thread pool code is explicit enough.

I recommend you use users@tomcat.apache.org to debug this.

-- 
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 37273] New: - Under stress, tomcat generates multiple threads/processors for the same request

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37273

   Summary: Under stress, tomcat generates multiple
threads/processors for the same request
   Product: Tomcat 5
   Version: 5.5.9
  Platform: Other
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P2
 Component: Connector:HTTP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I had make a stress-test at our web-application with Grinder and jMeter.
After 5 minutes Tomcat generates several http-80-Processors for one request.
This causes that the corresponding Servlet-class runs multiple 
at the same time (of course with the same sessionID) and 
throws deadlocks in our application.
It must be a Bug because in regular load the 
Tomcat runs (correct)/(dont multiply processors)

-- 
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 37262] - JDBC datasources are never released

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37262





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 17:54 ---
(In reply to comment #7)
> If the Tomcat team decides that DBCP is a "proprietary" external library that
> does not deserve proper integration and furthermore connections leaks are
> something totally acceptable, than the documentation at
> http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html
> should be updated to reflect this position. Funny enough, the doc guides the
> users how not to leak connections, but when tomcat does it, it's OK :-(

Hmmm...is the responsibility of Tomcat to just release DBCP when it is no longer
needed (by any webapp it is hosting), or DBCP's connections as well when just
one webapp no longer needs it?  Interesting question--the latter may be too
granular for it.

At any rate, please check the Servlet 2.4 Specification, the very small section
SRV.10.2.2 -- for the example given, it appears to indicate that the Developer
(that's you ;) should create a servlet context listener class in order to close
database connection(s).  If so, the only issue appears to be then, does Tomcat
give you access to the DBCP object(s) necessary to do such connection closing?

Glen


-- 
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 37262] - JDBC datasources are never released

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37262





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 17:35 ---
If the Tomcat team decides that DBCP is a "proprietary" external library that
does not deserve proper integration and furthermore connections leaks are
something totally acceptable, than the documentation at
http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html
should be updated to reflect this position. Funny enough, the doc guides the
users how not to leak connections, but when tomcat does it, it's OK :-(

-- 
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 37262] - JDBC datasources are never released

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37262





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 16:42 ---
(In reply to comment #3)
> No, we will not add proprietary code to release any resource provider 
> resources
> (obviously, almost every resource provider will need something ...), but 
> rather
> it is up to it to have its cleanup code. DBCP can do this by closing inactive
> connections, and everything should eventually be GCed.
> 
> Obviously, feel free to use your own custom code as needed.

Remy, 

I would agree that there would be a big can of worms here if Tomcat needed to
import:
+import com.mycompany.MyResource;
+import com.acme.MyBasicDataSource;

etc., etc., non-integrated resources, just to keep manually closing each
resource--there would be no end to it.

But looking at the import statement needed for this patch:
+import org.apache.--->tomcat<---.dbcp.dbcp.BasicDataSource;

It seems that DBCP has already been specifically integrated within
Tomcat[1]--i.e., the proprietary code is already there--and for that reason,
Tomcat should perhaps take care of DBCP cleanup needs.

OTOH, is there a bug with the implementation of DBCP that is not causing these
connections to close on its own--i.e., insufficient timeouts or other
enhancements that DBCP can (rightfully?) provide that will not require any
changes to Tomcat?  Maybe a patch should be submitted to DBCP instead.

Also, slightly different topic, needing to modify and rebuild Tomcat in order to
close proprietary resource providers seems nonideal.  Is there a cleaner way
within the servlet specification that this can be done without needing to recode
& rebuild Tomcat?  Just asking as a newbie here--I'm hardly a Tomcat/servlet 
expert.

Thanks,
Glen

[1] http://tinyurl.com/7ebqn


-- 
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 37271] New: - Deployer.install()/JMX bug results in HTTP 302 redirect responses

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37271

   Summary: Deployer.install()/JMX bug results in HTTP 302 redirect
responses
   Product: Tomcat 5
   Version: 5.0.28
  Platform: HP
OS/Version: HP-UX
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


When Tomcat is started using org.apache.catalina.startup.Embedded and 
deployer.install() is called several (eg 5) times in quick succession the 
servlet contexts may be incompletely deployed.

Given this problem, after deployment when in use requests to a URL 
(eg. /localhost/eaifclient) are being rejected with a 302 response indicating 
a redirect to the same URL but with "/" appended (eg./localhost/eaifclient/) 
This appears to be random. The same request can be repeated and will 
sporadically pass or fail each time the application using embedded Tomcat is 
re-started.

Analysis shows that after deployment, in the cases where incoming HTTP 
requests succeeded Mapper::internalMapWrapper() was able to find a wild card 
mapping in rule 2 (prefix match) for the context "eaifclient".  When the 
request fails, rule 2 does not find the wildcard mapping and sets the redirect 
path because the context.wildcardWrappers array is empty.

The web.xml for each of the servlets contain mappings similar to the following:
  
eaifclient
*
  

There appears to be a race condition within the JMX deployment of the contexts.

Analysis of this theory revealed that in the cases where incoming HTTP 
requests failed, there are fewer the JMX triggered calls during deployment to 
the addWrapper()  methods compared with the number of calls in successful 
cases.  addWrapper(Context context, String path, Object wrapper, boolean 
jspWildCard) soes not called to set a wrapper ending with "/*" for the servlet 
context of the requests that fail.

The problems do not occur if the contexts are deployed using 
embedded.createContext() before Tomcat is started.

The java version on HPUX is 1.4.2.08-050401-17:46.  The problem also occurs 
very occasionally on Windows XP running java 1.4.2_08.

-- 
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 37264] - ServletContextListener cannot load classes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37264


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 16:04 ---
I did apply something very close to the proposed patch, but did not test it 
well.

-- 
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 commit: r328876 - in /tomcat/container/tc5.5.x: catalina/src/share/org/apache/catalina/core/StandardContext.java webapps/docs/changelog.xml

[remm]

Author: remm
Date: Thu Oct 27 07:02:41 2005
New Revision: 328876

URL: http://svn.apache.org/viewcvs?rev=328876&view=rev
Log:
- 37264: JNDI resources were no longer available when stopping listeners.
- Not tested well.
- Submitted by Bogdan Calmac.

Modified:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardContext.java
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardContext.java
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardContext.java?rev=328876&r1=328875&r2=328876&view=diff
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardContext.java
 (original)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/core/StandardContext.java
 Thu Oct 27 07:02:41 2005
@@ -4271,6 +4271,9 @@
 // Stop our filters
 filterStop();
 
+// Stop our application listeners
+listenerStop();
+
 // Stop ContainerBackgroundProcessor thread
 super.threadStop();
 
@@ -4301,9 +4304,6 @@
 if (children[i] instanceof Lifecycle)
 ((Lifecycle) children[i]).stop();
 }
-
-// Stop our application listeners
-listenerStop();
 
 // Clear all application-originated servlet context attributes
 if (context != null)

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewcvs/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=328876&r1=328875&r2=328876&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Thu Oct 27 07:02:41 2005
@@ -57,6 +57,10 @@
 set by the realm unless hasRole is overriden, which was no longer 
being done properly for
 the JAAS realm (remm)
   
+  
+37264: JNDI resources were no longer available when 
stopping listeners,
+submitted by Bogdan Calmac (remm)
+  
 
   
   



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

DO NOT REPLY [Bug 37264] - ServletContextListener cannot load classes

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=37264





--- Additional Comments From [EMAIL PROTECTED]  2005-10-27 16:02 ---
I don't like the patch either, it is indeed more appropiate to move some code
from STOP_EVENT to AFTER_STOP_EVENT. I'll test the patch and post the results.
With my limited knowledge of the code base, I think the fix involves moving this
whole block from STOP to AFTER_STOP:

if (container instanceof Context) {
ContextBindings.unbindClassLoader
(container, container, 
 ((Container) container).getLoader().getClassLoader());
}

if (container instanceof Server) {
namingResources.removePropertyChangeListener(this);
ContextBindings.unbindClassLoader
(container, container, 
 this.getClass().getClassLoader());
}

ContextAccessController.unsetSecurityToken(getName(), container);

namingContext = null;
envCtx = null;
compCtx = null;
initialized = false;


-- 
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 commit: r328875 [2/2] - in /tomcat/site/trunk: docs/ docs/faq/ docs/faq/printer/ xdocs-faq/ xdocs/

[yoavs]

Modified: tomcat/site/trunk/docs/faq/printer/cluster.html
URL: 
http://svn.apache.org/viewcvs/tomcat/site/trunk/docs/faq/printer/cluster.html?rev=328875&r1=328874&r2=328875&view=diff
==
--- tomcat/site/trunk/docs/faq/printer/cluster.html (original)
+++ tomcat/site/trunk/docs/faq/printer/cluster.html Thu Oct 27 06:57:53 2005
@@ -1,4 +1,4 @@
-Tomcat FAQ - Cluster
+