DO NOT REPLY [Bug 11158] New: - WebappClassLoader does'nt find any class in an external repository

2002-07-25 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11158.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11158

WebappClassLoader does'nt find any class in an external repository

   Summary: WebappClassLoader does'nt find any class in an external
repository
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The method findClassInternal cannot return null when the required class
is not in one of the local repositories but in one of the external
repositories.
In this case, this method throws an exception and it does'not return null
This implies that the call to super.findClass(name);  in the method
findClass of WebappClassLoader (line 954) cannot be done.

To reproduce this bug you must add an extenal repository to the set of places 
the WebappClassLoader can look for classes to be loaded.

To do that, I propose you to call my method addRepositoryInClassLoader in 
the init method of the first servlet load-on-startups


  //
  private static String CATALINA_LOADER 
=org.apache.catalina.loader.WebappClassLoader;

  
  //
  /**
  * invoke the method public void addRepository(String repository)
  * if it is an instance of org.apache.catalina.loader.WebappClassLoader
  */
  private void addRepositoryInClassLoader(String aRepository) throws 
ServletException
  {
ClassLoader wClassLoader = Thread.currentThread().getContextClassLoader();
String wClassLoaderName = wClassLoader.getClass().getName();

log(---setClassLoader:);
log(CStringFacilities.toStringDescr(ClassLoaderName,wClassLoaderName));

/* this test replace instanceof which return false if the tested class is
instancied by an other class loader (other name space !)*/
if (wClassLoaderName.equals(CATALINA_LOADER)){
  
  /* build the URL of the external repository */
  String wUrl = file:+ aRepository;
  
  /* invoke addRepository(String aRep) */
  try {
Class[] wParameterTypes  = new Class[]{String.class};
Object[] wArguments = new Object[] {wUrl};
Method wMethodAddRepository = wClassLoader.getClass().getMethod
(addRepository,wParameterTypes );
wMethodAddRepository.invoke(wClassLoader,wArguments);
  } catch (Exception e) {
log(Can't invoke addRepository(String aRep)\n + 
CStringFacilities.eToString(e));
  }
  
  /* invoke getURLs() */
  try {
Method wMethodGetUrl = wClassLoader.getClass().getMethod(getURLs,new 
Class[0] );
RL[] wUrls = (URL[])wMethodGetUrl.invoke(wClassLoader, new Object[0] );
int wMax = wUrls.length;
for (int wI=0;wIwMax;wI++){
  log(CStringFacilities.toStringDescr(external repository 
[+wI+],wUrls[wI].toString() ));
}
  } catch (Exception e) {
log(Can't invoke getURLs()\n +CStringFacilities.eToString(e));
  }
}
  }

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




DO NOT REPLY [Bug 11149] - Tomcat shutdown requires resolvable hostname

2002-07-25 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11149.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11149

Tomcat shutdown requires resolvable hostname

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-07-25 07:14 ---
Tomcat needs to establish a socket connection to signal a shutdown.  You can 
specify the attribute address=127.0.0.1 in the Ajp12Connector element if you 
only ever want to be able to shutdown from the machine that Tomcat is running 
on.  Otherwise, you can specify the IP address in the attribute or use the -
host ip.address.of.tomcat parameter to shutdown.sh.

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




mod_jk2.so compiled (after patching), but won't install

2002-07-25 Thread Dev Zero G Ltd

First of all - many many thanks to everybody who has helped so far - we 
really appreciate it.. Just one last push required. :)

We finally got mod_jk2.so and libjkjni.so to compile (see patch history 
at the bottom of the mail), but can't install. We put them into 
$(APACHE2_HOME)/modules and $(CATALINA_HOME)/lib accordingly.

But after running $(APACHE2_HOME)/bin/apachectl configtest we get an 
error message:

--- error start ---
file://augada/usr/local/apache2/modules ../bin/apachectl configtest
Syntax error on line 231 of /usr/local/apache2/conf/httpd.conf:
Cannot load /usr/local/apache2/modules/mod_jk2.so into server:
/usr/local/apache2/modules/mod_jk2.so: Undefined symbol
apr_thread_mutex_trylock
--- error end ---

What could it be?

--- patch history start ---
Filename: jk\native2\include\jk_mutex.h

Line #:75
Old line  :
#ifdef HAS_APR
New line:
#if APR_HAS_THREADS

Line #:121
Old line  :
#ifdef APR_HAS_THREADS

New line:
#if APR_HAS_THREADS

Reason:This conditional define statement adjusts variable
definition (threadMutex). Type of this variable depends on define
directive conditions, but to have needed types there are some #ifdef
statements on lines 75-81. So, those definition statements are not
the same, and this situation causes build-time error, when compiler
includes one header file (with one type defined inside), but variable
tries to have another type (found by me in another .h file - not
included while build time due to #ifdef directives). Such changes
were done experimentally and may be not 100% correct. In original
compiler fails with message like syntax error on before
apr_thread_mutex_t in line 121

Filename jk\native2\build.xml

Line #:  374
Action: commented

Reason   :Having this link option uncommented (original) I could
not acquire libjkjni.so, only .a and .la files present. As far as I
am dummy in FreeBSD C/C++, I used something
try-to-change-something-and-see-what-you-get method (it has pretty
russian idiom,but I don't know its analog in English)

Filename: jk\build.properties

Some pathes set to correspond to reality (path to apache, etc)

Filename:jk\native\apache-2.0\build-unix.sh

Line #:  44
Action:commented.
Line #:  46
Action:  uncommented and approved
New line:
INCLUDE=-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE

Reason:while compiling mod_jk.so compiler could not see
connectors includes. I added first statement to make it visible
--- patch history end ---




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




DO NOT REPLY [Bug 6832] - Locale of the browser is ignored by the AJP13 connector

2002-07-25 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6832.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6832

Locale of the browser is ignored by the AJP13 connector





--- Additional Comments From [EMAIL PROTECTED]  2002-07-25 08:47 ---
zmiana z ajp13 na mod_jk2

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




Re: mod_jk2.so compiled (after patching), but won't install

2002-07-25 Thread Henri Gomez

Quoting Dev Zero G Ltd [EMAIL PROTECTED]:

 First of all - many many thanks to everybody who has helped so far - we 
 really appreciate it.. Just one last push required. :)
 
 We finally got mod_jk2.so and libjkjni.so to compile (see patch history 
 at the bottom of the mail), but can't install. We put them into 
 $(APACHE2_HOME)/modules and $(CATALINA_HOME)/lib accordingly.
 
 But after running $(APACHE2_HOME)/bin/apachectl configtest we get an 
 error message:
 
 --- error start ---
 file://augada/usr/local/apache2/modules ../bin/apachectl configtest
 Syntax error on line 231 of /usr/local/apache2/conf/httpd.conf:
 Cannot load /usr/local/apache2/modules/mod_jk2.so into server:
 /usr/local/apache2/modules/mod_jk2.so: Undefined symbol
 apr_thread_mutex_trylock
 --- error end ---
 
 What could it be?

Which version of Apache 2.0 did you have ?


 --- patch history start ---
 Filename: jk\native2\include\jk_mutex.h
 
 Line #:75
 Old line  :
 #ifdef HAS_APR
 New line:
 #if APR_HAS_THREADS

+1

 #ifdef HAS_APR


 Line #:121
 Old line  :
 #ifdef APR_HAS_THREADS
 
 New line:
 #if APR_HAS_THREADS
 
 Reason:This conditional define statement adjusts variable
 definition (threadMutex). Type of this variable depends on define
 directive conditions, but to have needed types there are some #ifdef
 statements on lines 75-81. So, those definition statements are not
 the same, and this situation causes build-time error, when compiler
 includes one header file (with one type defined inside), but variable
 tries to have another type (found by me in another .h file - not
 included while build time due to #ifdef directives). Such changes
 were done experimentally and may be not 100% correct. In original
 compiler fails with message like syntax error on before
 apr_thread_mutex_t in line 121

apr.h have #define APR_AS_THREADS 1 so both should be the same.
Didn't have any build error with that on Linux Redhat 7.2 + apache 2.0.39 ...

 Filename jk\native2\build.xml
 
 Line #:  374
 Action: commented
 
 Reason   :Having this link option uncommented (original) I could
 not acquire libjkjni.so, only .a and .la files present. As far as I
 am dummy in FreeBSD C/C++, I used something
 try-to-change-something-and-see-what-you-get method (it has pretty
 russian idiom,but I don't know its analog in English)
 
 Filename: jk\build.properties
 
 Some pathes set to correspond to reality (path to apache, etc)
 
 Filename:jk\native\apache-2.0\build-unix.sh
 
 Line #:  44
 Action:commented.
 Line #:  46
 Action:  uncommented and approved
 New line:
 INCLUDE=-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE

Don't use build-unix.sh but instead configure/make. The build.sh is no more
present in recent jtc cvs, deprecated in favor of autoconf/make 

 Reason:while compiling mod_jk.so compiler could not see
 connectors includes. I added first statement to make it visible
 --- patch history end ---
 
 
 
 
 




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




Re: mod_jk2.so compiled (after patching), but won't install

2002-07-25 Thread Dev Zero G Ltd

Thanks very much for the help.

See below

Henri Gomez wrote:
 Quoting Dev Zero G Ltd [EMAIL PROTECTED]:
 
First of all - many many thanks to everybody who has helped so far - we 
really appreciate it.. Just one last push required. :)

We finally got mod_jk2.so and libjkjni.so to compile (see patch history 
at the bottom of the mail), but can't install. We put them into 
$(APACHE2_HOME)/modules and $(CATALINA_HOME)/lib accordingly.

But after running $(APACHE2_HOME)/bin/apachectl configtest we get an 
error message:

--- error start ---
file://augada/usr/local/apache2/modules ../bin/apachectl configtest
Syntax error on line 231 of /usr/local/apache2/conf/httpd.conf:
Cannot load /usr/local/apache2/modules/mod_jk2.so into server:
/usr/local/apache2/modules/mod_jk2.so: Undefined symbol
apr_thread_mutex_trylock
--- error end ---

What could it be?
 
 Which version of Apache 2.0 did you have ?

We are running Apache 2.0.39 on FreeBSD 4.4

 
--- patch history start ---
Filename: jk\native2\include\jk_mutex.h

Line #:75
Old line  :
#ifdef HAS_APR
New line:
#if APR_HAS_THREADS
 
 +1
 
#ifdef HAS_APR
 
 
Line #:121
Old line  :
#ifdef APR_HAS_THREADS

New line:
#if APR_HAS_THREADS

Reason:This conditional define statement adjusts variable
definition (threadMutex). Type of this variable depends on define
directive conditions, but to have needed types there are some #ifdef
statements on lines 75-81. So, those definition statements are not
the same, and this situation causes build-time error, when compiler
includes one header file (with one type defined inside), but variable
tries to have another type (found by me in another .h file - not
included while build time due to #ifdef directives). Such changes
were done experimentally and may be not 100% correct. In original
compiler fails with message like syntax error on before
apr_thread_mutex_t in line 121

 
 apr.h have #define APR_AS_THREADS 1 so both should be the same.
 Didn't have any build error with that on Linux Redhat 7.2 + apache 2.0.39 ...
 

our version of apr.h has #define APR_HAS_THREADS 0

Maybe apache/connector has not been ported properly to FreeBSD?

 
Filename jk\native2\build.xml

Line #:  374
Action: commented

Reason   :Having this link option uncommented (original) I could
not acquire libjkjni.so, only .a and .la files present. As far as I
am dummy in FreeBSD C/C++, I used something
try-to-change-something-and-see-what-you-get method (it has pretty
russian idiom,but I don't know its analog in English)

Filename: jk\build.properties

Some pathes set to correspond to reality (path to apache, etc)

Filename:jk\native\apache-2.0\build-unix.sh

Line #:  44
Action:commented.
Line #:  46
Action:  uncommented and approved
New line:
INCLUDE=-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE
 
 
 Don't use build-unix.sh but instead configure/make. The build.sh is no more
 present in recent jtc cvs, deprecated in favor of autoconf/make 
 

will try this

 
Reason:while compiling mod_jk.so compiler could not see
connectors includes. I added first statement to make it visible
--- patch history end ---

Thanks again


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




cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_mutex.h

2002-07-25 Thread hgomez

hgomez  2002/07/25 03:02:21

  Modified:jk/native2/include jk_mutex.h
  Log:
  Correct preprocessor use of APR_HAS_THREADS, since APR
  make use of #define APR_HAS_THREADS 0 when no threads support
  (Reported by Dev Zero Ltd)
  
  Revision  ChangesPath
  1.4   +2 -2  jakarta-tomcat-connectors/jk/native2/include/jk_mutex.h
  
  Index: jk_mutex.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/include/jk_mutex.h,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jk_mutex.h6 Jun 2002 13:32:25 -   1.3
  +++ jk_mutex.h25 Jul 2002 10:02:21 -  1.4
  @@ -72,7 +72,7 @@
   struct jk_env;
   struct jk_mutex;
   
  -#ifdef HAS_APR
  +#if APR_HAS_THREADS
   #include apr_thread_mutex.h
   #elif defined( WIN32 )
   #include windows.h
  @@ -118,7 +118,7 @@
   /* Private data */
   void *privateData;
   
  -#ifdef APR_HAS_THREADS
  +#if APR_HAS_THREADS
   apr_thread_mutex_t *threadMutex;
   #elif defined( WIN32 )
   CRITICAL_SECTION threadMutex;
  
  
  

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




cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 Makefile.am

2002-07-25 Thread hgomez

hgomez  2002/07/25 03:31:30

  Modified:jk/native/apache-1.3 Makefile.am
  Log:
  Make sure that apxs flags will be passed to libtool when building
  mod_jk.c (if not mod_jk.c will not be compiled with -DEAPI for example)
  
  Revision  ChangesPath
  1.7   +1 -1  jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.am
  
  Index: Makefile.am
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/Makefile.am,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- Makefile.am   5 Nov 2001 23:04:06 -   1.6
  +++ Makefile.am   25 Jul 2002 10:31:30 -  1.7
  @@ -16,7 +16,7 @@
   JK_INCL=-DUSE_APACHE_MD5 -I ${JK}
   JAVA_INCL=-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/${OS}
   JAVA_LIB=-L ${JAVA_HOME}/jre/lib/${ARCH} -L ${JAVA_HOME}/lib/${ARCH}/native_threads
  -AM_CFLAGS=@apache_include@ -I../common
  +AM_CFLAGS=@apache_include@ @APXSCFLAGS@ @APXSCPPFLAGS@ -I../common
   
   include ../common/list.mk.in
   
  
  
  

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




Re: mod_jk2.so compiled (after patching), but won't install

2002-07-25 Thread Henri Gomez

Quoting Dev Zero G Ltd [EMAIL PROTECTED]:

  Which version of Apache 2.0 did you have ?
 
 We are running Apache 2.0.39 on FreeBSD 4.4

good

 --- patch history start ---
 Filename: jk\native2\include\jk_mutex.h
 
 Line #:75
 Old line  :
 #ifdef HAS_APR
 New line:
 #if APR_HAS_THREADS
  
  +1
  
 #ifdef HAS_APR
  
  
 Line #:121
 Old line  :
 #ifdef APR_HAS_THREADS
 
 New line:
 #if APR_HAS_THREADS
 
 Reason:This conditional define statement adjusts variable
 definition (threadMutex). Type of this variable depends on define
 directive conditions, but to have needed types there are some #ifdef
 statements on lines 75-81. So, those definition statements are not
 the same, and this situation causes build-time error, when compiler
 includes one header file (with one type defined inside), but variable
 tries to have another type (found by me in another .h file - not
 included while build time due to #ifdef directives). Such changes
 were done experimentally and may be not 100% correct. In original
 compiler fails with message like syntax error on before
 apr_thread_mutex_t in line 121
 
  
  apr.h have #define APR_AS_THREADS 1 so both should be the same.
  Didn't have any build error with that on Linux Redhat 7.2 + apache 2.0.39
 ...
  
 
 our version of apr.h has #define APR_HAS_THREADS 0

So you don't have THREADS and yes #ifdef APR_HAS_THREADS is invalid,
your patch is correct

 Maybe apache/connector has not been ported properly to FreeBSD?

Linux, solaris, windows and many stranges architectures (JF ;)
patches applied to jk_mutex.h

 Filename jk\native2\build.xml
 
 Line #:  374
 Action: commented
 
 Reason   :Having this link option uncommented (original) I could
 not acquire libjkjni.so, only .a and .la files present. As far as I
 am dummy in FreeBSD C/C++, I used something
 try-to-change-something-and-see-what-you-get method (it has pretty
 russian idiom,but I don't know its analog in English)
 
 Filename: jk\build.properties
 
 Some pathes set to correspond to reality (path to apache, etc)
 
 Filename:jk\native\apache-2.0\build-unix.sh
 
 Line #:  44
 Action:commented.
 Line #:  46
 Action:  uncommented and approved
 New line:
 INCLUDE=-I ../common -I$APACHE_HOME/include/apr-util $JAVA_INCLUDE
  
  
  Don't use build-unix.sh but instead configure/make. The build.sh is no
 more
  present in recent jtc cvs, deprecated in favor of autoconf/make 
  
 
 will try this
 
  
 Reason:while compiling mod_jk.so compiler could not see
 connectors includes. I added first statement to make it visible
 --- patch history end ---
 
 Thanks again
 
 
 




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




[logging] Redirecting System.out to JDK1.4 Logging for tomcat

2002-07-25 Thread Bob Herrmann


I don't know if anyone else will find this interesting, but I wrote a
class which redirects System.Out to JDK1.4 Logging.  It is Tomcat 
aware and unrolls the stack in a way useful for Tomcat.  This might be
useful if you are embedding Tomcat.

I changed catalina.sh to start my class, it then invokes Bootstrap.

Any comments?

Cheers,
-bob







? patch.txt
? catalina/src/share/org/apache/catalina/startup/Tomcat2Jdk14Log.java
Index: catalina/build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.124
diff -r1.124 build.xml
1073a1074
 include name=org/apache/catalina/startup/Tomcat2Jdk14Log.class /
Index: catalina/src/bin/catalina.sh
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/bin/catalina.sh,v
retrieving revision 1.31
diff -r1.31 catalina.sh
209c209
   org.apache.catalina.startup.Bootstrap $@ start \
---
   org.apache.catalina.startup.Tomcat2Jdk14Log $@ start \




package org.apache.catalina.startup;

import java.io.OutputStream;
import java.io.IOException;
import java.io.PrintStream;

import java.util.logging.Level;
import java.util.logging.Logger;

/* This class takes StandardOut and redirects it to the Jdk1.4 Logger.
 * It attempts to walk the stack in a way that is meaningful for Tomcat
 */

public class Tomcat2Jdk14Log extends OutputStream {

public static void main(String args[]) {
	PrintStream ps = ( new PrintStream( new Tomcat2Jdk14Log(SysOut, Level.INFO ) ) ); 
	System.setOut( ps );

	ps = (new PrintStream( new Tomcat2Jdk14Log(SysErr, Level.WARNING ) ) );
	// Humm... this causes an exception to start to be printed..
	//perhaps a re-entrant issue?
	//System.setErr(ps);

	// just passing through
	Bootstrap.main(args);
}

private StringBuffer sb = new StringBuffer();
private Level level;
private Logger jlog;

// some platforms use 1 char for newline, others use 2
private int preNewlineChar = -1;
private int newlineChar;

private Tomcat2Jdk14Log( String logName, Level level ){
	this.level = level;
	jlog = Logger.getLogger(logName);

String newline = System.getProperty( line.separator );
if ( newline.length() == 2 ) {
preNewlineChar = newline.charAt(0);
newlineChar = newline.charAt(1);
} else {
newlineChar = newline.charAt(0);
}
}


// should this be syncronized?
public void write(int x) throws java.io.IOException {
if ( x != newlineChar ) {
sb.append( (char)x );
	return;
}

	// deal with Windows/Unix newline stuff
	if ( preNewlineChar != -1
	  sb.length()  1 
	  sb.charAt( sb.length() -1 ) == preNewlineChar) {
	sb.deleteCharAt( sb.length() -1 );
	}

	// get stack trace.  This is quite slow.  If method/classnames
	// arent needed this should be turned off
	StackTraceElement locations[] = new Throwable().getStackTrace();

	String cname=unknown;
	String method=unknown;
	boolean foundLogger = false;
	String myClassName = this.getClass().getName();

	// Stratagy for finding an Interesting tomcat stackframe
	for (int i=3;i locations.length;i++ ) {
	StackTraceElement caller=locations[i];

	cname=caller.getClassName();
	if ( !foundLogger ){
		// PHASE I: find the tomcat logger (we assume different platforms might
		// have different levels of stack... so we whirl through until we see
		// something we recognize. )
		if ( !cname.equals( org.apache.tomcat.util.log.SystemLogHandler ))
		continue;
		foundLogger = true;
		continue;
	}

	method=caller.getMethodName();
	// PHASE II: get rid of wrappers on top of the wrapper
	if ( method.equals(log) || method.equals(internalLog) )
		continue;

	// add line # for fun.
	method += :+caller.getLineNumber();
	break;
	}

	jlog.logp( level, cname, method, sb.toString() );

	sb = new StringBuffer(200);
}


}



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


DO NOT REPLY [Bug 7602] - After RequestDispatcher.forward() the character encoding for parameters is set to ISO-8859-1

2002-07-25 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7602.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7602

After RequestDispatcher.forward() the character encoding for parameters is set to 
ISO-8859-1





--- Additional Comments From [EMAIL PROTECTED]  2002-07-25 11:02 ---
Why use a default of ISO-8859-1 or UTF-8 ? Why don't use the page encoding 
defined by, e.g. %@ page contentType=text/html; charset=Big5% on the page 
head ?

People always use same encoding across the whole application, even for 
internationisation they will choose whatever suitable encoding and fixed to use 
it across whole application.

As we, the Multi-byte character user, need to explicitly call 

request.setCharacterEncoding(BIG5);

before getting the passed in Chinese parameters for processing, or-else the 
parameters are decoded using ISO-8859-1 uselessly.

Also, I suggest to add / change the code of method to facilitate for re-doing 
the parameter parsing using another encoding for the rare case that different 
encodings are required to use across application.

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




DO NOT REPLY [Bug 5709] - HttpServletRequest.getHost returns web server address or null, not client address

2002-07-25 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5709.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5709

HttpServletRequest.getHost returns web server address or null, not client address





--- Additional Comments From [EMAIL PROTECTED]  2002-07-25 11:06 ---
Created an attachment (id=2485)
Patch, restores behavior of tomcat 3

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




DO NOT REPLY [Bug 5709] - HttpServletRequest.getHost returns web server address or null, not client address

2002-07-25 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5709.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5709

HttpServletRequest.getHost returns web server address or null, not client address





--- Additional Comments From [EMAIL PROTECTED]  2002-07-25 11:10 ---
tomcat 3 has code in HttpServletRequestFacade.getRemoteHost() that tests whether
the remoteHost has already been set or not. The patch simply puts this code into
tomcat4, but now it's in RequestFacade.getRemoteHost()

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




Re: [logging] Redirecting System.out to JDK1.4 Logging for tomcat

2002-07-25 Thread Remy Maucherat

Bob Herrmann wrote:
 I don't know if anyone else will find this interesting, but I wrote a
 class which redirects System.Out to JDK1.4 Logging.  It is Tomcat 
 aware and unrolls the stack in a way useful for Tomcat.  This might be
 useful if you are embedding Tomcat.
 
 I changed catalina.sh to start my class, it then invokes Bootstrap.
 
 Any comments?

AFAIK, Glenn used the Jasper sys.out redirector (and put it in 
j-t-c/util) to do that. It doesn't redirect everything, but I believe it 
redirects everything significant.

The advantages are:
- It then redirects to one of the Catalina loggers
- It doesn't depend on JDK 1.4

Remy


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




Re: [logging] Redirecting System.out to JDK1.4 Logging for tomcat

2002-07-25 Thread Bob Herrmann

On Thu, 2002-07-25 at 07:13, Remy Maucherat wrote:
 Bob Herrmann wrote:
  I don't know if anyone else will find this interesting, but I wrote a
  class which redirects System.Out to JDK1.4 Logging.  It is Tomcat 
  aware and unrolls the stack in a way useful for Tomcat.  This might be
  useful if you are embedding Tomcat.
  
  I changed catalina.sh to start my class, it then invokes Bootstrap.
  
  Any comments?
 
 AFAIK, Glenn used the Jasper sys.out redirector (and put it in 
 j-t-c/util) to do that. It doesn't redirect everything, but I believe it 
 redirects everything significant.
 
 The advantages are:
 - It then redirects to one of the Catalina loggers
 - It doesn't depend on JDK 1.4

True.  My approach is tuned for 2 things,
 - utilizing JDK 1.4 logging 
 - unrolling the Tomcat stack in a way to get to interesting bits of
stack

You are right that this isn't something everyone would want.  If you are
trying to get Tomcat to log though JDK 1.4, then my approach might be
useful.  

The stack unrolling is helpful, IMHO, because it helps to identify which
class and method called the logger.  

I would like to have used commons-logging to get to JDK1.4's backend. 
Alas commons-logging doesn't support arbitrary stack unrolling
methods... And Tomcat has a lot of log wrappers

$ cd jakarta-tomcat-4.0
$ grep -i 'log(' `find . -name *.java `|grep void|cut -f1
-d:|sort|uniq|wc -l
 65

To migrate to commons-logging, it looks like at least 65 classes need to
be adjusted.  I presume this will take awhile.  Using my approach is a
quick stop gap.   Perhaps Tomcat 5 will embrace the migration to
commons-logging.

Cheers,
-bob

Related Thread:
http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg28257.html



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



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




Re: bug #11043

2002-07-25 Thread peter lin


Can any body give me a tip on where to look within catalina to patch the
bug I submitted?  It's not critical, but it's also not trivial, since
I'm not the only one who wants to use ServletContextListener to start up
an application.  If anyone is willing to give me a tip as to where to
look, I want to fix it this weekend and submit a patch so that it can be
included in 4.1.x release.

I've verified it exists in 4.0.3, 4.0.4 and 4.1.8. A paraphrase of the
bug is when the root directory is set to something other than ROOT, it
creates two instance of the ServletContextListener listed in web.xml and
fires the event twice.


peter lin
 

peter lin wrote:
 
 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11043
 
 hey remmy,
 
 I was thinking of debugging the bug I reported earlier this week.  Can
 you give me any tips as to where to look, so that I can fix it and
 submit a patch for it this weekend?
 
 thanks
 
 peter lin
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]

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




cvs commit: jakarta-tomcat-5 build.properties.default build.xml build.properties.sample

2002-07-25 Thread remm

remm2002/07/25 05:01:05

  Modified:.build.xml
  Added:   .build.properties.default
  Removed: .build.properties.sample
  Log:
  - Fix a few basic problems with the scripts.
  
  Revision  ChangesPath
  1.2   +23 -9 jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- build.xml 19 Jul 2002 00:39:13 -  1.1
  +++ build.xml 25 Jul 2002 12:01:05 -  1.2
  @@ -8,6 +8,7 @@
 property file=download.properties/
 property file=build.properties/
 property file=${user.home}/build.properties/
  +  property file=build.properties.default/
   
 !-- Project Properties --
 property name=name  value=Apache Tomcat /
  @@ -20,6 +21,16 @@
 property name=jtc.final.namevalue=${jtc.project}-${version} /
 property name=jtc.final-src.namevalue=${jtc.project}-${version}-src /
   
  +  !-- Source dependencies --
  +  property name=api.home
  +   value=${basedir}/../jakarta-servletapi-5/
  +  property name=catalina.home
  +   value=${basedir}/../jakarta-tomcat-catalina/
  +  property name=jasper.home
  +   value=${basedir}/../jakarta-tomcat-jasper/jasper2/
  +  property name=jtc.home
  +   value=${basedir}/../jakarta-tomcat-connectors/
  +
 !-- Build Defaults --
 property name=catalina.build   value=${catalina.home}/build/
 property name=jasper.build value=${jasper.home}/build/
  @@ -32,19 +43,16 @@
 property name=webapps.dist value=${catalina.home}/webapps/dist/
   
   
  -  !-- Source dependencies --
  -  property name=catalina.home
  -   value=${basedir}/../jakarta-tomcat-catalina/
  -  property name=jasper.home
  -   value=${basedir}/../jakarta-tomcat-jasper/jasper2/
  -  property name=jtc.home
  -   value=${basedir}/../jakarta-tomcat-connectors/
  -
  -
 !-- === DETECT: Display configuration == --
 target name=detect
  description=Display configuration and conditional compilation flags
   
  +echo message=--- ${name} ${version} Build ---/
  +echo message=api.home=${api.home}/
  +echo message=catalina.home=${catalina.home}/
  +echo message=jasper.home=${jasper.home}/
  +echo message=jtc.home=${jtc.home}/
  +
   ant dir=${catalina.home} target=flags.display/
   ant dir=${basedir}/webapps/admin target=flags.display/
   
  @@ -64,6 +72,8 @@
 !-- == DEPLOY: Deploy Components === --
 target name=deploy depends=deploy-static
  description=Build and deploy all components
  +echoTarget: API - Dist .../echo
  +ant dir=${api.home} target=dist/
   echoTarget: Catalina - Deploy .../echo
   ant dir=${catalina.home} target=deploy/
   echoTarget: Jasper - Deploy .../echo
  @@ -77,6 +87,8 @@
 target name=clean
  description=Clean all components
   delete dir=${tomcat.build}/
  +echoTarget: API - Clean .../echo
  +ant dir=${api.home} target=clean/
   echoTarget: Catalina - Clean .../echo
   ant dir=${catalina.home} target=clean/
   echoTarget: Jasper - Clean .../echo
  @@ -90,6 +102,8 @@
 !-- === COMBO: Build All Components  --
 target name=all
  description=Clean, build, and deploy all components
  +echoTarget: API - Dist .../echo
  +ant dir=${api.home} target=dist/
   echoTarget: Catalina - All .../echo
   ant dir=${catalina.home} target=all/
   echoTarget: Jasper - All .../echo
  
  
  
  1.1  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  # -
  # build.properties.sample
  #
  # This is an example build.properties file, used to customize building Tomcat
  # for your local environment.  It defines the location of all external
  # modules that Tomcat depends on.  Copy this file to build.properties
  # in the top-level source directory, and customize it as needed.
  #
  # $Id: build.properties.default,v 1.1 2002/07/25 12:01:05 remm Exp $
  # -
  
  
  # - Compile Control Flags -
  compile.debug=on
  compile.deprecation=off
  compile.optimize=on
  
  
  # - Build Control Flags
  
  #Build all components
  #full.dist=on
  
  #Build lightweight JDK 1.4 distribution
  #light.dist=on
  
  #Hide configuration flags display
  #flags.hide=on
  
  #Version number
  version=5.0
  
  # - CVS setup
  #Proxy to download subproject
  #proxy.host=proxy.domain
  #proxy.port=8080
  #proxy.use=on
  
  #CVS root for the jakarta repositories.
  

cvs commit: jakarta-tomcat-catalina/etc mx4j.license

2002-07-25 Thread remm

remm2002/07/25 05:01:22

  Modified:.build.xml
   catalina build.xml
   catalina/src/share/org/apache/catalina/mbeans
MBeanUtils.java
  Added:   etc  mx4j.license
  Removed: catalina/src/share/org/apache/catalina/startup
CatalinaManager.java CatalinaManagerMBean.java
EmbeddedManager.java EmbeddedManagerMBean.java
  Log:
  - Fix a few basic problems with the scripts.
  
  Revision  ChangesPath
  1.2   +5 -11 jakarta-tomcat-catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/build.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- build.xml 18 Jul 2002 16:47:24 -  1.1
  +++ build.xml 25 Jul 2002 12:01:22 -  1.2
  @@ -5,21 +5,15 @@
   
 !-- See build.properties.sample in the top level directory for all --
 !-- property values you must customize for successful building!!!--
  -  property file=build.properties/
  -  property file=${user.home}/build.properties/
  +  !--property file=build.properties/
  +  property file=${user.home}/build.properties/--
   
 !-- Build Defaults --
  -  property name=catalina.build   value=${basedir}/catalina/build/
  -  property name=catalina.distvalue=${basedir}/dist/
  -  property name=jasper.build value=${jasper.home}/build/
  -  property name=servlet.home value=../jakarta-servletapi-4/dist/
  -  property name=tomcat.build value=${basedir}/build/
  -  property name=tomcat.dist  value=${basedir}/dist/
  -  property name=webapps.buildvalue=${basedir}/webapps/build/
  -  property name=webapps.dist value=${basedir}/webapps/dist/
  -
  +  !--property name=catalina.build   value=${basedir}/catalina/build/--
   
 !-- Source dependencies --
  +  property name=api.home
  +   value=${basedir}/../jakarta-servletapi-5/
 property name=jtc.home
  value=${basedir}/../jakarta-tomcat-connectors/
   
  
  
  
  1.2   +7 -7  jakarta-tomcat-catalina/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- build.xml 18 Jul 2002 16:47:30 -  1.1
  +++ build.xml 25 Jul 2002 12:01:22 -  1.2
  @@ -5,15 +5,14 @@
   
 !-- See build.properties.sample in the top level directory for all --
 !-- property values you must customize for successful building!!!--
  -  property file=build.properties/
  +  !--property file=build.properties/
 property file=../build.properties/
  -  property file=${user.home}/build.properties/
  +  property file=${user.home}/build.properties/--
   
 !-- Build Defaults --
  -  property name=build.compilervalue=classic/
  -  property name=catalina.buildvalue=${basedir}/build/
  -  property name=catalina.deploy   value=${basedir}/../build/
  -  property name=catalina.dist value=${basedir}/dist/
  +  property name=catalina.buildvalue=${catalina.home}/catalina/build/
  +  property name=catalina.deploy   value=${catalina.home}/build/
  +  property name=catalina.dist value=${catalina.home}/dist/
 property name=test.failonerror  value=true/
 property name=test.runner   value=junit.textui.TestRunner/
 property name=test.webapp   value=../webapps/build/examples/
  @@ -28,6 +27,7 @@
   
 !-- Dependent JARs and files --
 property name=ant.jar value=${ant.home}/lib/ant.jar/
  +  property name=servlet.jar value=${api.home}/dist/lib/servlet.jar/
 property name=tomcat-util.jar
  value=${tomcat-util.home}/build/lib/tomcat-util.jar/
 property name=tomcat-coyote.jar
  @@ -688,7 +688,7 @@
 /target
 target name=copy-jmx.jar if=copy.jmx.jar
   copy todir=${catalina.build}/server/lib file=${jmx.jar}/
  -copy todir=${catalina.build}/server/lib file=../lib/mx4j.license/
  +copy todir=${catalina.build}/server/lib file=../etc/mx4j.license/
 /target
 target name=copy-jndi.jar if=copy.jndi.jar
   copy todir=${catalina.build}/common/lib file=${jndi.jar}/
  
  
  
  1.2   +5 -53 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java
  
  Index: MBeanUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/MBeanUtils.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- MBeanUtils.java   18 Jul 2002 16:48:00 -  1.1
  +++ MBeanUtils.java   25 Jul 2002 12:01:22 -  1.2
  @@ -98,7 +98,6 @@
   import org.apache.catalina.User;
   import org.apache.catalina.UserDatabase;
   import 

DO NOT REPLY [Bug 11165] New: - Install task assumes the war file is readable

2002-07-25 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11165.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11165

Install task assumes the war file is readable

   Summary: Install task assumes the war file is readable
   Product: Tomcat 4
   Version: 4.1.7
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The scenario is as follows: 

1. Tomcat is started as root as some other kind of special user 
   (tomcat maybe) 
2. I do my development as my self. When I try to install a war file it  
   complains about: 
   2002-07-25 13:50:47 StandardContext[/nowise]: Error initializing
   resources: Doc base must point to a WAR file

The problem here is that the Tomcat server tries to read the war file 
itself. The Tomcat server falsly assumes that it has read access to the 
path it got. But in my case it doesn't. 

I don't know if this is possible, but a better solution would be to 
transfer the war file to the server as my user.

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




Re: JSR77 tomcat5 configuration

2002-07-25 Thread Remy Maucherat

[EMAIL PROTECTED] wrote:
 It seems JSR77 has been posted - I think everyone should read it.
 
 What's important is the set of naming conventions for the managed
 objects we expose - I strongly believe that we should use those
 names wherever we provide the equivalent functionality.
 
 For example ( on what is important for me ): 
 - 'node' attribute - instead of jvmRoute 
 - each tomcat instance in a distributed config must know 
 about all other
 - we should start exposing mbeans for JVM, WebModule and 
 servlets using the naming conventions.
 
 Of course, we should keep backward compat - but all old
 attribute names should be eventually deprecated.
 
 As I mentioned in the past, I'm not happy with XmlMapper/Digester
 style used for configuration and I'm not happy with either 
 server.xml format or with the way we save the config.
 
 At this moment I have a very strong belief ( and it's getting 
 stronger every day ) that we should adopt a configuration 
 close to the JMX model, where every configurable object
 is a named mbean. 
 
 That means no more Interceptor/Context/Server/Valve/Listener/etc.
 
 I also thing the configuration should be centered around a
 class similar with RuntimeConfigurable on ant, where all the
  user settings are stored ( including ${props} ). Any 
 configuration action that involves persistence should operate
 on the RuntimeConfigurable, which should deal with saving
 the config ( in a form as close as possible to the original 
 user configuration ).
 
 While I think XmlMapper/Digester are very powerfull tools, I think
 tomcat5 should follow a model that is closer to ant - i.e. 
 a set of patterns and a flatter configuration file. This has proven
 to be easy and is well-understood ( even if I wrote a lot of 
 code in xmlMapper, I do have troubles sometimes with it, and
 nobody can claim it's as easy as ant tasks).
 
 The question is: What do you think :-) ? 

Maybe it's time to plan for a change ...

This points out at the need for a new JSR 77 aware servlet container 
(which would likely reuse lots of code from the current Catalina). It's 
a good thing the core is now separate from the servlet container ;-)

Remy


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




Re: connection pooling

2002-07-25 Thread Craig R. McClanahan



On Thu, 25 Jul 2002, Pop Marius wrote:

 Date: Thu, 25 Jul 2002 11:00:05 +0200
 From: Pop Marius [EMAIL PROTECTED]
 Reply-To: Tomcat Developers List [EMAIL PROTECTED]
 To: tomcat [EMAIL PROTECTED]
 Subject: connection pooling


 Hi everybody !

 I'm using Tomcat 4 and my application works. To get a connection to database I have 
the following code:

   Context initCtx = new InitialContext();
   Context envCtx = (Context) initCtx.lookup(java:comp/env);

   DataSource ds = (DataSource)envCtx.lookup(jdbc/orgDB);
   return  ds.getConnection();

 and of course in the server.xml the necessary resource requirements !
 The application works fine, but How could I ensure myself that the
 connections provided are reused, that the pooling machine works, and I
 really have a pooling mechanism.

 How can I test it ! The documentation sais that ds.getConnection() gets
 a connection from the pool (which pool, how) but I'm not sure that !


It gets a connection from the pool that you configured with your resource
settings in server.xml.

 Any idea would be helpful !


The normal pattern for using a connection from a data source like this
(including your code from above):

  Context initCtx = new InitialContext();
  Context envCtx = (Context) initCtx.lookup(java:comp/env);
  DataSource ds = (DataSource) envCtx.lookup(jdbc/orgDB);
  Connection conn= ds.getConnextion();
  ... use the connection to do your database access ...
  conn.close();

The last call doesn't actually close the underlying database connection --
it just returns this instance to the connection pool.




 Pop Marius Lucian


Craig



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




can not build libjkjni.so

2002-07-25 Thread Dev Zero G Ltd

We are trying to get the mod_jk working on FreeBSD 4.4, tomcat 4.0.4, 
apache 2.0.39, jdk 1.4.0

We have so far successfully built mod_jk2.so and all the jars, but now 
are having problems with libjkjni.so

Can somebody help, PLEASE?!! WE ARE SO CLOSE...

 what we've done 

updated from cvs jakarta-tomcat-connectors (~15:00 GMT+00)

${conn_root}/utils: cp build.properties.sample build.properties
ant
${conn_root}/jk: cp build.properties.sample build.properties

in build.properties:
set catalina.home
set tomcat4.home to catalina.home
set apache.home

${conn_root}/coyote
cp build.properties.sample build.properties
ant

${conn_root}/
ant

${conn_root}/
cp jtc.jar ${catalina.home}/server/lib
cp ${jtc.home}/jk/build/lib/tomcat-jni.jar ${catalina.home}/bin
cd ${catalina.home}/server/lib
rm tomcat-ajp.jar tomcat-util.jar tomcat-coyote.jar tomcat-http11.jar
cd ${catalina.home}
vi conf/server.xml

add coyote connector:

Connector className=org.apache.coyote.tomcat4.CoyoteConnector
   port=8009 minProcessors=5 maxProcessors=75
   enableLookups=true redirectPort=8443
   acceptCount=10 debug=0 connectionTimeout=2
 protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/

${conn_root}/jk
chmod -r +x *.sh
./buildconf.sh
vi configure

//  find key --no-verify and remove it - in other way following 
configure run fails with message --no-verify requires host or 
something else

./configure --with-apxs=/usr/local/apache2/bin/apxs 
--with-java-home=${JAVA_HOME} --with-java-platform=2 -enable-jni
// in common, apache2 and jni folders need to edit Makefile because (my 
shell is csh)
// a)  libtool must be defined as libtool but not /bin/csh libtool
b) in some places in Makefile's statement $ I've replaced by
certain file name ( .la). I don't know why it doesn't work (we're new to 
unix C programming)

make
make install
${conn_root}/jk/apache2
cp mod_jk.so /usr/local/apache2/modules

 QUESTION -
Where can we find .so library to place into ${catalina.home}/lib folder? 
It must be libjkjni.so, or something like that, right?

We are mainly folowing instructions from 
http://www.pubbitch.org/jboss/mod_jk2.html
and from http://jakarta.apache.org/tomcat/tomcat-4.0-doc/config/ajp.html

Any more advice, pointers, ideas, suggestions - will be greatful for 
_anything_

Thanks in advance!!


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




RE: connection pooling

2002-07-25 Thread Andrew Conrad

Use a monitoring tool on your RDBMS.  For SQL Server I use Profiler.


- Andrew

 -Original Message-
 From: Pop Marius [mailto:[EMAIL PROTECTED]] 
 Sent: Thursday, July 25, 2002 5:00 AM
 To: tomcat
 Subject: connection pooling
 
 
 
 Hi everybody !
 
 I'm using Tomcat 4 and my application works. To get a 
 connection to database I have the following code:
 
   Context initCtx = new InitialContext();
   Context envCtx = (Context) initCtx.lookup(java:comp/env);
 
   DataSource ds = (DataSource)envCtx.lookup(jdbc/orgDB);
   return  ds.getConnection();
 
 and of course in the server.xml the necessary resource 
 requirements ! The application works fine, but How could I 
 ensure myself that the connections provided are reused, that 
 the pooling machine works, and I really have a pooling mechanism.
 
 How can I test it ! The documentation sais that 
 ds.getConnection() gets a connection from the pool (which 
 pool, how) but I'm not sure that !
 
 Any idea would be helpful !
 
 
 
 
 Pop Marius Lucian
 

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




DO NOT REPLY [Bug 11177] New: - Tomcat requires JRE 1.2 on Solaris 2.7

2002-07-25 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11177.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11177

Tomcat requires JRE 1.2 on Solaris 2.7

   Summary: Tomcat requires JRE 1.2 on Solaris 2.7
   Product: Tomcat 3
   Version: 3.1 Final
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Blocker
  Priority: Other
 Component: Config
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


On JRE Solaris_JDK_1.1.7_08a Tomcat dies while starting with a 
java.lang.ClassNotFoundException: org.apache.tomcat.startup.EmbededTomcat 

If I use Solaris_JDK_1.2.2_11 it starts fine.

System Configuration:  Sun Microsystems  sun4u Sun Enterprise 450 (4 X 
UltraSPARC-II 400MHz)
Memory size: 2048 Megabytes

Solaris
Release: 5.7
Kernel architecture: sun4u
Application architecture: sparc
Hardware provider: Sun_Microsystems
Domain: 
Kernel version: SunOS 5.7 Generic 106541-15 January 2001


Complete error msg:
Using classpath: /home/b0fds_ws/atlas/lib/tomcat.jar
Using JAVA_HOME: /usr/java1.1
Using TOMCAT_HOME: /home/b0fds_ws/atlas

Jdk11Compat: Installing jar protocol handler 
Guessed home=/home/b0fds_ws/atlas/lib
Exception: java.lang.ClassNotFoundException: 
org.apache.tomcat.startup.EmbededTomcat
java.lang.ClassNotFoundException: org.apache.tomcat.startup.EmbededTomcat
at java.lang.Throwable.init(Compiled Code)
at java.lang.Exception.init(Compiled Code)
at java.lang.ClassNotFoundException.init(Compiled Code)
at org.apache.tomcat.util.compat.SimpleClassLoader.loadClass(Compiled 
Code)
at java.lang.ClassLoader.loadClass(Compiled Code)
at org.apache.tomcat.startup.Main.execute(Compiled Code)
at org.apache.tomcat.startup.Main.main(Compiled Code)

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




cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler JspDocumentParser.java Parser.java TagLibraryInfoImpl.java

2002-07-25 Thread luehe

luehe   2002/07/25 12:02:16

  Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java Parser.java
TagLibraryInfoImpl.java
  Log:
  Integrated TagFileProcessor into TagLibraryInfo constructor
  
  Revision  ChangesPath
  1.9   +5 -5  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java
  
  Index: JspDocumentParser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentParser.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- JspDocumentParser.java24 Jul 2002 19:58:57 -  1.8
  +++ JspDocumentParser.java25 Jul 2002 19:02:16 -  1.9
  @@ -483,8 +483,8 @@
   // get the location
   String[] location = ctxt.getTldLocation(uri);
   
  -tl = new TagLibraryInfoImpl(ctxt, prefix, uri, location,
  - err);
  +tl = new TagLibraryInfoImpl(ctxt, parserController, prefix,
  + uri, location, err);
   }
taglibs.put(prefix, tl);
}
  
  
  
  1.12  +6 -5  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- Parser.java   22 Jul 2002 20:35:27 -  1.11
  +++ Parser.java   25 Jul 2002 19:02:16 -  1.12
  @@ -371,8 +371,9 @@
if (uri != null  prefix != null) {
// Errors to be checked in Validator
String[] location = ctxt.getTldLocation(uri);
  - TagLibraryInfo tl = new TagLibraryInfoImpl(ctxt, prefix, uri,
  -location, err);
  + TagLibraryInfo tl = new TagLibraryInfoImpl(ctxt, parserController,
  +prefix, uri, location,
  +err);
taglibs.put(prefix, tl);
}
   
  
  
  
  1.5   +51 -13
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
  
  Index: TagLibraryInfoImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- TagLibraryInfoImpl.java   22 Jul 2002 23:02:55 -  1.4
  +++ TagLibraryInfoImpl.java   25 Jul 2002 19:02:16 -  1.5
  @@ -81,13 +81,14 @@
* @author Kin-man Chung
*/
   public class TagLibraryInfoImpl extends TagLibraryInfo {
  -static private final String TAGLIB_TLD = META-INF/taglib.tld;
  -static private final String WEB_XML = /WEB-INF/web.xml;
   
  -Hashtable jarEntries;
  +private static final String TAGLIB_TLD = META-INF/taglib.tld;
  +private static final String WEB_XML = /WEB-INF/web.xml;
   
  -JspCompilationContext ctxt;
  -ErrorDispatcher err;
  +private Hashtable jarEntries;
  +private JspCompilationContext ctxt;
  +private ErrorDispatcher err;
  +private ParserController parserController;
   
   private final void print(String name, String value, PrintWriter w) {
   if (value != null) {
  @@ -141,14 +142,19 @@
  
   }
   
  -public TagLibraryInfoImpl(JspCompilationContext ctxt, String prefix, 
  -   String uriIn, String[] location,
  -   ErrorDispatcher err) 
  -throws JasperException {
  -
  +/**
  + * Constructor.
  + */
  +public TagLibraryInfoImpl(JspCompilationContext ctxt,
  +   ParserController pc,
  +   String prefix, 
  +   String uriIn,
  +   String[] location,
  +   ErrorDispatcher err) throws JasperException {
   super(prefix, uriIn);
   
this.ctxt = ctxt;
  + this.parserController = pc;
this.err = err;
   ZipInputStream zin;
   InputStream in = null;
  @@ -275,6 +281,8 @@
   this.tagLibraryValidator = createValidator(element);
   else if (tag.equals(tname))
   tagVector.addElement(createTagInfo(element));
  +else if (tag-file.equals(tname))
  +tagVector.addElement(createTagInfoFromTagFile(element));
   else if (function.equals(tname))  

DO NOT REPLY [Bug 11177] - Tomcat requires JRE 1.2 on Solaris 2.7

2002-07-25 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11177.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11177

Tomcat requires JRE 1.2 on Solaris 2.7

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
Version|3.1 Final   |3.3.1 Final



--- Additional Comments From [EMAIL PROTECTED]  2002-07-25 19:04 ---
This is fixed in the nightly.

In the mean time, you can work around it by running Tomcat as:

TOMCAT_OPTS=-Dtomcat.install=/home/b0fds_ws/atlas startup.sh

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




cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler TagFileProcessor.java

2002-07-25 Thread luehe

luehe   2002/07/25 12:08:46

  Modified:jasper2/src/share/org/apache/jasper/compiler
TagFileProcessor.java
  Log:
  Removed java.lang.Exception from throws clause of TagFileProcessor.parseTagFile()
  
  Revision  ChangesPath
  1.2   +3 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java
  
  Index: TagFileProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- TagFileProcessor.java 24 Jul 2002 22:38:43 -  1.1
  +++ TagFileProcessor.java 25 Jul 2002 19:08:46 -  1.2
  @@ -278,7 +278,7 @@
   }
   
   public static TagInfo parseTagFile(ParserController pc, String tagfile)
  -throws FileNotFoundException, JasperException, Exception {
  +throws FileNotFoundException, JasperException {
   
   Node.Nodes page = pc.parse(tagfile);
   TagFileVisitor tagFileVisitor = new TagFileVisitor(pc.getCompiler());
  
  
  

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




Re: javax.servlet.jsp.el.ExpressionEvaluator ????

2002-07-25 Thread Kin-Man Chung

The head branch of jasper2 is meant to be part of Jakarta-tomcat-5, which
in the middle of being set up.  It might be a while before tomcat 5
can be built.

You should check out the tomcat_4_branch of jasper2 for your build.

If you really want to build Jakarta-tomcat-4 with the head branch
of jasper2 with, just to try out JSP2.0 features, then you should
follow the instructions in BUILDING.txt in jasper2.


 Date: Thu, 25 Jul 2002 14:45:07 -0500
 From: Brian Millett [EMAIL PROTECTED]
 Subject: javax.servlet.jsp.el.ExpressionEvaluator 
 To: Tomcat Developers List [EMAIL PROTECTED]
 Content-transfer-encoding: 7bit
 
 I am trying to compile the latest 7/25 cvs co of Jakarta-tomcat-4 and I
 have ran into a problems with jasper2.
 
[javac]
 
/home/bpm/compile_area/cvs_jakarta/jakarta-tomcat-jasper/jasper2/src/share/org/a
pache/jasper/compiler/JspUtil.java:90: package javax.servlet.jsp.el does not 
exist
 [javac] import javax.servlet.jsp.el.ExpressionEvaluator;
 [javac] ^
 
 
 I have no idea where this file might be located.  It is not part of the
 commons, commons-sandbox, taglibs, struts, velocity, etc.
 
 What is it and why was code committed to CVS that references files that
 do not exist?
 
 Thanks.
 
 -- 
 Brian Millett
 Enterprise Consulting Group Shifts in paradigms
 (314) 205-9030 often cause nose bleeds.
 [EMAIL PROTECTED]   Greg Glenn
 
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 


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




DO NOT REPLY [Bug 11181] New: - HelloWorldExample doesnt compile

2002-07-25 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11181.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11181

HelloWorldExample doesnt compile

   Summary: HelloWorldExample doesnt compile
   Product: Tomcat 4
   Version: 4.1.0
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Examples
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


public class HelloWorldExample extends HttpServlet 
{
public void doGet(HttpServletRequest request,
  HttpServletResponse response)
throws IOException, ServletException
{
ResourceBundle rb =
ResourceBundle.getBundle(LocalStrings,Locale.getDefault
()); //request.getLocale());
response.setContentType(text/html);
//HttpServletRequest has no getLocale() method...

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




DO NOT REPLY [Bug 11183] New: - ArrayIndexOutOfBoundsException in parseParameters()

2002-07-25 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11183.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11183

ArrayIndexOutOfBoundsException in parseParameters()

   Summary: ArrayIndexOutOfBoundsException in parseParameters()
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When submitting a JSP request in which the value of the LAST parameter on the 
URL ends in a percent sign, Catalina throws a 
java.lang.ArrayIndexOutOfBoundsException in the parseParameters() method of 
org.apache.catalina.util.RequestUtil. 

Looking at the following line from the switch statement, it would seem that the 
code is assuming there are two more characters after the percent sign:

case '%':
data[ox++] = (byte)((convertHexDigit(data[ix++])  4)
+ convertHexDigit(data[ix++]));

If the query string were properly encoded (% - %25), this wouldn't be an issue.  
But if it's not, shouldn't the container handle it better than this exception?

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




tomcat in 64-bit mode

2002-07-25 Thread Ed Borkmann


Tomcat4.0 ran fine until we started running it with the 64 bit option
-d64 

We are using Solaris 2.8  on a Sun-Fire-280R.

Now Tomcat will crash every few hours.  Does anybody know of a reason why this 
would happen?  The logs really don't give any clues.
Thanks.

Ed




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




cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties

2002-07-25 Thread luehe

luehe   2002/07/25 15:28:46

  Modified:jasper2/src/share/org/apache/jasper
JspCompilationContext.java
   jasper2/src/share/org/apache/jasper/compiler Parser.java
TagFileProcessor.java TagLibraryInfoImpl.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties
  Added:   jasper2/src/share/org/apache/jasper/compiler
ImplicitTagLibraryInfo.java
  Log:
  Added support for implicit tag libraries containing the tag handlers of tag files 
stored in a directory without a TLD file
  
  Revision  ChangesPath
  1.10  +12 -11
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java
  
  Index: JspCompilationContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- JspCompilationContext.java24 Jul 2002 09:09:47 -  1.9
  +++ JspCompilationContext.java25 Jul 2002 22:28:45 -  1.10
  @@ -61,19 +61,16 @@
   
   package org.apache.jasper;
   
  +import java.io.*;
  +import java.net.*;
  +import java.util.Set;
  +import javax.servlet.ServletContext;
  +import org.apache.jasper.compiler.JspRuntimeContext;
   import org.apache.jasper.compiler.JspReader;
   import org.apache.jasper.compiler.ServletWriter;
  -import java.io.IOException;
  -import java.io.File;
  -import java.io.FileNotFoundException;
  -import java.net.URL;
  -import java.net.URLClassLoader;
  -import java.net.MalformedURLException;
   import org.apache.jasper.compiler.Compiler;
   import org.apache.jasper.servlet.JspServletWrapper;
   import org.apache.jasper.servlet.JasperLoader;
  -import javax.servlet.ServletContext;
  -import org.apache.jasper.compiler.JspRuntimeContext;
   
   /**
* A place holder for various things that are used through out the JSP
  @@ -233,6 +230,10 @@
   
   public URL getResource(String res) throws MalformedURLException {
   return context.getResource(canonicalURI(res));
  +}
  +
  +public Set getResourcePaths(String path) {
  +return context.getResourcePaths(canonicalURI(path));
   }
   
   /** 
  
  
  
  1.13  +25 -10
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
  
  Index: Parser.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Parser.java   25 Jul 2002 19:02:16 -  1.12
  +++ Parser.java   25 Jul 2002 22:28:45 -  1.13
  @@ -368,13 +368,28 @@
Attributes attrs = parseAttributes();
String uri = attrs.getValue(uri);
String prefix = attrs.getValue(prefix);
  - if (uri != null  prefix != null) {
  - // Errors to be checked in Validator
  - String[] location = ctxt.getTldLocation(uri);
  - TagLibraryInfo tl = new TagLibraryInfoImpl(ctxt, parserController,
  -prefix, uri, location,
  -err);
  - taglibs.put(prefix, tl);
  + if (prefix != null) {
  + TagLibraryInfo tagLibInfo = null;
  + if (uri != null) {
  + // Errors to be checked in Validator
  + String[] location = ctxt.getTldLocation(uri);
  + tagLibInfo = new TagLibraryInfoImpl(ctxt, parserController,
  + prefix, uri, location,
  + err);
  + } else {
  + String tagdir = attrs.getValue(tagdir);
  + if (tagdir != null) {
  + tagLibInfo = ImplicitTagLibraryInfo.getTabLibraryInfo(
  +ctxt,
  + parserController,
  + prefix, 
  + tagdir,
  + err);
  + }
  + }
  + if (tagLibInfo != null) {
  + taglibs.put(prefix, tagLibInfo);
  + }
}
   
new Node.TaglibDirective(attrs, start, parent);
  
  
  
  1.3   +12 -5 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java
  
  Index: TagFileProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 

[Logging] more issues with stack reading

2002-07-25 Thread costinm

Ok, back to the subject of extracting the method name from the 
stack trace.

The problem is actually a bit more complicated and I think we're
doing the wrong thing at the moment, and all proposed solutions
are quite bad.

What we are trying to solve: display the method and classname that
makes the log call. 

Log4j and jdk1.4 logging provide a config format to enable displaying this 
- logkit doesn't seem to, so it's not a problem there ( since it couldn't
be displayed in the first place - if it does, same issue as in jdk1.4 
apply )

Log4j has the best support for this - if you enable the display for
method and classname it'll generate a Throwable and walk the stack to
find the caller. It also have support for passing a Object which is 
indicates the 'wrapper' - so if log4j is wrapped, we display the real
caller, not the wrapper.

JDK1.4 does almost the same thing - if called directly and if the
method display is configured, it'll walk the stack. It is also possible
to pass the class/method as String params ( as oposed to log4j 
where you pass the Object wrapper ).

The problem in JDK1.4 is that there is no good way to deal with the 
case when their logger is wrapped ( by commons-logging or by a tomcat
logger or any other method ). So we have to 'emulate' this and extract
the information from stack in the wrapper. We could ask the user
to pass this explicitely - but that's stupid, since the info is redundant
( we already _have_ it, in the stack ) and make the logger hard to use.

We solve the problem for commons-logging, but what if commons-logging
itself is wrapped ? Well, same solution as in log4j can be used here, 
i.e. pass ( somehow ) information about the wrapper and skip it from
the stack walk.

However there are 2 huge problems:

1. Performance. Generating an exception and parsing the stack trace
is _extremely_ expensive. If you need the information - you'll have 
to pay for it, but the problem is that you pay for it even if you
_don't_ use it. 

2. Configuration. We either add explicit API to pass this info in each
Log method or we allow to configure it per LogFactory or once per Log
( i.e. a single method - generic or not - to configure it ). 

What that means is that in order to avoid the performance when it is
not needed, we also need to request the logger to enable stack checking
in 1.4 ( again, log4j works without problems anyway ). 

The solution of casting or constructing Jdk14Logger explicitely is 
wrong - we loose the pluggability and discovery. 

IMHO the only way to deal with that is to allow some form of 
configuration ( hints ) that is generic to all loggers. 

I'll ask for a vote - after I hear your comments. The hints 
will be passed by whoever creates the Logger, and so far the 
best solution seems to be setAttribute in Logger.

There is one alternative - that doesn't require API changes, and it
may be much better: 

Require ( or recomend ? ) that each Log and LogFactory to support a form 
of JMX. 

That would mean that we'll be able to find if a Log or LogFactory support
configuration, pass configuration using a standard API, use the 
existing JMX support in log4j, get the loggers to integrate nicely
in tomcat and apps that use JMX. 

A static MBean would be the best choice for this case - as it 
doesn't introduce _any_ dependency on JMX, it's just a programming
style where each LogFactory/Log impl would also implement an interface
with getters/setters. For log4j we could expose the 'real' MBean 
of the Category, since it already exist and get access to all
the config capabilities. 

Yet another alternative is to just use getter/setters and the 
introspection-based dynamic MBean in tomcat-util ( which can be used
to transparently enable any bean as a JMX component - like 3.3 
interceptors or jk handlers ).

I hope at least someone has read all this long message and will respond 
:-)

Costin 








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




DO NOT REPLY [Bug 11187] - Question on request.getHeaderNames()

2002-07-25 Thread bugzilla

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11187.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11187

Question on request.getHeaderNames()

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

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