RE: Source jar for tomcat-dbcp?

2012-03-11 Thread Jim Garrison
  It would have been nice if this was noted in the docs :-)
 
 Sounds like you're pretty close to being able to make a patch.  ;)

I'm willing to write something up, but am not sure how to contribute it to the
doc website.  I rummaged through the ASF svn and found the tomcat/site
stuff, but it seems to be old and does not look like the current doc website.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Source jar for tomcat-dbcp?

2012-03-10 Thread Jim Garrison
I have a problem I need to debug by stepping into tomcat-dbcp (6.0.35). I tried 
downloading the Apache commons-dbcp source but it seems the version in Tomcat 
has the classes in different packages, so I can't get Eclipse to recognize the 
source.

I've searched the following areas:

*  the tomcat source zip (apache-tomcat-6.0.35-src.zip) -- it does not contain 
the dbcp source
*  archive.apache.org/dist/tomcat/tomcat-6
*  maven-central; it has source jars for tomcat 7, but none for tomcat 6.
* svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_35/java -- this does 
not contain the dbcp sources either
* svn.apache.org/repos/asf/tomcat/tags/JDBC_POOL_1_1_0_1/ -- This looked 
promising, but on examination it does not seem to contain the source for the 
library in 6.0.35

The tomcat-dbcp.jar that came with 6.0.35 contains the following packages:

   org.apache.tomcat.dbcp.collections
   org.apache.tomcat.dbcp.dbcp
   org.apache.tomcat.dbcp.dbcp.cpdsadapter
   org.apache.tomcat.dbcp.datasources
   org.apache.tomcat.dbcp.jocl
   org.apache.tomcat.dbcp.pool
   org.apache.tomcat.dbcp.pool.impl

So, where can I find the source for tomcat-dbcp 6.0.35?


RE: Source jar for tomcat-dbcp?

2012-03-10 Thread Jim Garrison
 -Original Message-
 From: Jim Garrison [mailto:jim.garri...@troux.com]
 Sent: Saturday, March 10, 2012 7:07 PM
 To: users@tomcat.apache.org
 Subject: Source jar for tomcat-dbcp?
 
 I have a problem I need to debug by stepping into tomcat-dbcp (6.0.35). I
 tried downloading the Apache commons-dbcp source but it seems the
 version in Tomcat has the classes in different packages, so I can't get 
 Eclipse
 to recognize the source.
[snip]

I think I've figured this out.  In build.xml, the commons-dbcp sources are 
copied into a different package hierarchy and then built.  

Based on build.properties.default I see that it uses commons-dbcp version 1.3 
and commons-pool version 1.5.6.

So all I need to do is duplicate what build.xml does to assemble the sources in 
the proper locations.

It would have been nice if this was noted in the docs :-)

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



RE: tomcat6w.exe -- 32bit and 64bit versions identical?

2012-03-07 Thread Jim Garrison
 -Original Message-
 From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
 Sent: Tuesday, March 06, 2012 12:27 PM
 To: Tomcat Users List
 Subject: RE: tomcat6w.exe -- 32bit and 64bit versions identical?
 
  From: Jim Garrison [mailto:jim.garri...@troux.com]
  Subject: tomcat6w.exe -- 32bit and 64bit versions identical?
 
  The two versions of tomcat6w.exe are identical.
 
  Is this correct?
 
 That is correct.  The tomcat6w.exe program does not access the JVM, so it
 need not match the JVM's execution mode.

Thanks. Is that a change from 6.0.20?

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



tomcat6w.exe -- 32bit and 64bit versions identical?

2012-03-06 Thread Jim Garrison
I am in an environment where I deploy tomcat via a script.  Rather than keep 
two entire copies of Tomcat for 32- and 64-bit systems I have the complete 
32-bit download plus the 64-bit tomcat6*.exe files.  I'm upgrading from 6.0.20 
to 6.0.35 and my usual procedure is to diff the 32- and 64-bit versions, which 
in the past has found only those differences (and tcnative-1.dll).  This time, 
when diffing apache-tomcat-6.0.35-windows-x64 with 
apache-tomcat-6.0.35-windows-x86, I get only tomcat6.exe as different.  The two 
versions of tomcat6w.exe are identical.

Is this correct?


disableProxyCaching in Tomcat6?

2009-12-10 Thread Jim Garrison
In Tomcat5 there was a Context parameter disableProxyCaching to prevent 
proxies from caching content.  This parameter doesn't seem to be present in 
Tomcat6.  Is there an equivalent setting?


RE: DelegatingCallableStatement.getInnermostDelegate() -- NoSuchMethodError

2008-03-17 Thread Jim Garrison

 -Original Message-
 From: Phil Steitz [mailto:[EMAIL PROTECTED]
 Sent: Saturday, March 15, 2008 5:09 PM
 To: Tomcat Users List
 Subject: Re: DelegatingCallableStatement.getInnermostDelegate() --
 NoSuchMethodError
 
 This looks like a signature from dbcp 1.1.  Are you sure you used dbcp
 1.2+ when you compiled the classes below?  In dbcp 1.1,
 getInnermostDelegate is implemented in DelegatingCallableStatement and
 it returns a CallableStatement.  In 1.2, inheritance is as you
 describe and this method returns a Statement (which you need to cast
 to CallableStatement).

That was it.  That was also the one possibility I hadn't considered :-)
Thanks for the assistance.

IMPORTANT NOTICE:
This message may contain confidential information. If you have received this 
e-mail in error, do not use, copy or distribute it. Do not open any 
attachments. Delete it immediately from your system and notify the sender 
promptly by e-mail that you have done so. Thank you.



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



DelegatingCallableStatement.getInnermostDelegate() -- NoSuchMethodError

2008-03-14 Thread Jim Garrison

I'm getting a NoSuchMethodError on 
org.apache.commons.dbcp.DelegatingCallableStatement.getInnermostDelegate
().

AFAICT DelegatingCallableStatement inherits ultimately from
DelegatingStatement, which DOES have such a method. I've examined the
commons-dbcp-1.2.1.jar file that's in the classpath, and the
inheritance hierarchy looks OK and there IS a getInnermostDelegate()
method on DelegatingStatement.


Since this is running in BusinessObjects' Tomcat 5.0 server I thought
there might be a classloader problem.  I printed out the classloaders
at the point where the error happens, but the debugging output seems
to indicate that everything should work -- but I still get the
exception.  I can't really post an SSCCE as this is buried in a much
larger system that runs only under Tomcat.

Source Fragment
===

import java.sql.*;
import org.apache.commons.dbcp.DelegatingCallableStatement;
.
.
.
PreparedStatement stmt;
.
.
.
protected void executeStatement() throws SQLException
{
  if ( TPMonitor.TYPE_ORACLE == TPMonitor.getInstance().getDBType() )
  {
System.out.println(DBTYPE: ORA);
System.out.println(stmt CLASS:  + stmt.getClass().getName());
System.out.println(stmt LOADER:  +
stmt.getClass().getClassLoader().toString());

DelegatingCallableStatement dcs = (DelegatingCallableStatement)
stmt;
System.out.println(dcs CLASS:  + dcs.getClass().getName());
System.out.println(dcs LOADER:  +
dcs.getClass().getClassLoader().toString());

Statement cs = dcs.getInnermostDelegate();


The above statement throws the following exception:

java.lang.NoSuchMethodError:
org.apache.commons.dbcp.DelegatingCallableStatement.getInnermostDelegate
()Ljava/sql/CallableStatement;



Debugging Output


DBTYPE: ORA
stmt CLASS: org.apache.commons.dbcp.DelegatingCallableStatement
stmt LOADER: StandardClassLoader
  delegate: true
  repositories:
file:C:\Program Files\Business Objects\Tomcat\common\classes\
file:C:\Program Files\Business
Objects\Tomcat\common\endorsed\xalan.jar
file:C:\Program Files\Business
Objects\Tomcat\common\endorsed\xercesImpl.jar
file:C:\Program Files\Business
Objects\Tomcat\common\endorsed\xml-apis.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\ant-launcher.jar
file:C:\Program Files\Business Objects\Tomcat\common\lib\ant.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\commons-collections-2.1.1.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\commons-dbcp-1.2.1.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\commons-el.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\commons-pool-1.2.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\jasper-compiler.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\jasper-runtime.jar
file:C:\Program Files\Business Objects\Tomcat\common\lib\jsp-api.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\naming-common.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\naming-factory.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\naming-java.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\naming-resources.jar
file:C:\Program Files\Business Objects\Tomcat\common\lib\ojdbc14.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\servlet-api.jar
file:C:\Program Files\Business Objects\Tomcat\common\lib\sqljdbc.jar
-- Parent Classloader:
[EMAIL PROTECTED]

dcs CLASS: org.apache.commons.dbcp.DelegatingCallableStatement
dcs LOADER: StandardClassLoader
  delegate: true
  repositories:
file:C:\Program Files\Business Objects\Tomcat\common\classes\
file:C:\Program Files\Business
Objects\Tomcat\common\endorsed\xalan.jar
file:C:\Program Files\Business
Objects\Tomcat\common\endorsed\xercesImpl.jar
file:C:\Program Files\Business
Objects\Tomcat\common\endorsed\xml-apis.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\ant-launcher.jar
file:C:\Program Files\Business Objects\Tomcat\common\lib\ant.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\commons-collections-2.1.1.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\commons-dbcp-1.2.1.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\commons-el.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\commons-pool-1.2.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\jasper-compiler.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\jasper-runtime.jar
file:C:\Program Files\Business Objects\Tomcat\common\lib\jsp-api.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\naming-common.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\naming-factory.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\naming-java.jar
file:C:\Program Files\Business
Objects\Tomcat\common\lib\naming-resources.jar

RE: Listener Shutdown Order?

2007-11-15 Thread Jim Garrison


 -Original Message-
 From: Christopher Schultz [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 14, 2007 12:34 PM
 To: Tomcat Users List
 Subject: Re: Listener Shutdown Order?
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Jim,
 
 Jim Garrison wrote:
  From: Christopher Schultz [mailto:[EMAIL PROTECTED]
 
  Notification that the servlet context is *about* to be shut down.
All
  servlets and filters have been destroy()ed before any
  ServletContextListeners are notified of context destruction.
 
  What I'm seeing is that servlet destroy() is being called AFTER the
  listeners have been shutdown.  If I'm reading the quote above right,
  this shouldn't happen; servlets should have already been destroy()ed
  before the listener is shutdown.
 
 
 I checked the Tomcat 5.5 source, and this is what happens in
 StandardContext.stop():
 
 .
 .
 .

You are, of course, correct and there is no bug.  I was getting confused
due to multiple contexts running in a single server.  I've sorted
everything out now and it all appears to work as expected.

The root cause of my confusion was a bug in the Eclipse debugger's
variable-value tooltip display, which can display the wrong value if
there are two instances of a Class loaded under different classloaders.

IMPORTANT NOTICE:
This message may contain confidential information. If you have received this 
e-mail in error, do not use, copy or distribute it. Do not open any 
attachments. Delete it immediately from your system and notify the sender 
promptly by e-mail that you have done so. Thank you.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Listener Shutdown Order?

2007-11-14 Thread Jim Garrison
When starting up, Listeners are started before load-on-startup servlets,
so we use this mechanism to initialize Spring.

 

On shutdown, Tomcat seems to shutdown listeners BEFORE the servlets.
This results in the Spring context being discarded while it is still
needed.  If context listeners start before servlets, shouldn't the
listeners be shutdown AFTER the servlets?


IMPORTANT NOTICE:
This message may contain confidential information. If you have received this 
e-mail in error, do not use, copy or distribute it. Do not open any 
attachments. Delete it immediately from your system and notify the sender 
promptly by e-mail that you have done so. Thank you.



RE: Listener Shutdown Order?

2007-11-14 Thread Jim Garrison


 -Original Message-
 From: Christopher Schultz [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, November 14, 2007 11:43 AM
 
 Notification that the servlet context is *about* to be shut down. All
 servlets and filters have been destroy()ed before any
 ServletContextListeners are notified of context destruction.

What I'm seeing is that servlet destroy() is being called AFTER the
listeners have been shutdown.  If I'm reading the quote above right,
this shouldn't happen; servlets should have already been destroy()ed
before the listener is shutdown.  

The problem is that the non-Spring servlet needs to notify a Spring
based component to shutdown, and can't get to it after the Spring
ApplicationContext is gone.

BTW, thanks for the quick reply.


IMPORTANT NOTICE:
This message may contain confidential information. If you have received this 
e-mail in error, do not use, copy or distribute it. Do not open any 
attachments. Delete it immediately from your system and notify the sender 
promptly by e-mail that you have done so. Thank you.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]