DO NOT REPLY [Bug 35196] - ServletContextListener contextInitialized called twice during startup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=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]

DO NOT REPLY [Bug 35196] - ServletContextListener contextInitialized called twice during startup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35196





--- Additional Comments From [EMAIL PROTECTED]  2005-06-03 05:59 ---
Created an attachment (id=15280)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=15280&action=view)
Cataling Log Output

My Error I have two  inside  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] New: - ServletContextListener contextInitialized called twice during startup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=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]

Re: Graceful restart on Windows [was Re: Adding working dynamically with mod_jk status?]

[David Rees]

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]

Tomcat 5.x client SSL and CRL

[Atul]

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]

Something new for me.. Can anyone identify ?

[nitin dubey]

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]

help for ClassNotFoundException

[MEHMOOD, QAISER]

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.

Re: Initial apr results

[Peter Lin]

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

Re: Initial apr results

[Bill Barker]

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

cvs commit: jakarta-tomcat-connectors/jni/native/src sslcontext.c sslutils.c

[mturk]

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_print

DO NOT REPLY [Bug 35169] - pageContext not available within tag

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=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]

Re: Initial apr results

[Tim Funk]

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]

cvs commit: jakarta-tomcat-connectors/jni/native/src sslcontext.c

[mturk]

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
  + * 
  + * 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.
  + * 
  + * 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
  + * setCACertificatePath), 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
  + * 
  + * 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.
  + * 
  + * The following levels are available for level:
  + * 
  + * 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
  + * 
  + * setCACertificatePath), 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 *);
  +
  +UNREFERENCED_STDARGS;
  +TCN_ASSERT(ctx != 0);

cvs commit: jakarta-tomcat-connectors/jni/native/src ssl.c sslcontext.c

[mturk]

mturk   2005/06/02 02:52:46

  Modified:jni/java/org/apache/tomcat/jni SSL.java SSLContext.java
   jni/native/src ssl.c sslcontext.c
  Log:
  Add functions for defining acceptable CA names.
  
  Revision  ChangesPath
  1.8   +3 -1  
jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/SSL.java
  
  Index: SSL.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jni/java/org/apache/tomcat/jni/SSL.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- SSL.java  1 Jun 2005 12:50:51 -   1.7
  +++ SSL.java  2 Jun 2005 09:52:45 -   1.8
  @@ -160,6 +160,8 @@
*If null the default file will be tested.
*The seed file is $RANDFILE if that environment variable is
*set, $HOME/.rnd otherwise.
  + *In case both files are unavailable builtin
  + *random seed generator is used.
*/
   public static native boolean randLoad(String filename);
   
  
  
  
  1.10  +56 -4 
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.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- SSLContext.java   2 Jun 2005 07:44:38 -   1.9
  +++ SSLContext.java   2 Jun 2005 09:52:46 -   1.10
  @@ -222,7 +222,8 @@
* preference. This can be used alternatively and/or additionally to
* setCACertificatePath.
* @param ctx Server or Client context to use.
  - * @param file File of concatenated PEM-encoded CA Certificates for 
Client Auth.
  + * @param file File of concatenated PEM-encoded CA Certificates for
  + * Client Auth.
*/
   public static native boolean setCACertificateFile(long ctx, String file);
   
  @@ -235,12 +236,63 @@
* 
* 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.
  + * 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 setCACertificatePath(long ctx, String path);
   
  +/**
  + * Set File of concatenated PEM-encoded CA Certificates for defining
  + * acceptable CA names
  + * 
  + * When a client certificate is requested by mod_ssl, a list of 
acceptable
  + * Certificate Authority names is sent to the client in the SSL 
handshake.
  + * These CA names can be used by the client to select an appropriate 
client
  + * certificate out of those it has available.
  + * 
  + * If neither of the directives setCADNRequestPath or
  + * setCADNRequestFile are given, then the set of acceptable
  + * CA names sent to the client is the names of all the CA certificates 
given
  + * by the setCACertificateFile and
  + * setCACertificatePath directives; in other words, the 
names
  + * of the CAs which will actually be used to verify the client 
certificate.
  + * 
  + * In some circumstances, it is useful to be able to send a set of 
acceptable
  + * CA names which differs from the actual CAs used to verify the client
  + * certificate - for example, if the client certificates are signed by
  + * intermediate CAs. In such cases, CADNRequestPath and/or 
CADNRequestFile
  + * can be used; the acceptable CA names are then taken from the complete
  + * set of certificates in the directory and/or file specified by
  + * this pair of directives.
  + * 
  + * setCADNRequestFile must specify an all-in-one file containing a
  + * concatenation of PEM-encoded CA certificates.
  + * @param ctx Server or Client context to use.
  + * @param file File of concatenated PEM-encoded CA Certificates for 
defining
  + * acceptable CA names.
  + */
  +public static native boolean setCADNRequestFile(long ctx, String file);
  +
  +/**
  + * Set Directory of PEM-encoded CA Certificates for defining acceptable
  + * CA names
  + * 
  + * This optional directive can be used to specify the set of acceptable
  + * CA names which will be sent to the client when a client certificate is
  + * requeste

Re: Summer of code

[Remy Maucherat]

Tim Funk wrote:
A killer feature would be extending the balancer to be a HTTP reverse 
proxy.


Then tomcat could be a reverse proxy to other tomcats (or any other 
webserver) if needed.


I have a (very simple) reverse proxy filter available that if my 
employer allows it - I could release. It catches some of the edge cases 
like Content-length=0 with more headers available and other such cases.


I think there should be proposals, like this one which seems good, then 
have a vote on all these.


Please be quick for the proposals as there's a deadline, apparently, so 
I'd say this needs to be wrapped up and the wiki edited by the end of 
next week.


Rémy

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

DO NOT REPLY [Bug 33650] - Jasper performance for multiple files processing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33650





--- Additional Comments From [EMAIL PROTECTED]  2005-06-02 09:53 ---
I have changed the summer project to a more general "optimizing JSP compilation
performance", as hopefully not all optimizations are going to be about caching
stuff.

-- 
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 ssl.c sslcontext.c sslutils.c

[mturk]

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.
  + * 
  + * 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
  + * 
  + * 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.
  + * 
  + * 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
  + * 
  + * 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 setCARevocationPath.
  + * @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
  + * 
  + * 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.
  + * 
  + * 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
  + * 
  + * Point setCertificateFile at a PEM encoded certificate.  If
  + * the certificate is encrypted, then you will be prompted for a
  + * pass phrase.  Note that a kill -HUP will prompt again. A