Re: Initial apr results
Tim Funk wrote: My test box was an HP-UX 9000/800/L1000-44 - Dual CPU (440 MHz) On my initial tests with the APR connector - the APR connector seemed slower the old http connector. But the difference is mild and my initial numbers are flaky. On the same hardware - I am running 6 other instances (of different versions) of tomcat at the same time which may be throwing my numbers off. During some slow time - I might be able to take most of them down and run some more tests to try to ensure I am hogging all the resources to the box and not sharing them. For those curious - for /tomcat.gif - my requests per second range anywhere from 1200+ to 5000+ - Due to such a large range - I have no confidence in my numbers so far to reach any conclusion. I was using the command: /usr/local/httpd/bin/ab -n 1000 -c 100 -k http://myserver:8090/tomcat.gif With keepalive off - I was still easily over 1000 requests per second for tomcat.gif. I can't assert yet that there are no bugs at the moment (performance or otherwise). So far, performance seems good on Windows, and Linux. To give a comparison on Windows with this test, APR HTTP is within 5% of regular HTTP, and gets closer depending on the JVM (I suppose if it's better at JNI - I've noticed slightly better results with Sun JDK 1.5 Server compared to 1.4.2 client). I think you should use -n 2 at least: if the test duration is too small, ab is going to produce random results. In this test, increasing concurrency isn't particularly useful either. Obviously, the results of this kind of testing are not really important as long as the results stay relatively close (for example, I think the -25% result I got when using polling exclusively was really good). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c sslutils.c
mturk 2005/06/02 00:44:39 Modified:jni/java/org/apache/tomcat/jni SSLContext.java jni/native/include ssl_private.h jni/native/src ssl.c sslcontext.c sslutils.c Log: Add more configuration directives to SSL Context. Revision ChangesPath 1.9 +126 -1 jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/SSLContext.java Index: SSLContext.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/SSLContext.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- SSLContext.java 1 Jun 2005 12:36:24 - 1.8 +++ SSLContext.java 2 Jun 2005 07:44:38 - 1.9 @@ -118,4 +118,129 @@ */ public static native void setQuietShutdown(long ctx, boolean mode); +/** + * Cipher Suite available for negotiation in SSL handshake. + * br / + * This complex directive uses a colon-separated cipher-spec string consisting + * of OpenSSL cipher specifications to configure the Cipher Suite the client + * is permitted to negotiate in the SSL handshake phase. Notice that this + * directive can be used both in per-server and per-directory context. + * In per-server context it applies to the standard SSL handshake when a + * connection is established. In per-directory context it forces a SSL + * renegotation with the reconfigured Cipher Suite after the HTTP request + * was read but before the HTTP response is sent. + * @param ctx Server or Client context to use. + * @param ciphers An SSL cipher specification. + */ +public static native boolean setCipherSuite(long ctx, String ciphers); + +/** + * Set Directory of PEM-encoded CA Certificates for Client Auth + * br / + * This directive sets the directory where you keep the Certificates of + * Certification Authorities (CAs) whose clients you deal with. These are + * used to verify the client certificate on Client Authentication. + * br / + * The files in this directory have to be PEM-encoded and are accessed through + * hash filenames. So usually you can't just place the Certificate files there: + * you also have to create symbolic links named hash-value.N. And you should + * always make sure this directory contains the appropriate symbolic links. + * Use the Makefile which comes with mod_ssl to accomplish this task. + * @param ctx Server or Client context to use. + * @param path Directory of PEM-encoded CA Certificates for Client Auth. + */ +public static native boolean setCARevocationPath(long ctx, String path); + +/** + * Set File of concatenated PEM-encoded CA CRLs for Client Auth + * br / + * This directive sets the all-in-one file where you can assemble the + * Certificate Revocation Lists (CRL) of Certification Authorities (CA) + * whose clients you deal with. These are used for Client Authentication. + * Such a file is simply the concatenation of the various PEM-encoded CRL + * files, in order of preference. This can be used alternatively and/or + * additionally to codesetCARevocationPath/code. + * @param ctx Server or Client context to use. + * @param file File of concatenated PEM-encoded CA CRLs for Client Auth. + */ +public static native boolean setCARevocationFile(long ctx, String file); + +/** + * Set File of PEM-encoded Server CA Certificates + * br / + * This directive sets the optional all-in-one file where you can assemble the + * certificates of Certification Authorities (CA) which form the certificate + * chain of the server certificate. This starts with the issuing CA certificate + * of of the server certificate and can range up to the root CA certificate. + * Such a file is simply the concatenation of the various PEM-encoded CA + * Certificate files, usually in certificate chain order. + * br / + * But be careful: Providing the certificate chain works only if you are using + * a single (either RSA or DSA) based server certificate. If you are using a + * coupled RSA+DSA certificate pair, this will work only if actually both + * certificates use the same certificate chain. Else the browsers will be + * confused in this situation. + * @param ctx Server or Client context to use. + * @param file File of PEM-encoded Server CA Certificates. + */ +public static native boolean setCertificateChainFile(long ctx, String file); + +/** + * Set Server Certificate + * br / + * Point setCertificateFile at a PEM encoded certificate. If + * the certificate is encrypted, then you will be prompted for a + * pass phrase. Note
cvs commit: jakarta-tomcat-connectors/jni/native/src sslcontext.c
mturk 2005/06/02 03:19:32
Modified:jni/java/org/apache/tomcat/jni SSLContext.java
jni/native/src sslcontext.c
Log:
Add functions for Certificate verification level and depth
for the Client Authentication.
Revision ChangesPath
1.11 +50 -1
jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/SSLContext.java
Index: SSLContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/SSLContext.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- SSLContext.java 2 Jun 2005 09:52:46 - 1.10
+++ SSLContext.java 2 Jun 2005 10:19:32 - 1.11
@@ -295,4 +295,53 @@
*/
public static native boolean setCADNRequestPath(long ctx, String path);
+/**
+ * Set Maximum depth of CA Certificates in Client Certificate
verification
+ * br /
+ * This directive sets how deeply mod_ssl should verify before deciding
that
+ * the clients don't have a valid certificate. Notice that this
directive can
+ * be used both in per-server and per-directory context. In per-server
context
+ * it applies to the client authentication process used in the standard
SSL
+ * handshake when a connection is established. In per-directory context
it forces
+ * a SSL renegotation with the reconfigured client verification depth
after the
+ * HTTP request was read but before the HTTP response is sent.
+ * br /
+ * The depth actually is the maximum number of intermediate certificate
issuers,
+ * i.e. the number of CA certificates which are max allowed to be
followed while
+ * verifying the client certificate. A depth of 0 means that self-signed
client
+ * certificates are accepted only, the default depth of 1 means the
client
+ * certificate can be self-signed or has to be signed by a CA which is
directly
+ * known to the server (i.e. the CA's certificate is under
+ * codesetCACertificatePath/code), etc.
+ * @param ctx Server or Client context to use.
+ * @param depth Maximum depth of CA Certificates in Client Certificate
+ * verification.
+ */
+public static native void setVerifyDepth(long ctx, int depth);
+
+/**
+ * Set Type of Client Certificate verification
+ * br /
+ * This directive sets the Certificate verification level for the Client
+ * Authentication. Notice that this directive can be used both in
per-server
+ * and per-directory context. In per-server context it applies to the
client
+ * authentication process used in the standard SSL handshake when a
connection
+ * is established. In per-directory context it forces a SSL renegotation
with
+ * the reconfigured client verification level after the HTTP request was
read
+ * but before the HTTP response is sent.
+ * br /
+ * The following levels are available for level:
+ * PRE
+ * SSL_CVERIFY_NONE - No client Certificate is required at all
+ * SSL_CVERIFY_OPTIONAL - The client may present a valid
Certificate
+ * SSL_CVERIFY_REQUIRE- The client has to present a valid
Certificate
+ * SSL_CVERIFY_OPTIONAL_NO_CA - The client may present a valid
Certificate
+ * but it need not to be (successfully)
verifiable
+ * /PRE
+ * codesetCACertificatePath/code), etc.
+ * @param ctx Server or Client context to use.
+ * @param level Type of Client Certificate verification.
+ */
+public static native boolean setVerifyClient(long ctx, int level);
+
}
1.17 +29 -2 jakarta-tomcat-connectors/jni/native/src/sslcontext.c
Index: sslcontext.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/sslcontext.c,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- sslcontext.c 2 Jun 2005 09:52:46 - 1.16
+++ sslcontext.c 2 Jun 2005 10:19:32 - 1.17
@@ -183,7 +183,12 @@
SSL_CTX_set_tmp_rsa_callback(c-ctx, SSL_callback_tmp_RSA);
SSL_CTX_set_tmp_dh_callback(c-ctx, SSL_callback_tmp_DH);
-
+
+/* Set default Certificate verification level
+ * and depth for the Client Authentication
+ */
+c-verify_depth = 1;
+c-verify_mode = SSL_CVERIFY_UNSET;
/*
* Let us cleanup the ssl context when the pool is destroyed
*/
@@ -546,6 +551,28 @@
return rv;
}
+TCN_IMPLEMENT_CALL(void, SSLContext, setVerifyDepth)(TCN_STDARGS, jlong ctx,
+ jint depth)
+{
+tcn_ssl_ctxt_t *c = J2P(ctx, tcn_ssl_ctxt_t *);
+
+
Re: Initial apr results
Excellent. In my future tests, I'll keep the concurrency lower and the hits higher. I'll also use different size files. I am only able to use a 1.4.2 JVM. I might be able to get 1.5 on - but its highly doubtful. -Tim Remy Maucherat wrote: Tim Funk wrote: My test box was an HP-UX 9000/800/L1000-44 - Dual CPU (440 MHz) On my initial tests with the APR connector - the APR connector seemed slower the old http connector. But the difference is mild and my initial numbers are flaky. On the same hardware - I am running 6 other instances (of different versions) of tomcat at the same time which may be throwing my numbers off. During some slow time - I might be able to take most of them down and run some more tests to try to ensure I am hogging all the resources to the box and not sharing them. For those curious - for /tomcat.gif - my requests per second range anywhere from 1200+ to 5000+ - Due to such a large range - I have no confidence in my numbers so far to reach any conclusion. I was using the command: /usr/local/httpd/bin/ab -n 1000 -c 100 -k http://myserver:8090/tomcat.gif With keepalive off - I was still easily over 1000 requests per second for tomcat.gif. I can't assert yet that there are no bugs at the moment (performance or otherwise). So far, performance seems good on Windows, and Linux. To give a comparison on Windows with this test, APR HTTP is within 5% of regular HTTP, and gets closer depending on the JVM (I suppose if it's better at JNI - I've noticed slightly better results with Sun JDK 1.5 Server compared to 1.4.2 client). I think you should use -n 2 at least: if the test duration is too small, ab is going to produce random results. In this test, increasing concurrency isn't particularly useful either. Obviously, the results of this kind of testing are not really important as long as the results stay relatively close (for example, I think the -25% result I got when using polling exclusively was really good). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35169] - pageContext not available within tag
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35169. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35169 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-06-02 12:43 --- When using tag files, the implicit variable to use is jspContext, not pageContext. See the JSP spec (Table JSP.8-5 Implicit Objects Available in Tag Files) for more details. (or tomcat-user) -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jni/native/src sslcontext.c sslutils.c
mturk 2005/06/02 04:07:07
Modified:jni/native/include ssl_private.h
jni/native/src sslcontext.c sslutils.c
Log:
Implement Client Authentication verify callback and CA initialization.
Revision ChangesPath
1.11 +12 -1
jakarta-tomcat-connectors/jni/native/include/ssl_private.h
Index: ssl_private.h
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jni/native/include/ssl_private.h,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ssl_private.h 2 Jun 2005 07:44:38 - 1.10
+++ ssl_private.h 2 Jun 2005 11:07:06 - 1.11
@@ -88,6 +88,14 @@
#define SSL_DEFAULT_CACHE_SIZE (256)
#define SSL_DEFAULT_VHOST_NAME (_default_:443)
#define SSL_MAX_STR_LEN 2048
+
+#define SSL_CVERIFY_UNSET (-1)
+#define SSL_CVERIFY_NONE(0)
+#define SSL_CVERIFY_OPTIONAL(1)
+#define SSL_CVERIFY_REQUIRE (2)
+#define SSL_CVERIFY_OPTIONAL_NO_CA (3)
+#define SSL_VERIFY_PEER_STRICT
(SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT)
+
/* public cert/private key */
typedef struct {
/*
@@ -167,5 +175,8 @@
RSA*SSL_callback_tmp_RSA(SSL *, int, int);
DH *SSL_callback_tmp_DH(SSL *, int, int);
voidSSL_vhost_algo_id(const unsigned char *, unsigned char *, int);
+int SSL_callback_SSL_verify(int, X509_STORE_CTX *);
+STACK_OF(X509_NAME)
+*SSL_init_findCAList(tcn_ssl_ctxt_t *, const char *, const char
*);
#endif /* SSL_PRIVATE_H */
1.18 +66 -4 jakarta-tomcat-connectors/jni/native/src/sslcontext.c
Index: sslcontext.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jni/native/src/sslcontext.c,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- sslcontext.c 2 Jun 2005 10:19:32 - 1.17
+++ sslcontext.c 2 Jun 2005 11:07:06 - 1.18
@@ -183,8 +183,8 @@
SSL_CTX_set_tmp_rsa_callback(c-ctx, SSL_callback_tmp_RSA);
SSL_CTX_set_tmp_dh_callback(c-ctx, SSL_callback_tmp_DH);
-
-/* Set default Certificate verification level
+
+/* Set default Certificate verification level
* and depth for the Client Authentication
*/
c-verify_depth = 1;
@@ -565,11 +565,73 @@
jint level)
{
tcn_ssl_ctxt_t *c = J2P(ctx, tcn_ssl_ctxt_t *);
+int verify = SSL_VERIFY_NONE;
+STACK_OF(X509_NAME) *ca_list;
UNREFERENCED_STDARGS;
TCN_ASSERT(ctx != 0);
c-verify_mode = level;
-/* TODO: Add verification code callback */
+
+if (c-verify_mode == SSL_CVERIFY_UNSET)
+c-verify_mode = SSL_CVERIFY_NONE;
+
+/*
+ * Configure callbacks for SSL context
+ */
+if (c-verify_mode == SSL_CVERIFY_REQUIRE)
+verify |= SSL_VERIFY_PEER_STRICT;
+if ((c-verify_mode == SSL_CVERIFY_OPTIONAL) ||
+(c-verify_mode == SSL_CVERIFY_OPTIONAL_NO_CA))
+verify |= SSL_VERIFY_PEER;
+
+SSL_CTX_set_verify(c-ctx, verify, SSL_callback_SSL_verify);
+ /*
+ * Configure Client Authentication details
+ */
+if (c-ca_cert_file || c-ca_cert_path) {
+if (!SSL_CTX_load_verify_locations(c-ctx,
+ c-ca_cert_file,
+ c-ca_cert_path)) {
+BIO_printf(c-bio_os, [ERROR]
+ Unable to configure verify locations
+ for client authentication);
+return JNI_FALSE;
+}
+
+if (c-mode (c-pk.s.ca_name_file || c-pk.s.ca_name_path)) {
+ca_list = SSL_init_findCAList(c,
+ c-pk.s.ca_name_file,
+ c-pk.s.ca_name_path);
+}
+else {
+ca_list = SSL_init_findCAList(c,
+ c-ca_cert_file,
+ c-ca_cert_path);
+}
+if (!ca_list) {
+BIO_printf(c-bio_os, [ERROR]
+ Unable to determine list of acceptable
+ CA certificates for client authentication);
+return JNI_FALSE;
+}
+SSL_CTX_set_client_CA_list(c-ctx, (STACK *)ca_list);
+}
+
+/*
+ * Give a warning when no CAs were configured but client authentication
+ * should take place. This cannot work.
+ */
+if (c-verify_mode == SSL_CVERIFY_REQUIRE) {
+ca_list = (STACK_OF(X509_NAME) *)SSL_CTX_get_client_CA_list(c-ctx);
+
+if (sk_X509_NAME_num(ca_list) == 0) {
+BIO_printf(c-bio_os,
+
Re: Initial apr results
You might also want to dig up Peter's JMeter test plan. This one is the opposite of the 'ab' test, in that it tests the ability to handle a lot of socket connections without necessarily much throughput. As Remy said, the 'ab -k' tests should be close unless either your JVM vendor or your APR implementation s*cks. Both connectors do much the same thing with this test execpt for sendfile (and 'tomcat.gif' is too small to for Tomcat to use sendfile by default). - Original Message - From: Tim Funk [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, June 02, 2005 3:41 AM Subject: Re: Initial apr results Excellent. In my future tests, I'll keep the concurrency lower and the hits higher. I'll also use different size files. I am only able to use a 1.4.2 JVM. I might be able to get 1.5 on - but its highly doubtful. -Tim Remy Maucherat wrote: Tim Funk wrote: My test box was an HP-UX 9000/800/L1000-44 - Dual CPU (440 MHz) On my initial tests with the APR connector - the APR connector seemed slower the old http connector. But the difference is mild and my initial numbers are flaky. On the same hardware - I am running 6 other instances (of different versions) of tomcat at the same time which may be throwing my numbers off. During some slow time - I might be able to take most of them down and run some more tests to try to ensure I am hogging all the resources to the box and not sharing them. For those curious - for /tomcat.gif - my requests per second range anywhere from 1200+ to 5000+ - Due to such a large range - I have no confidence in my numbers so far to reach any conclusion. I was using the command: /usr/local/httpd/bin/ab -n 1000 -c 100 -k http://myserver:8090/tomcat.gif With keepalive off - I was still easily over 1000 requests per second for tomcat.gif. I can't assert yet that there are no bugs at the moment (performance or otherwise). So far, performance seems good on Windows, and Linux. To give a comparison on Windows with this test, APR HTTP is within 5% of regular HTTP, and gets closer depending on the JVM (I suppose if it's better at JNI - I've noticed slightly better results with Sun JDK 1.5 Server compared to 1.4.2 client). I think you should use -n 2 at least: if the test duration is too small, ab is going to produce random results. In this test, increasing concurrency isn't particularly useful either. Obviously, the results of this kind of testing are not really important as long as the results stay relatively close (for example, I think the -25% result I got when using polling exclusively was really good). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Initial apr results
if you need the test plan Tim, email me and I'll send it to you :) peter On 6/2/05, Bill Barker [EMAIL PROTECTED] wrote: You might also want to dig up Peter's JMeter test plan. This one is the opposite of the 'ab' test, in that it tests the ability to handle a lot of socket connections without necessarily much throughput. As Remy said, the 'ab -k' tests should be close unless either your JVM vendor or your APR implementation s*cks. Both connectors do much the same thing with this test execpt for sendfile (and 'tomcat.gif' is too small to for Tomcat to use sendfile by default). - Original Message - From: Tim Funk [EMAIL PROTECTED] To: Tomcat Developers List tomcat-dev@jakarta.apache.org Sent: Thursday, June 02, 2005 3:41 AM Subject: Re: Initial apr results Excellent. In my future tests, I'll keep the concurrency lower and the hits higher. I'll also use different size files. I am only able to use a 1.4.2 JVM. I might be able to get 1.5 on - but its highly doubtful. -Tim Remy Maucherat wrote: Tim Funk wrote: My test box was an HP-UX 9000/800/L1000-44 - Dual CPU (440 MHz) On my initial tests with the APR connector - the APR connector seemed slower the old http connector. But the difference is mild and my initial numbers are flaky. On the same hardware - I am running 6 other instances (of different versions) of tomcat at the same time which may be throwing my numbers off. During some slow time - I might be able to take most of them down and run some more tests to try to ensure I am hogging all the resources to the box and not sharing them. For those curious - for /tomcat.gif - my requests per second range anywhere from 1200+ to 5000+ - Due to such a large range - I have no confidence in my numbers so far to reach any conclusion. I was using the command: /usr/local/httpd/bin/ab -n 1000 -c 100 -k http://myserver:8090/tomcat.gif With keepalive off - I was still easily over 1000 requests per second for tomcat.gif. I can't assert yet that there are no bugs at the moment (performance or otherwise). So far, performance seems good on Windows, and Linux. To give a comparison on Windows with this test, APR HTTP is within 5% of regular HTTP, and gets closer depending on the JVM (I suppose if it's better at JNI - I've noticed slightly better results with Sun JDK 1.5 Server compared to 1.4.2 client). I think you should use -n 2 at least: if the test duration is too small, ab is going to produce random results. In this test, increasing concurrency isn't particularly useful either. Obviously, the results of this kind of testing are not really important as long as the results stay relatively close (for example, I think the -25% result I got when using polling exclusively was really good). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
help for ClassNotFoundException
Hi , Under tomcat I am integrating the uPortal and running one portlet application in a web context. I put my own classes under the WEB-INF/classes directory and also put jar files in WEB-INF/lib directory , but I am getting the error : ClassNotFoundException , When I put these jar files in tomcat/common/lib directory , its working fine. Can anyone tell me That how and where I can specify for a web application under one context that where are the jar And class files.
Something new for me.. Can anyone identify ?
Hello,
From a servlet deployed in tomcat I am getting the
request parameter map by calling getParameterMap()
then using reflection calling a Class say Sub that
has a method construct(HashMap requestMap). The
method is called properly but surprisingly I am
getting InvocationTargetException-ClassCastException
when I try to read the parameter from the map.
Following is the code.
Code in Class called from Servlet
// Note that the map instance is an instance of
org.apache.catalina.util.ParameterMap
Method method = cls.getMethod(constructSql, new
Class[]{request.getParameterMap().getClass().getSuperclass()});
query = (String) method.invoke(obj, new
Object[]{request.getParameterMap()});
Code from Sub
public String construct(HashMap requestMap) {
log.info(~construct());
log.info(10);
Object obj = requestMap.get(ParamKey);
log.info(obj.getClass());
log.info(10.1);
String str = (String) obj;
log.info(str);
log.info(10.2);
return ;
}
Console Output ==
INFO [http-8080-Processor25] SearchCodeQuery -
~construct()
INFO [http-8080-Processor25] SearchCodeQuery - 10
INFO [http-8080-Processor25] SearchCodeQuery -
class [Ljava.lang.String;
INFO [http-8080-Processor25] SearchCodeQuery -
10.1
INFO [http-8080-Processor25] ServletRequestProcessor
- java.lang.reflect.InvocationTargetException
INFO [http-8080-Processor25] ServletRequestProcessor
- java.lang.ClassCastException: [Ljava.lang.String;
Is it because that the instance is actually
org.apache.catalina.util.ParameterMap and I am trying
to call get() over that instance ? But ParameterMap
itself does not have any implementation of get() it
takes that from its superclass i.e. HashMap.
Is it not supposed to run. When you can see in the
log that the value is a String object and a similar
java application using LinkedHashMap and HashMap runs
without any hiccups ?
I am using JDK:1.5.0_03, Tomcat:5.5.9
Thanks in advance
Nitin
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 5.x client SSL and CRL
Hi, I was trying to get tomcat 5.x (standalone) setup for mutual ssl for (only some service URLs) with CRL/OCSP validations. If I write my own CRL validator, how can I tell tomcat to invoke it for such requests? I tried various docs, lists but couldn'tfind any pointers. Any pointers are appeciated. thx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Graceful restart on Windows [was Re: Adding working dynamically with mod_jk status?]
On 6/1/05, Bernard [EMAIL PROTECTED] wrote: I follow this sequence because mod_jk returns a server error if it cannot connect to Tomcat. To avoid this during Tomcat restarts, you need to have 2 Tomcat instances running and set them up with mod_jk to load balance across them. -Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35196] New: - ServletContextListener contextInitialized called twice during startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35196. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35196 Summary: ServletContextListener contextInitialized called twice during startup Product: Tomcat 5 Version: 5.5.9 Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] While I was trying to get to the bottom of why my webapp ServletContextListener class was working fine under standalone TOMCAT but getting an error under Eclipse WTP I seem to have uncovered that my contextInitialized() method is actually called twice. This does not seem like correct behaviour. If I startup, use; then shutdown tomcat my webapp handlers are called in this sequence: contextInitialized(); contextInitialized(); contextDestroyed(); The above relates to the bug I'm filing. Below is how I think it relates to another problem I am seeing (and other people seem to be having with integrated tomcat development with Eclipse WTP, check google for SEVERE: Error listenerStart and SEVERE: context [/webapp] startup failed due to previous errors with ClassNotFoundException) : I _*SUSPECT*_ the first contextInitialized() call is made from the server/outside-container executation context and therefore has the incorrect class loader in play. I believe this is the reason why my Eclipse WTP tomcat launches fail when any ServletContextListener is in use. For whatever reasons the classpaths and configuration Eclipse specifies seems tighter than the default one when $CATALINA_HOME == $CATALINA_BASE and is uncovering this problem. Eclipse WTP uses $CATALINA_BASE pointed to its mini-deployment directory. I _*SUSPECT*_ the 2nd call I see to run the handler is the proper time to do it, this being from inside the webapp/container executation context and therefore the correct class loader. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35196] - ServletContextListener contextInitialized called twice during startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35196. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35196 --- Additional Comments From [EMAIL PROTECTED] 2005-06-03 05:59 --- Created an attachment (id=15280) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=15280action=view) Cataling Log Output My Error I have two Host .../ inside Engine and my class is being instated for each one of those. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35196] - ServletContextListener contextInitialized called twice during startup
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35196. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35196 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
