Re: Avoiding same server to server HTTP calls to generate HTML pages via JSPs
Adam Gordon wrote: Right now we basically have a URL dispatcher that when a specific request comes in, we make another request to retrieve the contents of a URI (a JSP page to generate HTML) via a server-to-server HTTP call and then essentially slap that into a MimeBodyPart for sending text/html email messages. Simply do not use JSP. Use Velocity for example. -- Mikolaj Rydzewski [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Problem in Tomcat 5.5 Server
Hi Guys, We have setup 3 tomcat server for 1 domain name using DNS Round-robin. Our problem is sometimes the tomcat servers are not responding, we are monitoring the bandwidth and cpu usage and its not high during those slow response times. Hope you guys have any ideas on this... Tia! Richard - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Avoiding same server to server HTTP calls to generate HTML pages via JSPs
If you cannot replace your jsps with velocity (or freemarker) you could still use RequestDispatcher. Just provide your own implementation of ServletResponse that mostly will be just wrapper based on servlet response instance ( Tomcat implementation), but will buffer response output as string rather than write it to output stream. Gennady. -Original Message- From: Mikolaj Rydzewski [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 10:15 To: Tomcat Users List Subject: Re: Avoiding same server to server HTTP calls to generate HTML pages via JSPs Adam Gordon wrote: Right now we basically have a URL dispatcher that when a specific request comes in, we make another request to retrieve the contents of a URI (a JSP page to generate HTML) via a server-to-server HTTP call and then essentially slap that into a MimeBodyPart for sending text/html email messages. Simply do not use JSP. Use Velocity for example. -- Mikolaj Rydzewski [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fifo queue
Marco Caldirola wrote: I need to create on my tomcat 6.0 server a fifo queue of my http requests. I want to process a single request at a time. Do you have an idea? Change your idea. Do you really need such a nasty hack? Use command pattern. Process requests as usual, create Command objects and insert them into any queue you want. -- Mikolaj Rydzewski [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
tc-native-1.1.12 fails to configure on Redhat EL4 x86_64 (... command not found)
Hi, I get many error msgs from this new thing; 1.1.10 was fine. I cut the rest of the lines with 'command not found'. # ./configure --with-apr=/usr/local/apache2/ --with-ssl=/usr/include/openssl/ checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking for working mkdir -p... yes Tomcat Native Version: 1.1.12 checking for chosen layout... tcnative checking for APR... yes setting CC to gcc setting CPP to gcc -E checking for a BSD-compatible install... /usr/bin/install -c checking for JDK location (please wait)... /opt/java from environment checking Java platform... checking Java platform... checking for sablevm... NONE adding -I/opt/java/include to TCNATIVE_PRIV_INCLUDES checking os_type directory... linux adding -I/opt/java/include/linux to TCNATIVE_PRIV_INCLUDES checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for OpenSSL library... using openssl from /usr/include/openssl//lib and /usr/include/openssl//include checking OpenSSL library version... not compatible checking for OpenSSL DSA support... no adding -I/usr/include/openssl//include to TCNATIVE_PRIV_INCLUDES setting TCNATIVE_LDFLAGS to -L/usr/include/openssl//lib --Wl,-rpath,/usr/include/openssl//lib -lssl -lcrypto adding -DHAVE_OPENSSL to CFLAGS setting TCNATIVE_LIBS to setting TCNATIVE_LIBS to /usr/local/apache2/lib/libapr-1.la -luuid -lrt -lcrypt -lpthread -ldl ./configure: line 4315: APR_BUILD_DIR: command not found ./configure: line 4316: APR_INCLUDES: command not found ./configure: line 4317: APR_LIBS: command not found ./configure: line 4318: APR_LIB_TARGET: command not found ./configure: line 4319: APR_SO_EXT: command not found ./configure: line 4320: BASH: command not found ./configure: line 4321: BASH_ARGC: command not found ./configure: line 4322: BASH_ARGV: command not found ./configure: line 4323: BASH_LINENO: command not found ./configure: line 4324: BASH_SOURCE: command not found ... Thx Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat6
Yes, Why it shouldn't be ? Shiby Maria John wrote: Hi, can Tomcat 6 version be used in production? Regards, Shiby - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- signature full-name Vinu Varghese /full-name company-email [EMAIL PROTECTED] /company-email company-website www.x-minds.org /company-website big-words Success always occurs in private, and failure in full view. /big-words company-name-big \/ ._ _ o .__| _ /\ ~~ | | | | | | (_| _\ /company-name-big /signature
Re: fifo queue
Add something like the following to your servlet
synchronized ( someObject )
{
do work
}
But you'll need to be careful, as requests will block and clients
might time out if you are performing lengthy operations inside the
synchronized block.
On Jan 4, 2008 11:12 AM, Marco Caldirola [EMAIL PROTECTED] wrote:
Hi,
I need to create on my tomcat 6.0 server a fifo queue of my http requests.
I want to process a single request at a time.
Do you have an idea?
Thanks in advance.
Marco
___
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail:
http://it.docs.yahoo.com/nowyoucan.html
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
fifo queue
Hi, I need to create on my tomcat 6.0 server a fifo queue of my http requests. I want to process a single request at a time. Do you have an idea? Thanks in advance. Marco ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
Tomcat6
Hi, can Tomcat 6 version be used in production? Regards, Shiby - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fifo queue
Reduce the max http request threads to 1. However, 1) the admin request will be queued like user ones 2) it's not a fifo, the socket that are served, one at a time, by http thread are, i think, in the same order as the thread get notified by jvm En l'instant précis du 04/01/08 12:12, Marco Caldirola s'exprimait en ces termes: Hi, I need to create on my tomcat 6.0 server a fifo queue of my http requests. I want to process a single request at a time. Do you have an idea? Thanks in advance. Marco ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html -- http://www.devlog.be (a belgian developer's logs) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tc-native-1.1.12 fails to configure on Redhat EL4 x86_64 (... command not found)
Hi Rainer,
I can reproduce on Solaris.
The first problem should be fixed by:
--- configure.orig 2007-12-21 15:06:53.0 +0100
+++ configure 2008-01-04 14:16:13.0 +0100
@@ -2490,7 +2490,7 @@
{ (exit 1); exit 1; }; }
fi
sapr_version=`echo $sapr_pversion|sed -e 's/\(a-z*\)$/.\1/'`
- IFS=.; set $sapr_version; IFS=' '
+ tc_save_IFS=$IFS; IFS=.; set $sapr_version; IFS=$tc_save_IFS
if test ${1} -lt 1; then
{ { echo $as_me:$LINENO: error: You need APR version 1.2.1 or
newer installed. 5
echo $as_me: error: You need APR version 1.2.1 or newer installed. 2;}
If you regenerate configure via buildconf, you need to also fix
build/tcnative.m4 analogously:
--- build/tcnative.m4.orig 2008-01-04 14:18:10.0 +0100
+++ build/tcnative.m4 2008-01-04 14:16:05.0 +0100
@@ -31,7 +31,7 @@
AC_MSG_ERROR(APR config could not be located. Please use the
--with-apr option.)
fi
sapr_version=`echo $sapr_pversion|sed -e 's/\([a-z]*\)$/.\1/'`
- IFS=.; set $sapr_version; IFS=' '
+ tc_save_IFS=$IFS; IFS=.; set $sapr_version; IFS=$tc_save_IFS
if test ${1} -lt 1; then
AC_MSG_ERROR(You need APR version 1.2.1 or newer installed.)
else
Does that also fix your second problem?
Regards,
Rainer (sic!)
Rainer Traut schrieb:
Hi,
I get many error msgs from this new thing; 1.1.10 was fine. I cut the
rest of the lines with 'command not found'.
# ./configure --with-apr=/usr/local/apache2/
--with-ssl=/usr/include/openssl/
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking for working mkdir -p... yes
Tomcat Native Version: 1.1.12
checking for chosen layout... tcnative
checking for APR... yes
setting CC to gcc
setting CPP to gcc -E
checking for a BSD-compatible install... /usr/bin/install -c
checking for JDK location (please wait)... /opt/java from environment
checking Java platform... checking Java platform...
checking for sablevm... NONE
adding -I/opt/java/include to TCNATIVE_PRIV_INCLUDES
checking os_type directory... linux
adding -I/opt/java/include/linux to TCNATIVE_PRIV_INCLUDES
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for OpenSSL library... using openssl from
/usr/include/openssl//lib and /usr/include/openssl//include
checking OpenSSL library version... not compatible
checking for OpenSSL DSA support... no
adding -I/usr/include/openssl//include to TCNATIVE_PRIV_INCLUDES
setting TCNATIVE_LDFLAGS to -L/usr/include/openssl//lib
--Wl,-rpath,/usr/include/openssl//lib -lssl -lcrypto
adding -DHAVE_OPENSSL to CFLAGS
setting TCNATIVE_LIBS to
setting TCNATIVE_LIBS to /usr/local/apache2/lib/libapr-1.la -luuid
-lrt -lcrypt -lpthread -ldl
./configure: line 4315: APR_BUILD_DIR: command not found
./configure: line 4316: APR_INCLUDES: command not found
./configure: line 4317: APR_LIBS: command not found
./configure: line 4318: APR_LIB_TARGET: command not found
./configure: line 4319: APR_SO_EXT: command not found
./configure: line 4320: BASH: command not found
./configure: line 4321: BASH_ARGC: command not found
./configure: line 4322: BASH_ARGV: command not found
./configure: line 4323: BASH_LINENO: command not found
./configure: line 4324: BASH_SOURCE: command not found
...
Thx
Rainer
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: tc-native-1.1.12 fails to configure on Redhat EL4 x86_64 (... command not found)
Rainer Traut schrieb:
I get many error msgs from this new thing; 1.1.10 was fine. I cut the
rest of the lines with 'command not found'.
# ./configure --with-apr=/usr/local/apache2/
--with-ssl=/usr/include/openssl/
...
checking for OpenSSL library... using openssl from
/usr/include/openssl//lib and /usr/include/openssl//include
checking OpenSSL library version... not compatible
...
./configure: line 4316: APR_INCLUDES: command not found
./configure: line 4317: APR_LIBS: command not found
./configure: line 4318: APR_LIB_TARGET: command not found
...
And even more in config.log regarding the openssl library problem.
configure:3961: checking OpenSSL library version
configure:3995: gcc -o conftest -g -O2 -I/usr/include/openssl//include
conftest.c -L/usr/include/openssl//lib
--Wl,-rpath,/usr/include/openssl//lib -lssl -lcrypto 5
cc1: error: unrecognized command line option
-fWl,-rpath,/usr/include/openssl//lib
configure:3998: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| #include stdio.h
| #include openssl/opensslv.h
| int main() {
| if ((OPENSSL_VERSION_NUMBER = 0x0090701fL
| OPENSSL_VERSION_NUMBER 0x00908000L) ||
| OPENSSL_VERSION_NUMBER = 0x0090802fL)
| return (0);
| printf(\n\nFound OPENSSL_VERSION_NUMBER %#010x\n,
| OPENSSL_VERSION_NUMBER);
| printf(Require OPENSSL_VERSION_NUMBER 0x0090701f or greater
(0.9.7a)\n
|Require OPENSSL_VERSION_NUMBER 0x0090802f or greater
(0.9.8a)\n\n);
| return (1);
| }
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: session id cookies
Bill Barker wrote: Paul Singleton [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] If I set Context cookies=false ... will Tomcat ignore any JSESSIONID cookie which accompanies a request? Should it? With any of the released versions, it won't ignore the cookie if the browser sends one. There is a patch in the SVN that causes at least TC 6 to ignore the cookie, but it seems to be buggy. More info at http://issues.apache.org/bugzilla/show_bug.cgi?id=43839. As to should, IMHO the cookies=false should be more of a hint (like in the released versions of Tomcat), but I'm in the minority here. Thanks for the info. We were experimenting with a wholly URL-encoding version of an app (this appeals for various reasons) but on switching between them, found that a left- -over session cookie broke the no cookies version. Given the long-established, disputed behaviour of the cookies attribute, we'd be happy with an additional cookiesIgnore attribute (and no change to cookies) Paul S. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tc-native-1.1.12 fails to configure on Redhat EL4 x86_64 (... command not found)
Yes, this helps, everything fine now. Thank you. Rainer Rainer Jung schrieb: Replace --Wl, by -Wl, in configure and build/tcnative.m4. --- configure.orig 2007-12-21 15:06:53.0 +0100 +++ configure 2008-01-04 14:41:51.0 +0100 @@ -3936,7 +3936,7 @@ TCN_OPENSSL_LIBS=-L$use_openssl/lib -Wl,+b: -lssl -lcrypto ;; *linux*) -TCN_OPENSSL_LIBS=-L$use_openssl/lib --Wl,-rpath,$use_openssl/lib -lssl -lcrypto +TCN_OPENSSL_LIBS=-L$use_openssl/lib -Wl,-rpath,$use_openssl/lib -lssl -lcrypto ;; *) TCN_OPENSSL_LIBS=-L$use_openssl/lib -lssl -lcrypto --- build/tcnative.m4.orig 2008-01-04 14:18:10.0 +0100 +++ build/tcnative.m4 2008-01-04 14:54:50.0 +0100 @@ -336,7 +336,7 @@ TCN_OPENSSL_LIBS=-L$use_openssl/lib -Wl,+b: -lssl -lcrypto ;; *linux*) -TCN_OPENSSL_LIBS=-L$use_openssl/lib --Wl,-rpath,$use_openssl/lib -lssl -lcrypto +TCN_OPENSSL_LIBS=-L$use_openssl/lib -Wl,-rpath,$use_openssl/lib -lssl -lcrypto ;; *) TCN_OPENSSL_LIBS=-L$use_openssl/lib -lssl -lcrypto - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tc-native-1.1.12 fails to configure on Redhat EL4 x86_64 (... command not found)
Hi Rainer :) Rainer Jung schrieb: Hi Rainer, I can reproduce on Solaris. The first problem should be fixed by: --- configure.orig 2007-12-21 15:06:53.0 +0100 +++ configure 2008-01-04 14:16:13.0 +0100 ... --- build/tcnative.m4.orig 2008-01-04 14:18:10.0 +0100 +++ build/tcnative.m4 2008-01-04 14:16:05.0 +0100 ... First problem is fixed with your patch. Second seems not; I'm no expert with this build stuff, here's what I did: - applied the second patch to tcnative.m4 - then: # sh buildconf --with-apr=/usr/src/httpd-2.2.4 Looking for apr source in /usr/src/httpd-2.2.4 Creating configure ... Generating 'make' outputs ... buildconf: line 76: /usr/src/httpd-2.2.4/build/gen-build.py: Datei oder Verzeichnis nicht gefunden rebuilding rpm spec file - am I doing sth wrong here? - again: # ./configure --with-apr=/usr/local/apache2/ --with-ssl=/usr/include/openssl/ - config.log: configure:3522: gcc -o conftest -g -O2 -I/usr/include/openssl/include conftest.c -L/usr/include/openssl/lib --Wl,-rpath,/usr/include/openssl/lib -lssl -lcrypto 5 cc1: error: unrecognized command line option -fWl,-rpath,/usr/include/openssl/lib configure:3525: $? = 1 configure: program exited with status 1 Thx Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tc-native-1.1.12 fails to configure on Redhat EL4 x86_64 (... command not found)
Rainer Jung schrieb: Did you see my second post? Yes, but after I sent the reply. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tc-native-1.1.12 fails to configure on Redhat EL4 x86_64 (... command not found)
Did you see my second post? Rainer Traut schrieb: Hi Rainer :) Rainer Jung schrieb: Hi Rainer, I can reproduce on Solaris. The first problem should be fixed by: --- configure.orig 2007-12-21 15:06:53.0 +0100 +++ configure 2008-01-04 14:16:13.0 +0100 ... --- build/tcnative.m4.orig 2008-01-04 14:18:10.0 +0100 +++ build/tcnative.m4 2008-01-04 14:16:05.0 +0100 ... First problem is fixed with your patch. Second seems not; I'm no expert with this build stuff, here's what I did: - applied the second patch to tcnative.m4 - then: # sh buildconf --with-apr=/usr/src/httpd-2.2.4 Looking for apr source in /usr/src/httpd-2.2.4 Creating configure ... Generating 'make' outputs ... buildconf: line 76: /usr/src/httpd-2.2.4/build/gen-build.py: Datei oder Verzeichnis nicht gefunden rebuilding rpm spec file - am I doing sth wrong here? - again: # ./configure --with-apr=/usr/local/apache2/ --with-ssl=/usr/include/openssl/ - config.log: configure:3522: gcc -o conftest -g -O2 -I/usr/include/openssl/include conftest.c -L/usr/include/openssl/lib --Wl,-rpath,/usr/include/openssl/lib -lssl -lcrypto 5 cc1: error: unrecognized command line option -fWl,-rpath,/usr/include/openssl/lib configure:3525: $? = 1 configure: program exited with status 1 Thx Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem getting GlobalNamingResources DataSource DBCP from Custom JAAS
Hello again Mark, I have been looking in DataSourceRealm.java file as you
write below in previous messages.
Following the same method I change my code to:
Context context = null;
context = ContextBindings.getClassLoader();
context = (Context) context.lookup(comp/env);
dataSourceSQL = (DataSource)
context.lookup(jdbc/dataSource_usuarios_aplicaciones_Local);
But the same exception is thrown:
javax.naming.NameNotFoundException: Name jdbc is not bound in this Context
Has anything change inside JNDI from tomcat 5.5 to tomcat 6.0 ?
I am confused because my implementation works perfectly on tomcat 5.5.25.
To clear my confusion I wrote this simple lines for output the names binding
to 'comp/env' using both methods.
try {
Context context = (Context) ContextBindings.getClassLoader().
lookup(comp/env);
System.out.println(
\n ---
ContextBindings.getClassLoader().lookup('comp/env') - +
context.list());
if ( context!=null ) {
System.out.println( --- context != null);
}
NamingEnumeration list = context.list();
while (list.hasMore()) {
NameClassPair nc = (NameClassPair)list.next();
System.out.println( --- + nc.toString() );
}
} catch (NamingException ex) {
System.out.println(
NamingException ContextBindings.getClassLoader(). +
lookup('comp/env') - context.list(): +
ex.getMessage());
}
try {
Context context = new InitialContext();
context = (Context) context.lookup(java:comp/env);
System.out.println(
\n --- new InitialContext() - +
(Context) context.lookup('java:comp/env') -
context.list());
if ( context!=null ) {
System.out.println( --- context != null);
}
NamingEnumeration list = context.list();
while (list.hasMore()) {
NameClassPair nc = (NameClassPair)list.next();
System.out.println( --- + nc.toString() );
}
} catch (NamingException ex) {
System.out.println(
NamingException new InitialContext() - +
(Context) context.lookup('java:comp/env') -
context.list(): +
ex.getMessage());
}
I run this code in both tomcat servers 5.5.25 and 6.0.14 and this was the
output:
Output in Tomcat 5.5.25:
--- ContextBindings.getClassLoader().lookup('comp/env') - context.list()
--- context != null
--- users: org.apache.naming.ResourceEnvRef
--- jdbc: org.apache.naming.NamingContext
--- new InitialContext() - (Context) context.lookup('java:comp/env') -
context.list()
--- context != null
--- users: org.apache.naming.ResourceEnvRef
--- jdbc: org.apache.naming.NamingContext
Output in Tomcat 6.0.14:
--- ContextBindings.getClassLoader().lookup('comp/env') - context.list()
--- context != null
--- users: org.apache.naming.ResourceEnvRef
--- new InitialContext() - (Context) context.lookup('java:comp/env') -
context.list()
--- context != null
--- users: org.apache.naming.ResourceEnvRef
I think tomcat 6.0.14 does not offer jdbc: org.apache.naming.NamingContext
where I put my data source.
Best regards and thank you very much for your attention,
Mariano Lopez
-Mensaje original-
De: Mariano [mailto:[EMAIL PROTECTED]
Enviado el: jueves, 03 de enero de 2008 8:37
Para: Tomcat User-List (E-mail)
Asunto: RE: Problem getting GlobalNamingResources DataSource DBCP from
Custom JAAS
Thanks for the reply Mark but I think that the problem is from getting JNDI
objects out of context, like my case is. Remember I need it to implement a
custom JAAS and the same implementation works perfectly on tomcat 5.5.25,
but not on tomcat 6.0.14.
I searched in bug database and nothing found.
I will try to open a new bug in tomcat bug database.
Regards,
Mariano
-Mensaje original-
De: Mark Thomas [mailto:[EMAIL PROTECTED]
Enviado el: miércoles, 02 de enero de 2008 20:52
Para: Tomcat Users List
Asunto: Re: Problem getting GlobalNamingResources DataSource DBCP from
Custom JAAS
Mariano wrote:
Please any idea ?.
Try looking at how the DataSourceRealm does it.
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalin
a/realm/DataSourceRealm.java
Mark
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: tc-native-1.1.12 fails to configure on Redhat EL4 x86_64 (... command not found)
Replace --Wl, by -Wl, in configure and build/tcnative.m4.
--- configure.orig 2007-12-21 15:06:53.0 +0100
+++ configure 2008-01-04 14:41:51.0 +0100
@@ -3936,7 +3936,7 @@
TCN_OPENSSL_LIBS=-L$use_openssl/lib -Wl,+b: -lssl
-lcrypto
;;
*linux*)
-TCN_OPENSSL_LIBS=-L$use_openssl/lib
--Wl,-rpath,$use_openssl/lib -lssl -lcrypto
+TCN_OPENSSL_LIBS=-L$use_openssl/lib
-Wl,-rpath,$use_openssl/lib -lssl -lcrypto
;;
*)
TCN_OPENSSL_LIBS=-L$use_openssl/lib -lssl -lcrypto
--- build/tcnative.m4.orig 2008-01-04 14:18:10.0 +0100
+++ build/tcnative.m4 2008-01-04 14:54:50.0 +0100
@@ -336,7 +336,7 @@
TCN_OPENSSL_LIBS=-L$use_openssl/lib -Wl,+b: -lssl
-lcrypto
;;
*linux*)
-TCN_OPENSSL_LIBS=-L$use_openssl/lib
--Wl,-rpath,$use_openssl/lib -lssl -lcrypto
+TCN_OPENSSL_LIBS=-L$use_openssl/lib
-Wl,-rpath,$use_openssl/lib -lssl -lcrypto
;;
*)
TCN_OPENSSL_LIBS=-L$use_openssl/lib -lssl -lcrypto
HTH
Rainer
Rainer Traut schrieb:
Rainer Traut schrieb:
I get many error msgs from this new thing; 1.1.10 was fine. I cut the
rest of the lines with 'command not found'.
# ./configure --with-apr=/usr/local/apache2/
--with-ssl=/usr/include/openssl/
...
checking for OpenSSL library... using openssl from
/usr/include/openssl//lib and /usr/include/openssl//include
checking OpenSSL library version... not compatible
...
./configure: line 4316: APR_INCLUDES: command not found
./configure: line 4317: APR_LIBS: command not found
./configure: line 4318: APR_LIB_TARGET: command not found
...
And even more in config.log regarding the openssl library problem.
configure:3961: checking OpenSSL library version
configure:3995: gcc -o conftest -g -O2 -I/usr/include/openssl//include
conftest.c -L/usr/include/openssl//lib
--Wl,-rpath,/usr/include/openssl//lib -lssl -lcrypto 5
cc1: error: unrecognized command line option
-fWl,-rpath,/usr/include/openssl//lib
configure:3998: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| #include stdio.h
| #include openssl/opensslv.h
| int main() {
| if ((OPENSSL_VERSION_NUMBER = 0x0090701fL
| OPENSSL_VERSION_NUMBER 0x00908000L) ||
| OPENSSL_VERSION_NUMBER = 0x0090802fL)
| return (0);
| printf(\n\nFound OPENSSL_VERSION_NUMBER %#010x\n,
| OPENSSL_VERSION_NUMBER);
| printf(Require OPENSSL_VERSION_NUMBER 0x0090701f or greater
(0.9.7a)\n
|Require OPENSSL_VERSION_NUMBER 0x0090802f or greater
(0.9.8a)\n\n);
| return (1);
| }
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jdbc connection pooling
I'm using the connection pooling on Tomcat 6. And in my case i had to put the jar from the jdbc driver on. $CATALINA_HOME/lib On Jan 4, 2008 2:05 PM, Scott McClanahan [EMAIL PROTECTED] wrote: We are about to start testing the jdbc connection pooling capabilities within tomcat. I don't have any control over the application instead perform only administrative duties. Between the developers and myself we have done a good bit of research and mapped out a decent plan but there is one unresolved dispute between us. The developer says that the jar file containing the database driver should be published within the web applications WEB-INF/lib folder while I say it should be in $CATALINA_HOME/common/lib. Who is right and why? We hoped to define the datasource as a Resource within a DefaultContext element in the server.xml so it is available to all web applications. Is this good practice? I'd like to know of some ways you folks have done it too if you've got the time. Also any gotchas to look out for with connection pooling would be helpful from those who have actually done it. Thanks. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Diego
Re: jdbc connection pooling
As you've described it using tomcat's JNDI resources, the driver has to be in common/lib. If the application defines and manages it's own pool separate from tomcat, then you could put it in the app's WEB-INF/lib folder. This has everything to do with how the classloaders work. Since tomcat and your webapp both have to have access to the driver when using container managed connection pools, it has to be in common/lib. --David Scott McClanahan wrote: We are about to start testing the jdbc connection pooling capabilities within tomcat. I don't have any control over the application instead perform only administrative duties. Between the developers and myself we have done a good bit of research and mapped out a decent plan but there is one unresolved dispute between us. The developer says that the jar file containing the database driver should be published within the web applications WEB-INF/lib folder while I say it should be in $CATALINA_HOME/common/lib. Who is right and why? We hoped to define the datasource as a Resource within a DefaultContext element in the server.xml so it is available to all web applications. Is this good practice? I'd like to know of some ways you folks have done it too if you've got the time. Also any gotchas to look out for with connection pooling would be helpful from those who have actually done it. Thanks. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jdbc connection pooling
From: Scott McClanahan [mailto:[EMAIL PROTECTED] Subject: jdbc connection pooling The developer says that the jar file containing the database driver should be published within the web applications WEB-INF/lib folder while I say it should be in $CATALINA_HOME/common/lib. You are correct, the developer is wrong. If Tomcat is to manage the connections, its internal classes must be able to see the JDBC driver classes. Look at the classloader hierarchy. Note that Tomcat 5.0.x is deprecated; you should be using a newer level. We hoped to define the datasource as a Resource within a DefaultContext element in the server.xml so it is available to all web applications. This is not unusual, although DefaultContext is not used in 5.5 and beyond; there's a context.xml file in the conf directory instead. Also any gotchas to look out for with connection pooling would be helpful from those who have actually done it. Make sure the webapp code includes finally clauses on all DB access to make sure the connections are logically closed and thereby returned to the pool. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jdbc connection pooling
On Fri, 2008-01-04 at 10:23 -0600, Caldarale, Charles R wrote: From: Scott McClanahan [mailto:[EMAIL PROTECTED] Subject: jdbc connection pooling The developer says that the jar file containing the database driver should be published within the web applications WEB-INF/lib folder while I say it should be in $CATALINA_HOME/common/lib. You are correct, the developer is wrong. If Tomcat is to manage the connections, its internal classes must be able to see the JDBC driver classes. Look at the classloader hierarchy. Note that Tomcat 5.0.x is deprecated; you should be using a newer level. We hoped to define the datasource as a Resource within a DefaultContext element in the server.xml so it is available to all web applications. This is not unusual, although DefaultContext is not used in 5.5 and beyond; there's a context.xml file in the conf directory instead. Also any gotchas to look out for with connection pooling would be helpful from those who have actually done it. Make sure the webapp code includes finally clauses on all DB access to make sure the connections are logically closed and thereby returned to the pool. - Chuck I'm going to try my best to not sound ignorant but can you better explain what you mean when you say tomcat manages the connections compared to if the application (using the same apache commons projects) were to manage the connections. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jdbc connection pooling
We are about to start testing the jdbc connection pooling capabilities within tomcat. I don't have any control over the application instead perform only administrative duties. Between the developers and myself we have done a good bit of research and mapped out a decent plan but there is one unresolved dispute between us. The developer says that the jar file containing the database driver should be published within the web applications WEB-INF/lib folder while I say it should be in $CATALINA_HOME/common/lib. Who is right and why? We hoped to define the datasource as a Resource within a DefaultContext element in the server.xml so it is available to all web applications. Is this good practice? I'd like to know of some ways you folks have done it too if you've got the time. Also any gotchas to look out for with connection pooling would be helpful from those who have actually done it. Thanks. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jdbc connection pooling
On Fri, 2008-01-04 at 14:12 -0200, Diego wrote: I'm using the connection pooling on Tomcat 6. And in my case i had to put the jar from the jdbc driver on. $CATALINA_HOME/lib On Jan 4, 2008 2:05 PM, Scott McClanahan [EMAIL PROTECTED] wrote: We are about to start testing the jdbc connection pooling capabilities within tomcat. I don't have any control over the application instead perform only administrative duties. Between the developers and myself we have done a good bit of research and mapped out a decent plan but there is one unresolved dispute between us. The developer says that the jar file containing the database driver should be published within the web applications WEB-INF/lib folder while I say it should be in $CATALINA_HOME/common/lib. Who is right and why? We hoped to define the datasource as a Resource within a DefaultContext element in the server.xml so it is available to all web applications. Is this good practice? I'd like to know of some ways you folks have done it too if you've got the time. Also any gotchas to look out for with connection pooling would be helpful from those who have actually done it. Thanks. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] My apologies, we are running tomcat 5.0.28 on linux. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jdbc connection pooling
From: Scott McClanahan [mailto:[EMAIL PROTECTED] Subject: RE: jdbc connection pooling I'm going to try my best to not sound ignorant but can you better explain what you mean when you say tomcat manages the connections compared to if the application (using the same apache commons projects) were to manage the connections. Functionally no significant differences, other than having Tomcat manage them allows them to be shared across multiple webapps. Since the connection pooling logic is already included with Tomcat (and pretty much every other app server), there's no reason to carry that around in your webapp. If you want to have pooled connections private to a particular webapp, then placing the driver and various commons jars in WEB-INF/lib would be appropriate. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jdbc connection pooling
On Fri, 2008-01-04 at 11:16 -0600, Caldarale, Charles R wrote: From: Scott McClanahan [mailto:[EMAIL PROTECTED] Subject: RE: jdbc connection pooling I'm going to try my best to not sound ignorant but can you better explain what you mean when you say tomcat manages the connections compared to if the application (using the same apache commons projects) were to manage the connections. Functionally no significant differences, other than having Tomcat manage them allows them to be shared across multiple webapps. Since the connection pooling logic is already included with Tomcat (and pretty much every other app server), there's no reason to carry that around in your webapp. If you want to have pooled connections private to a particular webapp, then placing the driver and various commons jars in WEB-INF/lib would be appropriate. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks Chuck. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat + HttpClient + SSL + tcnative-1.dll issues?
We're narrowed down the problem further. It appears that a buffer within the SSL decoding process is not flushed properly which results in the HTTP request being sent to the application (Tomcat) twice. Wireshark clearly shows only one request, while the Tomcat access log shows two. As previously stated, this does not happen when we remove tcnative and use the built-in SSL decryption. Nor when plain HTTP is used. We've also reproduced the problem with Firefox as the HTTPS client, whereas the original issue was seen with HttpClient from Jakarta Commons (http://hc.apache.org/httpclient-3.x/). The timing, in the Tomcat access log, of the redundant request varies a bit based on the client. With HttpClient, the superfluous request appears when the TCP connection is reset, which is about 15s after the request was received. With Firefox, the dup is seen only when a subsequent request is made, as though it removes a clog. How do we go about debugging this? Is there any lower level tracing we can enable? Somewhere between the Tomcat access log and a sniffer trace? Thanks, JP Jim Brikman (ybrikman) wrote: Are there any known issues when using the Apache HttpClient to send https requests to Tomcat running with tcnative-1.dll? Perhaps different SSL stacks causing issues? The issue we are seeing is duplicate messages: our HttpClient sends just one copy of the message (an https request), but on the Tomcat side (with tcnative-1.dll) we are seeing the message twice. This only happens with https and not http. Jim Yevgeniy (Jim) Brikman Software Engineer Voice Technology Group [EMAIL PROTECTED] Phone :978-936-0510 Mobile :617-538-2632 500 Beaver Brook Road Boxborough, MA 01719 United States www.cisco.com http://www.cisco.com/ -- View this message in context: http://www.nabble.com/Tomcat-%2B-HttpClient-%2B-SSL-%2B-tcnative-1.dll-issues--tp14587172p14623993.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Content_Length Problem
I have a custom webservice hosted on IIS 6.0 and Tomcat 6, and I am using the latest version of the isapi_redirect.dll. The problem occurs when a CICS mainframe application tries to call this webservice. Everything appears to work fine, but the CICS application receives a response indicating a zero length message. I can view the message being sent from the webservice and this is definitely not the case (have also taken several packet traces to confirm this). We sent our problem to the folks over at IBM and they say that the CONTENT_LENGTH is not being set. Here is their response: The problem is that there isn't a Content-Length header sent by the IIS/Tomcat Server. CICS receives the headers and finds it is an HTTP/1.1 response for a Connection: Close. There isn't a Content-Length header so there can't be any user data (HTTP/1.1 has to supply Content-Length) so DFHWBCL just closes the session. PI domain then indicates that it failed to receive a response. The customer needs to investigate why their IIS server didn't return a Content-Length header. . The Content-Length header is mandatory for CICS' HTTP/1.1 conversations. This is documented in the CICS/TS 3.1 Internet Guide, section 1.3.11.1 (CICS Web support behavior in compliance with HTTP/1.1); this chapter documents the requirement in a section titled New Behavior for CICS TS Version 3, under the first item CICS checks inbound messages for compliance with HTTP/1.1, and handles or rejects non-compliant messages: Note: CICS requires the Content-Length header on all inbound HTTP/1.1 messages that have a message body. If a message body is present but the header is not provided, or its value is inaccurate, the socket receive for the faulty message or for a subsequent message can produce unpredictable results. For HTTP/1.0 messages that have a message body, the Content-Length header is optional. . The reason this is mandatory under CICS/TS 3.1, is due to our adherance to HTTP/1.1 specifications -- in other words, your HTTP/1.1 Web Service PROVIDER platform must provide this header, to be considered compliant. . Please ensure the IIS/Tomcat server sends a proper header. If we make the same request directly to Tomcat using the port number it works fine. The problem either lies in the isapi_redirect.dll or the IIS configuration. Does anyone have any ideas on what I can try to resolve this? Is there a know bug with the isapi_redirect.dll and CONTENT_LENGTH? Thanks- Joe This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail to [EMAIL PROTECTED] and delete the document. E-mails containing unprofessional, discourteous or offensive remarks violate Sentry policy. You may report employee violations by forwarding the message to [EMAIL PROTECTED] No recipient may use the information in this e-mail in violation of any civil or criminal statute. Sentry disclaims all liability for any unauthorized uses of this e-mail or its contents. This e-mail constitutes neither an offer nor an acceptance of any offer. No contract may be entered into by a Sentry employee without express approval from an authorized Sentry manager. Warning: Computer viruses can be transmitted via e-mail. Sentry accepts no liability or responsibility for any damage caused by any virus transmitted with this e-mail.
Re: Content_Length Problem
Hi Joe, are you able to reproduce the behaviour with few, maybe only a single request? If so: you can increase JkLogLevel to debug (not recommended for high load production size, because it produces a lot of log lines), reproduce the problem and make the log file available. What I didn't really understand from your post: do you know, if the Content-Length header gets send or not? How do you know? Did you sniff the network traffic or do you only know from the CICS behaviour? Lastly: HTTP/1.1 responses without Content-Length headers are valid if they are using chunked encoding (Transfer-Encoding: chunked). I think at the moment the isapi redirector does not use chunked encoding (didn't yet test, but there's an open RFE to implement chunked encoding in the isapi redirecotr), but I want to clarify the absolute statement concerning the http protocol. Chunked encoding replaces the content-length header with sending the number of bytes available in front of every chunk, s.t. the receiving node knows, how much data to expect, without the sending node needing to know the full size before sending. Dynamically generated content often uses chunked encoding to prevent the need of buffering the whole reposne before sending. Regards, Rainer Woytasik Joe schrieb: I have a custom webservice hosted on IIS 6.0 and Tomcat 6, and I am using the latest version of the isapi_redirect.dll. The problem occurs when a CICS mainframe application tries to call this webservice. Everything appears to work fine, but the CICS application receives a response indicating a zero length message. I can view the message being sent from the webservice and this is definitely not the case (have also taken several packet traces to confirm this). We sent our problem to the folks over at IBM and they say that the CONTENT_LENGTH is not being set. Here is their response: The problem is that there isn't a Content-Length header sent by the IIS/Tomcat Server. CICS receives the headers and finds it is an HTTP/1.1 response for a Connection: Close. There isn't a Content-Length header so there can't be any user data (HTTP/1.1 has to supply Content-Length) so DFHWBCL just closes the session. PI domain then indicates that it failed to receive a response. The customer needs to investigate why their IIS server didn't return a Content-Length header. . The Content-Length header is mandatory for CICS' HTTP/1.1 conversations. This is documented in the CICS/TS 3.1 Internet Guide, section 1.3.11.1 (CICS Web support behavior in compliance with HTTP/1.1); this chapter documents the requirement in a section titled New Behavior for CICS TS Version 3, under the first item CICS checks inbound messages for compliance with HTTP/1.1, and handles or rejects non-compliant messages: Note: CICS requires the Content-Length header on all inbound HTTP/1.1 messages that have a message body. If a message body is present but the header is not provided, or its value is inaccurate, the socket receive for the faulty message or for a subsequent message can produce unpredictable results. For HTTP/1.0 messages that have a message body, the Content-Length header is optional. . The reason this is mandatory under CICS/TS 3.1, is due to our adherance to HTTP/1.1 specifications -- in other words, your HTTP/1.1 Web Service PROVIDER platform must provide this header, to be considered compliant. . Please ensure the IIS/Tomcat server sends a proper header. If we make the same request directly to Tomcat using the port number it works fine. The problem either lies in the isapi_redirect.dll or the IIS configuration. Does anyone have any ideas on what I can try to resolve this? Is there a know bug with the isapi_redirect.dll and CONTENT_LENGTH? Thanks- Joe This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail to [EMAIL PROTECTED] and delete the document. E-mails containing unprofessional, discourteous or offensive remarks violate Sentry policy. You may report employee violations by forwarding the message to [EMAIL PROTECTED] No recipient may use the information in this e-mail in violation of any civil or criminal statute. Sentry disclaims all liability for any unauthorized uses of this e-mail or its contents. This e-mail constitutes neither an offer nor an acceptance of any offer. No contract may be entered into by a Sentry employee without express approval from an authorized Sentry manager. Warning: Computer viruses can be transmitted via e-mail. Sentry accepts no liability or responsibility for any damage caused by any virus transmitted with this e-mail. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL
Problems with HTTPS Mutual authentication with big petitions
Hello, I'm running into problems when I try to configure tomcat to validate the client by its https cert with big requests. I'm using it with forms and when the send the form to the server with big (10-15Kbytes) requests it fails, but when I send small (90 bytes) requests it works. I have on the web.xml a security constrain: security-constraint web-resource-collection web-resource-nameMutual auth/web-resource-name url-pattern/page1.htm/url-pattern url-pattern/page2.htm/url-pattern /web-resource-collection auth-constraint role-nameclientHttpsRole/role-name /auth-constraint user-data-constraint transport-guarantee CONFIDENTIAL /transport-guarantee /user-data-constraint /security-constraint login-config auth-methodCLIENT-CERT/auth-method /login-config security-role role-nameclientHttpsRole/role-name /security-role and I created the user: user username=CN=WHATEVER password=null roles=clientHttpsRole/ Here is the snip with the https connector of the server.xml: Connector port=8443 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 debug=0 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreType=JKS keystoreFile=keystore keystorePass=password truststoreFile=keystore truststorePass=password/ What makes me worry is that it works fine when I set the https connector with clientAuth=true. -- Atentamente, Nicolás Velásquez O. Bogotá, Colombia (^) ASCII Ribbon Campaign XNO HTML/RTF in e-mail / \ NO Word docs in e-mail - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
tld parsing error after upgrade to TC6
Hello everyone. I'm currently working on upgrading our environment to Tomcat 6.0.14 from 5.0.27. This is run on Apache 1.3.33 with mod_jk 1.2.25 (which is being upgraded from jk2). I'm able to get the basic sites working fine, however, there are a few applications that are still causing issues, and was hoping someone here could at least point me in the right direction on how to determine the exact cause of the issue. Running Tomcat with debug logging (java.security.debug=access,failure) enabled, I get the following output regarding the error. Now, based off this output, it sounds like the error is occurring when the taglib.tld file from the jspsql.jar file attempts to make a call to an external website. Also, this error only occurs when we have -security enabled on startup of Tomcat (which it needs to be for our environment). If anyone can offer some advice on what the cause and/or resolution of this may be, I would be most grateful. access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/lib/xercesImpl.jar read) access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/lib/xercesImpl.jar read) access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/lib/xercesImpl.jar read) access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/classes/org/apache/xerces/util/XMLChar.class read) access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/lib/xercesImpl.jar read) access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/lib/xercesImpl.jar read) access: access allowed (java.io.FilePermission /path/to/home/dir/html/app_name/WEB-INF/lib/xercesImpl.jar read) access: access denied (java.io.FilePermission /web/tomcat/lib/jsp-api.jar read) java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1206) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:313) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.util.zip.ZipFile.init(ZipFile.java:109) at java.util.jar.JarFile.init(JarFile.java:133) at java.util.jar.JarFile.init(JarFile.java:70) at sun.net.www.protocol.jar.URLJarFile.init(URLJarFile.java:72) at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:48) at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:53) at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:104) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:132) at java.net.URL.openStream(URL.java:1009) at org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:740) at org.apache.xerces.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:700) at org.apache.xerces.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:258) at org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:811) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:333) at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:525) at org.apache.xerces.parsers.StandardParserConfiguration.parse(StandardParserConfiguration.java:581) at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147) at org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1157) at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1562) at org.apache.catalina.startup.TldConfig.tldScanStream(TldConfig.java:518) at org.apache.catalina.startup.TldConfig.tldScanJar(TldConfig.java:476) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:301) at org.apache.catalina.core.StandardContext.processTlds(StandardContext.java:4428) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4235) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:123) at org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145) at java.security.AccessController.doPrivileged(Native Method) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:769) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:825) at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:714) at
RE: Content_Length Problem
Rainer, I don't think that chunked encoding will solve the problem I outlined. Just out of curiosity is there something special I need to do to enable chunked encoding once the patch is applied? Where is a good place to upload my log file? Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 3:29 PM To: Tomcat Users List Subject: Re: Content_Length Problem Hi Joe, the isapi chunked encoding patch shouldn't solve your problem. As I understand the topic it will not add a content-length header but enable chunked encoding, which doesn't use content-length. Clean up your jk log and let us/me have a look at it. I hope we can then see if anything is wrong and if so what it is. Regards, Rainer Woytasik Joe schrieb: Rainer, Thanks for the quick response! I am able to repeat this request, and each time I get the same response. The logging level is set to debug, but unfortunately I am unable to send the log file (company policy). I am going to scrub the log file to remove any sensitive information, I will send that your way shortly. I did some network sniffing and CONTENT_LENGTH is not sent. I built a new isapi_redirect.dll using the patch provided in Bugzilla. This patch was supposed to allow chunked encoding, but I am not sure if I applied it right. Is there a registry setting that I need to change to allow chunked encoding with this patch, or does it do it automatically? Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 2:06 PM To: Tomcat Users List Subject: Re: Content_Length Problem Hi Joe, are you able to reproduce the behaviour with few, maybe only a single request? If so: you can increase JkLogLevel to debug (not recommended for high load production size, because it produces a lot of log lines), reproduce the problem and make the log file available. What I didn't really understand from your post: do you know, if the Content-Length header gets send or not? How do you know? Did you sniff the network traffic or do you only know from the CICS behaviour? Lastly: HTTP/1.1 responses without Content-Length headers are valid if they are using chunked encoding (Transfer-Encoding: chunked). I think at the moment the isapi redirector does not use chunked encoding (didn't yet test, but there's an open RFE to implement chunked encoding in the isapi redirecotr), but I want to clarify the absolute statement concerning the http protocol. Chunked encoding replaces the content-length header with sending the number of bytes available in front of every chunk, s.t. the receiving node knows, how much data to expect, without the sending node needing to know the full size before sending. Dynamically generated content often uses chunked encoding to prevent the need of buffering the whole reposne before sending. Regards, Rainer Woytasik Joe schrieb: I have a custom webservice hosted on IIS 6.0 and Tomcat 6, and I am using the latest version of the isapi_redirect.dll. The problem occurs when a CICS mainframe application tries to call this webservice. Everything appears to work fine, but the CICS application receives a response indicating a zero length message. I can view the message being sent from the webservice and this is definitely not the case (have also taken several packet traces to confirm this). We sent our problem to the folks over at IBM and they say that the CONTENT_LENGTH is not being set. Here is their response: The problem is that there isn't a Content-Length header sent by the IIS/Tomcat Server. CICS receives the headers and finds it is an HTTP/1.1 response for a Connection: Close. There isn't a Content-Length header so there can't be any user data (HTTP/1.1 has to supply Content-Length) so DFHWBCL just closes the session. PI domain then indicates that it failed to receive a response. The customer needs to investigate why their IIS server didn't return a Content-Length header. . The Content-Length header is mandatory for CICS' HTTP/1.1 conversations. This is documented in the CICS/TS 3.1 Internet Guide, section 1.3.11.1 (CICS Web support behavior in compliance with HTTP/1.1); this chapter documents the requirement in a section titled New Behavior for CICS TS Version 3, under the first item CICS checks inbound messages for compliance with HTTP/1.1, and handles or rejects non-compliant messages: Note: CICS requires the Content-Length header on all inbound HTTP/1.1 messages that have a message body. If a message body is present but the header is not provided, or its value is inaccurate, the socket receive for the faulty message or for a subsequent message can produce unpredictable results. For HTTP/1.0 messages that have a message body, the Content-Length header is optional. . The reason this is mandatory under CICS/TS
RE: Apache Portable Runtime and Tomcat?
Hi Rainer, Thanks for the quick response! A couple more questions: if we grab the code for APR, OpenSSL and tcnative, and compile them (yes, we are on Windows), what will we get? Several dll's? And if so, do we just replace the tcnative-1.dll with these dll's or is there some other configuration that is necessary? Thanks, Jim -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 4:34 PM To: Tomcat Users List Subject: Re: Apache Portable Runtime and Tomcat? Hi Jim, APR and OpenSSL are maintained by other projects (apr.apache.org resp. www.openssl.org). The tcnative source can be obtained from http://www.apache.org/dist/tomcat/tomcat-connectors/native/ The download contain a dsp file for Visual Studio (supposing you are talking about WIN platform because you mentioned DLL), and a configure script for Unix/Linux. The configure script of the most recent version is 1.1.12 is broken (see mail on this list today), but the library code is fine. Regards, Rainer Jim Brikman (ybrikman) schrieb: The User Guide for the Apache Portable Runtime with Tomcat (http://tomcat.apache.org/tomcat-5.5-doc/apr.html) states the following: Windows binaries are provided for tcnative-1, which is a statically compiled .dll which includes OpenSSL and APR. It can be downloaded from here http://tomcat.heanet.ie/native/ as 32bit or AMD x86-64 binaries. In security conscious production environments, it is recommended to use separate shared dlls for OpenSSL, APR, and libtcnative-1, and update them as needed according to security bulletins. It may be obvious, but does anyone have step-by-step instructions on where/how to download/build these shared dlls for OpenSSL, APR and libtcnative-1 and configure Tomcat to use them? Thanks, Jim *Yevgeniy (Jim) Brikman* *Software Engineer* **Voice Technology Group* * [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Phone :*978-936-0510* Mobile :*617-538-2632* ** 500 Beaver Brook Road Boxborough, MA 01719 United States www.cisco.com http://www.cisco.com/ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: jdbc connection pooling
NOT in the WEB-INF/lib -- put in the common/lib - that's where it goes. You might get very erratic performance putting the jar file in both places. make sure you know how to configure either your server.xml file or respective META-INF/ .xml file appropriately. Depends on which TC version you use. -Original Message- From: Scott McClanahan [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 10:05 AM To: Tomcat Users List Subject: jdbc connection pooling We are about to start testing the jdbc connection pooling capabilities within tomcat. I don't have any control over the application instead perform only administrative duties. Between the developers and myself we have done a good bit of research and mapped out a decent plan but there is one unresolved dispute between us. The developer says that the jar file containing the database driver should be published within the web applications WEB-INF/lib folder while I say it should be in $CATALINA_HOME/common/lib. Who is right and why? We hoped to define the datasource as a Resource within a DefaultContext element in the server.xml so it is available to all web applications. Is this good practice? I'd like to know of some ways you folks have done it too if you've got the time. Also any gotchas to look out for with connection pooling would be helpful from those who have actually done it. Thanks. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Portable Runtime and Tomcat?
Hi Jim, APR and OpenSSL are maintained by other projects (apr.apache.org resp. www.openssl.org). The tcnative source can be obtained from http://www.apache.org/dist/tomcat/tomcat-connectors/native/ The download contain a dsp file for Visual Studio (supposing you are talking about WIN platform because you mentioned DLL), and a configure script for Unix/Linux. The configure script of the most recent version is 1.1.12 is broken (see mail on this list today), but the library code is fine. Regards, Rainer Jim Brikman (ybrikman) schrieb: The User Guide for the Apache Portable Runtime with Tomcat (http://tomcat.apache.org/tomcat-5.5-doc/apr.html) states the following: Windows binaries are provided for tcnative-1, which is a statically compiled .dll which includes OpenSSL and APR. It can be downloaded from here http://tomcat.heanet.ie/native/ as 32bit or AMD x86-64 binaries. In security conscious production environments, it is recommended to use separate shared dlls for OpenSSL, APR, and libtcnative-1, and update them as needed according to security bulletins. It may be obvious, but does anyone have step-by-step instructions on where/how to download/build these shared dlls for OpenSSL, APR and libtcnative-1 and configure Tomcat to use them? Thanks, Jim *Yevgeniy (Jim) Brikman* *Software Engineer* **Voice Technology Group* * [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Phone :*978-936-0510* Mobile :*617-538-2632* ** 500 Beaver Brook Road Boxborough, MA 01719 United States www.cisco.com http://www.cisco.com/ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Content_Length Problem
Hi Joe, the isapi chunked encoding patch shouldn't solve your problem. As I understand the topic it will not add a content-length header but enable chunked encoding, which doesn't use content-length. Clean up your jk log and let us/me have a look at it. I hope we can then see if anything is wrong and if so what it is. Regards, Rainer Woytasik Joe schrieb: Rainer, Thanks for the quick response! I am able to repeat this request, and each time I get the same response. The logging level is set to debug, but unfortunately I am unable to send the log file (company policy). I am going to scrub the log file to remove any sensitive information, I will send that your way shortly. I did some network sniffing and CONTENT_LENGTH is not sent. I built a new isapi_redirect.dll using the patch provided in Bugzilla. This patch was supposed to allow chunked encoding, but I am not sure if I applied it right. Is there a registry setting that I need to change to allow chunked encoding with this patch, or does it do it automatically? Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 2:06 PM To: Tomcat Users List Subject: Re: Content_Length Problem Hi Joe, are you able to reproduce the behaviour with few, maybe only a single request? If so: you can increase JkLogLevel to debug (not recommended for high load production size, because it produces a lot of log lines), reproduce the problem and make the log file available. What I didn't really understand from your post: do you know, if the Content-Length header gets send or not? How do you know? Did you sniff the network traffic or do you only know from the CICS behaviour? Lastly: HTTP/1.1 responses without Content-Length headers are valid if they are using chunked encoding (Transfer-Encoding: chunked). I think at the moment the isapi redirector does not use chunked encoding (didn't yet test, but there's an open RFE to implement chunked encoding in the isapi redirecotr), but I want to clarify the absolute statement concerning the http protocol. Chunked encoding replaces the content-length header with sending the number of bytes available in front of every chunk, s.t. the receiving node knows, how much data to expect, without the sending node needing to know the full size before sending. Dynamically generated content often uses chunked encoding to prevent the need of buffering the whole reposne before sending. Regards, Rainer Woytasik Joe schrieb: I have a custom webservice hosted on IIS 6.0 and Tomcat 6, and I am using the latest version of the isapi_redirect.dll. The problem occurs when a CICS mainframe application tries to call this webservice. Everything appears to work fine, but the CICS application receives a response indicating a zero length message. I can view the message being sent from the webservice and this is definitely not the case (have also taken several packet traces to confirm this). We sent our problem to the folks over at IBM and they say that the CONTENT_LENGTH is not being set. Here is their response: The problem is that there isn't a Content-Length header sent by the IIS/Tomcat Server. CICS receives the headers and finds it is an HTTP/1.1 response for a Connection: Close. There isn't a Content-Length header so there can't be any user data (HTTP/1.1 has to supply Content-Length) so DFHWBCL just closes the session. PI domain then indicates that it failed to receive a response. The customer needs to investigate why their IIS server didn't return a Content-Length header. . The Content-Length header is mandatory for CICS' HTTP/1.1 conversations. This is documented in the CICS/TS 3.1 Internet Guide, section 1.3.11.1 (CICS Web support behavior in compliance with HTTP/1.1); this chapter documents the requirement in a section titled New Behavior for CICS TS Version 3, under the first item CICS checks inbound messages for compliance with HTTP/1.1, and handles or rejects non-compliant messages: Note: CICS requires the Content-Length header on all inbound HTTP/1.1 messages that have a message body. If a message body is present but the header is not provided, or its value is inaccurate, the socket receive for the faulty message or for a subsequent message can produce unpredictable results. For HTTP/1.0 messages that have a message body, the Content-Length header is optional. . The reason this is mandatory under CICS/TS 3.1, is due to our adherance to HTTP/1.1 specifications -- in other words, your HTTP/1.1 Web Service PROVIDER platform must provide this header, to be considered compliant. . Please ensure the IIS/Tomcat server sends a proper header. If we make the same request directly to Tomcat using the port number it works fine. The problem either lies in the isapi_redirect.dll or the IIS configuration. Does anyone have any ideas on what I can
Apache Portable Runtime and Tomcat?
The User Guide for the Apache Portable Runtime with Tomcat ( http://tomcat.apache.org/tomcat-5.5-doc/apr.html) states the following: Windows binaries are provided for tcnative-1, which is a statically compiled .dll which includes OpenSSL and APR. It can be downloaded from here http://tomcat.heanet.ie/native/ as 32bit or AMD x86-64 binaries. In security conscious production environments, it is recommended to use separate shared dlls for OpenSSL, APR, and libtcnative-1, and update them as needed according to security bulletins. It may be obvious, but does anyone have step-by-step instructions on where/how to download/build these shared dlls for OpenSSL, APR and libtcnative-1 and configure Tomcat to use them? Thanks, Jim Yevgeniy (Jim) Brikman Software Engineer Voice Technology Group [EMAIL PROTECTED] Phone :978-936-0510 Mobile :617-538-2632 500 Beaver Brook Road Boxborough, MA 01719 United States www.cisco.com http://www.cisco.com/
RE: Content_Length Problem
Rainer, Thanks for the quick response! I am able to repeat this request, and each time I get the same response. The logging level is set to debug, but unfortunately I am unable to send the log file (company policy). I am going to scrub the log file to remove any sensitive information, I will send that your way shortly. I did some network sniffing and CONTENT_LENGTH is not sent. I built a new isapi_redirect.dll using the patch provided in Bugzilla. This patch was supposed to allow chunked encoding, but I am not sure if I applied it right. Is there a registry setting that I need to change to allow chunked encoding with this patch, or does it do it automatically? Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 2:06 PM To: Tomcat Users List Subject: Re: Content_Length Problem Hi Joe, are you able to reproduce the behaviour with few, maybe only a single request? If so: you can increase JkLogLevel to debug (not recommended for high load production size, because it produces a lot of log lines), reproduce the problem and make the log file available. What I didn't really understand from your post: do you know, if the Content-Length header gets send or not? How do you know? Did you sniff the network traffic or do you only know from the CICS behaviour? Lastly: HTTP/1.1 responses without Content-Length headers are valid if they are using chunked encoding (Transfer-Encoding: chunked). I think at the moment the isapi redirector does not use chunked encoding (didn't yet test, but there's an open RFE to implement chunked encoding in the isapi redirecotr), but I want to clarify the absolute statement concerning the http protocol. Chunked encoding replaces the content-length header with sending the number of bytes available in front of every chunk, s.t. the receiving node knows, how much data to expect, without the sending node needing to know the full size before sending. Dynamically generated content often uses chunked encoding to prevent the need of buffering the whole reposne before sending. Regards, Rainer Woytasik Joe schrieb: I have a custom webservice hosted on IIS 6.0 and Tomcat 6, and I am using the latest version of the isapi_redirect.dll. The problem occurs when a CICS mainframe application tries to call this webservice. Everything appears to work fine, but the CICS application receives a response indicating a zero length message. I can view the message being sent from the webservice and this is definitely not the case (have also taken several packet traces to confirm this). We sent our problem to the folks over at IBM and they say that the CONTENT_LENGTH is not being set. Here is their response: The problem is that there isn't a Content-Length header sent by the IIS/Tomcat Server. CICS receives the headers and finds it is an HTTP/1.1 response for a Connection: Close. There isn't a Content-Length header so there can't be any user data (HTTP/1.1 has to supply Content-Length) so DFHWBCL just closes the session. PI domain then indicates that it failed to receive a response. The customer needs to investigate why their IIS server didn't return a Content-Length header. . The Content-Length header is mandatory for CICS' HTTP/1.1 conversations. This is documented in the CICS/TS 3.1 Internet Guide, section 1.3.11.1 (CICS Web support behavior in compliance with HTTP/1.1); this chapter documents the requirement in a section titled New Behavior for CICS TS Version 3, under the first item CICS checks inbound messages for compliance with HTTP/1.1, and handles or rejects non-compliant messages: Note: CICS requires the Content-Length header on all inbound HTTP/1.1 messages that have a message body. If a message body is present but the header is not provided, or its value is inaccurate, the socket receive for the faulty message or for a subsequent message can produce unpredictable results. For HTTP/1.0 messages that have a message body, the Content-Length header is optional. . The reason this is mandatory under CICS/TS 3.1, is due to our adherance to HTTP/1.1 specifications -- in other words, your HTTP/1.1 Web Service PROVIDER platform must provide this header, to be considered compliant. . Please ensure the IIS/Tomcat server sends a proper header. If we make the same request directly to Tomcat using the port number it works fine. The problem either lies in the isapi_redirect.dll or the IIS configuration. Does anyone have any ideas on what I can try to resolve this? Is there a know bug with the isapi_redirect.dll and CONTENT_LENGTH? Thanks- Joe This e-mail is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this e-mail in error, please tell us immediately by return e-mail to [EMAIL PROTECTED] and delete the document. E-mails containing unprofessional,
Re: Avoiding same server to server HTTP calls to generate HTML pages via JSPs
Here's some code that does what Gennady suggested, using
RequestDispatcher and wrapping the response object to capture the
output in a String.
public class JSPFormatter
{
public String formatPage(String stJSPFile,
HttpServletRequest request,
HttpServletResponse response,
ServletContext ctx)
throws ServletException, IOException
{
// Make a wrapper for the response, to capture the output.
ResponseWrapper rw = new ResponseWrapper(response);
// Call the JSP page and capture its output.
RequestDispatcher rd = ctx.getRequestDispatcher(stJSPFile);
rd.include(request, rw);
return rw.getOutputString();
}
/**
* Nested class ResponseWrapper: Wrapper for the response to
capture the servlet output.
*/
public class ResponseWrapper extends HttpServletResponseWrapper
{
protected StringWriter writer = null;
protected ByteArrayOutputStream stream = null;
public ResponseWrapper(HttpServletResponse response) {
super(response);
}
public String getOutputString() {
if (writer != null)
return writer.toString();
else if (stream != null)
return stream.toString();
else
return null;
}
public ServletOutputStream getOutputStream() throws IOException {
stream = new ByteArrayOutputStream();
return new OutputStreamWrapper();
}
public PrintWriter getWriter() throws IOException {
writer = new StringWriter();
return new PrintWriter(writer);
}
/**
* Nested class OutputStreamWrapper: Wrapper for the
OutputStream to turn it
* into a ServletOutputStream for getOutputStream.
*/
public class OutputStreamWrapper extends ServletOutputStream
{
public void write(int b) throws IOException {
stream.write(b);
}
}
}
}
--
Len
On Jan 4, 2008 4:15 AM, Gennady Shumakher [EMAIL PROTECTED] wrote:
If you cannot replace your jsps with velocity (or freemarker) you could
still use RequestDispatcher. Just provide your own implementation of
ServletResponse that mostly will be just wrapper based on servlet response
instance ( Tomcat implementation), but will buffer response output as
string rather than write it to output stream.
Gennady.
-Original Message-
From: Mikolaj Rydzewski [mailto:[EMAIL PROTECTED]
Sent: Friday, January 04, 2008 10:15
To: Tomcat Users List
Subject: Re: Avoiding same server to server HTTP calls to generate HTML
pages via JSPs
Adam Gordon wrote:
Right now we basically have a URL dispatcher that when a specific
request comes in, we make another request to retrieve the contents of
a URI (a JSP page to generate HTML) via a server-to-server HTTP call
and then essentially slap that into a MimeBodyPart for sending
text/html email messages.
Simply do not use JSP. Use Velocity for example.
--
Mikolaj Rydzewski [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Portable Runtime and Tomcat?
Hi Jim, to make it work, you need all three of them. I never used it in Windows, so I can only judge from the download and the docs page. The docs page http://tomcat.apache.org/tomcat-6.0-doc/apr.html says, that the precompiled binaries include openssl, apr and tcnative in one combined DLL. The source download contains two slightly different .dsp files, so I assume, one of them is for keeping the three DLLs separate, one for producing a single combined DLL. Regards, Rainer Jim Brikman (ybrikman) schrieb: Hi Rainer, Thanks for the quick response! A couple more questions: if we grab the code for APR, OpenSSL and tcnative, and compile them (yes, we are on Windows), what will we get? Several dll's? And if so, do we just replace the tcnative-1.dll with these dll's or is there some other configuration that is necessary? Thanks, Jim -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 4:34 PM To: Tomcat Users List Subject: Re: Apache Portable Runtime and Tomcat? Hi Jim, APR and OpenSSL are maintained by other projects (apr.apache.org resp. www.openssl.org). The tcnative source can be obtained from http://www.apache.org/dist/tomcat/tomcat-connectors/native/ The download contain a dsp file for Visual Studio (supposing you are talking about WIN platform because you mentioned DLL), and a configure script for Unix/Linux. The configure script of the most recent version is 1.1.12 is broken (see mail on this list today), but the library code is fine. Regards, Rainer Jim Brikman (ybrikman) schrieb: The User Guide for the Apache Portable Runtime with Tomcat (http://tomcat.apache.org/tomcat-5.5-doc/apr.html) states the following: Windows binaries are provided for tcnative-1, which is a statically compiled .dll which includes OpenSSL and APR. It can be downloaded from here http://tomcat.heanet.ie/native/ as 32bit or AMD x86-64 binaries. In security conscious production environments, it is recommended to use separate shared dlls for OpenSSL, APR, and libtcnative-1, and update them as needed according to security bulletins. It may be obvious, but does anyone have step-by-step instructions on where/how to download/build these shared dlls for OpenSSL, APR and libtcnative-1 and configure Tomcat to use them? Thanks, Jim *Yevgeniy (Jim) Brikman* *Software Engineer* **Voice Technology Group* * [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Phone :*978-936-0510* Mobile :*617-538-2632* ** 500 Beaver Brook Road Boxborough, MA 01719 United States www.cisco.com http://www.cisco.com/ - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk 1.2.26
I'm getting 404 errors when I try to access the jkmanager page. There is only one backend tomcat instance and no load balancing configuration at all. I was just wanting to see the UI and if it had changed at all with the upgrade. Do you now get 404's if you don't have a load balancing configuration? Maybe I've done something wrong but the config looks the same. I can post the config if it's not something more obvious with the update. Thanks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_jk 1.2.26
Scottcan you confirm these JKMount directives in $APACHE_HOME/conf/httpd.conf # send all requests ending in .jsp to ajp13JkMount /*.jsp ajp13 # send all requests ending /servlet to ajp13JkMount /*/servlet/ ajp13 ThanksMartin __Disclaimer and confidentiality noteEverything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Subject: mod_jk 1.2.26 From: [EMAIL PROTECTED] To: users@tomcat.apache.org Date: Fri, 4 Jan 2008 17:42:01 -0500 I'm getting 404 errors when I try to access the jkmanager page. There is only one backend tomcat instance and no load balancing configuration at all. I was just wanting to see the UI and if it had changed at all with the upgrade. Do you now get 404's if you don't have a load balancing configuration? Maybe I've done something wrong but the config looks the same. I can post the config if it's not something more obvious with the update. Thanks - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008
Re: Content_Length Problem
If you can sniff the response headers, you should be able to see whether the Transfer-Encoding is chunked or not. -- Len On Jan 4, 2008 4:10 PM, Woytasik Joe [EMAIL PROTECTED] wrote: Rainer, Thanks for the quick response! I am able to repeat this request, and each time I get the same response. The logging level is set to debug, but unfortunately I am unable to send the log file (company policy). I am going to scrub the log file to remove any sensitive information, I will send that your way shortly. I did some network sniffing and CONTENT_LENGTH is not sent. I built a new isapi_redirect.dll using the patch provided in Bugzilla. This patch was supposed to allow chunked encoding, but I am not sure if I applied it right. Is there a registry setting that I need to change to allow chunked encoding with this patch, or does it do it automatically? Thanks- Joe -Original Message- From: Rainer Jung [mailto:[EMAIL PROTECTED] Sent: Friday, January 04, 2008 2:06 PM To: Tomcat Users List Subject: Re: Content_Length Problem Hi Joe, are you able to reproduce the behaviour with few, maybe only a single request? If so: you can increase JkLogLevel to debug (not recommended for high load production size, because it produces a lot of log lines), reproduce the problem and make the log file available. What I didn't really understand from your post: do you know, if the Content-Length header gets send or not? How do you know? Did you sniff the network traffic or do you only know from the CICS behaviour? Lastly: HTTP/1.1 responses without Content-Length headers are valid if they are using chunked encoding (Transfer-Encoding: chunked). I think at the moment the isapi redirector does not use chunked encoding (didn't yet test, but there's an open RFE to implement chunked encoding in the isapi redirecotr), but I want to clarify the absolute statement concerning the http protocol. Chunked encoding replaces the content-length header with sending the number of bytes available in front of every chunk, s.t. the receiving node knows, how much data to expect, without the sending node needing to know the full size before sending. Dynamically generated content often uses chunked encoding to prevent the need of buffering the whole reposne before sending. Regards, Rainer Woytasik Joe schrieb: I have a custom webservice hosted on IIS 6.0 and Tomcat 6, and I am using the latest version of the isapi_redirect.dll. The problem occurs when a CICS mainframe application tries to call this webservice. Everything appears to work fine, but the CICS application receives a response indicating a zero length message. I can view the message being sent from the webservice and this is definitely not the case (have also taken several packet traces to confirm this). We sent our problem to the folks over at IBM and they say that the CONTENT_LENGTH is not being set. Here is their response: The problem is that there isn't a Content-Length header sent by the IIS/Tomcat Server. CICS receives the headers and finds it is an HTTP/1.1 response for a Connection: Close. There isn't a Content-Length header so there can't be any user data (HTTP/1.1 has to supply Content-Length) so DFHWBCL just closes the session. PI domain then indicates that it failed to receive a response. The customer needs to investigate why their IIS server didn't return a Content-Length header. . The Content-Length header is mandatory for CICS' HTTP/1.1 conversations. This is documented in the CICS/TS 3.1 Internet Guide, section 1.3.11.1 (CICS Web support behavior in compliance with HTTP/1.1); this chapter documents the requirement in a section titled New Behavior for CICS TS Version 3, under the first item CICS checks inbound messages for compliance with HTTP/1.1, and handles or rejects non-compliant messages: Note: CICS requires the Content-Length header on all inbound HTTP/1.1 messages that have a message body. If a message body is present but the header is not provided, or its value is inaccurate, the socket receive for the faulty message or for a subsequent message can produce unpredictable results. For HTTP/1.0 messages that have a message body, the Content-Length header is optional. . The reason this is mandatory under CICS/TS 3.1, is due to our adherance to HTTP/1.1 specifications -- in other words, your HTTP/1.1 Web Service PROVIDER platform must provide this header, to be considered compliant. . Please ensure the IIS/Tomcat server sends a proper header. If we make the same request directly to Tomcat using the port number it works fine. The problem either lies in the isapi_redirect.dll or the IIS configuration. Does anyone have any ideas on what I can try to resolve this? Is there a know bug with the isapi_redirect.dll and CONTENT_LENGTH? Thanks- Joe This e-mail is confidential. If you are not the intended recipient,
FW: Problems with HTTPS Mutual authentication with big petitions
Nicolas- did you configure with JAAS? Are you using 5.5 TC?http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html#JAASRealm Saludos Martin __Disclaimer and confidentiality noteEverything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Date: Fri, 4 Jan 2008 16:52:31 -0500 From: [EMAIL PROTECTED] To: users@tomcat.apache.org Subject: Problems with HTTPS Mutual authentication with big petitions Hello, I'm running into problems when I try to configure tomcat to validate the client by its https cert with big requests. I'm using it with forms and when the send the form to the server with big (10-15Kbytes) requests it fails, but when I send small (90 bytes) requests it works. I have on the web.xml a security constrain: security-constraint web-resource-collection web-resource-nameMutual auth/web-resource-name url-pattern/page1.htm/url-pattern url-pattern/page2.htm/url-pattern /web-resource-collection auth-constraint role-nameclientHttpsRole/role-name /auth-constraint user-data-constraint transport-guarantee CONFIDENTIAL /transport-guarantee /user-data-constraint /security-constraint login-config auth-methodCLIENT-CERT/auth-method /login-config security-role role-nameclientHttpsRole/role-name /security-role and I created the user: user username=CN=WHATEVER password=null roles=clientHttpsRole/ Here is the snip with the https connector of the server.xml: Connector port=8443 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 debug=0 scheme=https secure=true clientAuth=false sslProtocol=TLS keystoreType=JKS keystoreFile=keystore keystorePass=password truststoreFile=keystore truststorePass=password/ What makes me worry is that it works fine when I set the https connector with clientAuth=true. -- Atentamente, Nicolás Velásquez O. Bogotá, Colombia (^) ASCII Ribbon Campaign X NO HTML/RTF in e-mail / \ NO Word docs in e-mail - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Watch “Cause Effect,” a show about real people making a real difference. Learn more _ Put your friends on the big screen with Windows Vista® + Windows Live™. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008
Re: Content_Length Problem
There's no Content-Length coming from the backend. See below. So: are you sure the backend sends it, if you send the same request without a web server in front of Tomcat? I would expect, that it's also missing, if you contact Tomcat directly via httpd. In this case it's an error in the webapp. Woytasik Joe schrieb: Here is my log, let me know if you see anything. Sending the request to the backend... [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): sending to ajp13 pos=4 len=501 max=8192 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): 12 34 01 F1 02 04 00 08 48 54 54 50 2F 31 2E 31 - .4..HTTP/1.1 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): 001000 00 14 2F 62 63 2F 42 69 6C 6C 69 6E 67 43 65 - .../xx/ ... [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): 01f036 38 36 00 FF 00 00 00 00 00 00 00 00 00 00 00 - 686. Since it's a POSt request, we also need to send the request body to the backend ... [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (1261): request body to send 670 - request body to resend 0 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): sending to ajp13 pos=4 len=676 max=8192 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): 12 34 02 A0 02 9E 54 61 62 42 61 72 25 33 41 50 - .4TabBar%3AP ... [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (892): 02a044 61 79 73 00 00 00 00 00 00 00 00 00 00 00 00 - Days The next log line tells us, that we already got an answer back: [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (1028): received from ajp13 pos=0 len=167 max=8192 Here comes the dump of the headers of the answers. If I decode the packet with the protocol specification, I get the same result, as what is printed out in clear text below: Packet dump: [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (1028): 04 00 C8 00 02 4F 4B 00 00 05 00 0D 43 61 63 68 - .OK.Cach ... [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (1028): 00a03D 55 54 46 2D 38 00 00 00 00 00 00 00 00 00 00 - =UTF-8.. Clear text: [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (602): status = 200 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (609): Number of headers is = 5 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (665): Header[0] [Cache-Control] = [no-cache] [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (665): Header[1] [Set-Cookie] = [rcou=87] [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (665): Header[2] [Pragma] = [no-cache] [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (665): Header[3] [Expires] = [Thu, 01 Jan 1970 00:00:00 GMT] [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (665): Header[4] [Content-Type] = [text/html;charset=UTF-8] And now we get the response body. Content-Length would have come before, but the response from the backend isn't chunked either. For an answer including Content-Length see below. [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (1028): received from ajp13 pos=0 len=8188 max=8192 [Fri Jan 04 14:11:48 2008] [8372:11108] [debug] jk_ajp_common.c (1028): 03 1F F8 3C 68 74 6D 6C 3E 0D 0A 3C 68 65 61 64 - ...html..head ... Now the next request is for a JavaScript file, and that request gets a response (404 error page), which includes a Content-Length: [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_isapi_plugin.c (852): Virtual Host redirection of /xx.xxX.com/xx/resources/javascript/smoketest/SmokeTest.js ... [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (1028): received from ajp13 pos=0 len=120 max=8192 [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (1028): 04 01 94 00 2F 2F 62 63 2F 72 65 73 6F 75 72 63 - //xx/resourc ... [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (1028): 007000 00 04 31 30 39 33 00 00 00 00 00 00 00 00 00 - ...1093. [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (602): status = 404 [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (609): Number of headers is = 2 [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (665): Header[0] [Content-Type] = [text/html;charset=utf-8] This is fine and is missing for the first request. [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (665): Header[1] [Content-Length] = [1093] [Fri Jan 04 14:11:49 2008] [8372:12224] [debug] jk_ajp_common.c (1028): received from ajp13 pos=0 len=1097 max=8192 Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To
Re: Problems with HTTPS Mutual authentication with big petitions
Nicolás Velásquez O. wrote: Hello, I'm running into problems when I try to configure tomcat to validate the client by its https cert with big requests. I'm using it with forms and when the send the form to the server with big (10-15Kbytes) requests it fails, but when I send small (90 bytes) requests it works. Try changing maxSavePostSize. See http://tomcat.apache.org/tomcat-6.0-doc/config/http.html The default is 4K which would explain what you are seeing. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_jk 1.2.26
On Fri, 2008-01-04 at 17:51 -0500, Martin Gainty wrote: Scottcan you confirm these JKMount directives in $APACHE_HOME/conf/httpd.conf # send all requests ending in .jsp to ajp13JkMount /*.jsp ajp13 # send all requests ending /servlet to ajp13JkMount /*/servlet/ ajp13 ThanksMartin __Disclaimer and confidentiality noteEverything in this e-mail and any attachments relates to the official business of Sender. This transmission is of a confidential nature and Sender does not endorse distribution to any party other than intended recipient. Sender does not necessarily endorse content contained within this transmission. Subject: mod_jk 1.2.26 From: [EMAIL PROTECTED] To: users@tomcat.apache.org Date: Fri, 4 Jan 2008 17:42:01 -0500 I'm getting 404 errors when I try to access the jkmanager page. There is only one backend tomcat instance and no load balancing configuration at all. I was just wanting to see the UI and if it had changed at all with the upgrade. Do you now get 404's if you don't have a load balancing configuration? Maybe I've done something wrong but the config looks the same. I can post the config if it's not something more obvious with the update. Thanks -- --- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Get the power of Windows + Web with the new Windows Live. http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008 Nevermind it has nothing to do with the status worker. I've just upgraded to apache 2.2 and mod_jk 1.2.26 and it seems that there is some inheritance logic in the JkMounts between virtual hosts. I see the very well documented section about JkMountCopy now. Sorry for the noise. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.26
Hi Scott, Scott McClanahan schrieb: I'm getting 404 errors when I try to access the jkmanager page. There is only one backend tomcat instance and no load balancing configuration at all. I was just wanting to see the UI and if it had changed at all with the upgrade. Do you now get 404's if you don't have a load balancing configuration? Maybe I've done something wrong but the config looks the same. I can post the config if it's not something more obvious with the update. Thanks No, no change like this (although you didn't tell us how old your previous version was). How does your config look like? Are you talking to the same virtual host, in which you did include your jkmanager JkMount? Although you should get it working, concerning changes in the UI: only one change, when using Apache httpd one can now see the JkMounts from all vhosts in the status worker display, independent of the vhost the status worker runs in. Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with HTTPS Mutual authentication with big petitions
Thanx, maxSavePostSize did the job. Mark Thomas wrote: Nicolás Velásquez O. wrote: Hello, I'm running into problems when I try to configure tomcat to validate the client by its https cert with big requests. I'm using it with forms and when the send the form to the server with big (10-15Kbytes) requests it fails, but when I send small (90 bytes) requests it works. Try changing maxSavePostSize. See http://tomcat.apache.org/tomcat-6.0-doc/config/http.html The default is 4K which would explain what you are seeing. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Atentamente, Nicolás Velásquez O. Bogotá, Colombia (^) ASCII Ribbon Campaign XNO HTML/RTF in e-mail / \ NO Word docs in e-mail - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
org.apache.commons.digester.Digester endElement (Q A)
if you find exceptions looking like this: ~ org.apache.commons.digester.Digester endElement SEVERE: End event threw exception java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.commons.beanutils.MethodUtils.invokeMethod(MethodUtils.java:216) at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:217) at org.apache.commons.digester.Rule.end(Rule.java:253) at org.apache.commons.digester.Digester.endElement(Digester.java:1222) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) . . . ~ it means what is says ;-) ~ but what I think is wrong is that TC conf parsers apparently attempt to parse into the comments so that if you have some not well-formed xml inside the comments, such as: ~ !-- Context configuration file for the Tomcat Administration Web App $Id: admin.xml 288428 2002-07-23 12:12:15Z remm $ W Box at Work: Context docBase=C:\cmllpz\prjx\java\GWB\tc\tc-4.1.36\server\webapps\admin Logger directory=C:\cmllpz\prjx\java\GWB\logs -- ~ they would pick it up ~ I was using TC 4.1.36 but I think this is a bug. After being fed a start comment, !--, sequence parsers should not attempt to resume parsing till they fully get an ending, --, one ~ Or? ~ lbrtchx - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
