Quoting [EMAIL PROTECTED]:
[snip]
So I'll be as -1 on adding this feature
( or CGI support, for this matter :-)
Damn! There goes my very next proposal =)
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
*
Pier Fumagalli wrote:
GOMEZ Henri [EMAIL PROTECTED] wrote:
I didn't agree with that Pier, we must try to keep compatibility
with previous release of Apache 2.0, since there IS STILL NO
official release.
Many users are still using Apache 2.0.24-alpha (including myself),
or even
Hi!
If I see correctly (after testing for it and browsing source extensively),
the 3.2 product line of Tomcat does not support the Digest authentication
scheme (RFC 2069). Could you confirm this? Also, please let me know if 3.3
or 4.0 support Digest.
In case they don't, I'm ready to provide an
Hi,
as we are in beta testing 3.3 (hope it's not too late) i got to hurry.
Well i do have problem with the JNI Connection (system) which was on
3.2.1
Main things :
JNIConnectionHandler include to classes:
JNIRequestAdapter
JNIResponseAdapter
so it's not possible for me to extend
no, Peter tells you that it is WORKING! Yep.
thanks,
pero
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 07, 2001 3:23 AM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader
jean-frederic clere [EMAIL PROTECTED] wrote:
I could stick with the last official tarball since that's an easy piece of
thing to download. So, if the latest version is 2.0.18 alpha (don't even
know since I use HEAD),
The is 2.0.25 (Thank STATUS!). 20010808 is a date...
I don't know about
Pier Fumagalli wrote:
jean-frederic clere [EMAIL PROTECTED] wrote:
I could stick with the last official tarball since that's an easy piece of
thing to download. So, if the latest version is 2.0.18 alpha (don't even
know since I use HEAD),
The is 2.0.25 (Thank STATUS!). 20010808 is
Thanks for the great info Costin.
Just an FYI, I did implement another solution, which was to implement a
Handler class for the jar protocol. Interestingly enough, it was
sufficient to only have a class that is responsible for the jar protocol.
The implementation of the class could be crap
On Thursday 06 September 2001 18:06, Justin Erenkrantz wrote:
On Fri, Sep 07, 2001 at 01:52:50AM +0100, Pier Fumagalli wrote:
Since there is no official release of httpd-2.0, I am confident that
nobody will actually care unless they're testing something... And by
testing good practice says
Thanks again James.
I think I understand now.
First question - what VM are you using ? JDK1.1.8 ( Sun and IBM ) seem to
have handlers for jar protocol ( even if it's not standard AFAIK ). Long
time ago I tested with kaffe and it worked - but I'm not sure I tested
getResource().
The real
On Fri, 7 Sep 2001, Thomas Colin de Verdiere wrote:
Main things :
JNIConnectionHandler include to classes:
JNIRequestAdapter
JNIResponseAdapter
so it's not possible for me to extend JNIConnectionHandler as i want to
modify
JNIRequest and Response Adapter.
Those reported bugs are in
I'm using IBM's JDK 1.1.8
I feel almost certain that it does not have a jar protocol handler.
I tried your suggestion but I still get the exception:
java.net.MalformedURLException: unknown protocol: jar
at java.lang.Throwable.init(Throwable.java:74)
at
Hi!
We're trying to use the encryption facilities included in the Sun JCE
extension. Everything
works fine when we try our application using the JDK1.3.1 alone. But
when we try it with
Tomcat, we get the next exception:
java.lang.ExceptionInInitializerError: java.lang.SecurityException: Cannot
Many users are still using Apache 2.0.24-alpha (including myself),
or even 2.0.18-beta (including IBM iSeries team porting Apache 2.0).
Ok, ok, I could understand your all developpers point of vue,
but let me say it appears just too elitist.
You just can't ask people (developpers or users)
costin wrote
In 3.3 we tried to make it easy to add modules ( and all the
functionality is implemented in modules ), it's just like adding a
webapplication. The idea is to reduce the pressure on the official
release, reduce the 'featurism', keep tomcat simple, etc.
That's also the general idea
Just wanted you to know: I've done with implementing Digest authentication
in Tomcat 3.2.1 code, will incorporate it into current 3.2.x latest code
from CVS. The funny thing is that so-called "mainstream" browsers (IE and
NN; tried many versions this afternoon) DO NOT support the Digest
Just wanted you to know: I've done with implementing Digest authentication
in Tomcat 3.2.1 code, will incorporate it into current 3.2.x latest code
from CVS. The funny thing is that so-called mainstream browsers (IE and
NN; tried many versions this afternoon) DO NOT support the Digest
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: 2001. szeptember 7. 18:13
Subject: Re: Digest authentication in Tomcat?
Tomcat 4.0 already supports DIGEST, but only if the realm can return clear
text passwords. Designing a cheme to store the
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: 2001. szeptember 7. 17:38
Subject: Re: Digest authentication in Tomcat?
In 3.3 we tried to make it easy to add modules ( and all the
functionality is implemented in modules ), it's just like adding a
On Fri, 7 Sep 2001, Remy Maucherat wrote:
Date: Fri, 7 Sep 2001 09:13:29 -0700
From: Remy Maucherat [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: Digest authentication in Tomcat?
Just wanted you to know: I've done with implementing Digest
Tomcat 4.0 already supports DIGEST, but only if the realm can return
clear
text passwords. Designing a cheme to store the limited digest in the
realmshould be possible, but should be postponed until 4.1.
My implementation works with the situation where server only knows
H(username :
craigmcc01/09/07 09:53:28
Modified:src/doc/appdev Tag: tomcat_32 contents.html
Log:
Update address to reflect our office move.
Revision ChangesPath
No revision
No revision
1.2.4.1 +1 -1
i'm not very to the latest news
my objectives is to run Tomcat under IIS and to access to
RequestAdapter and ResponseAdapter.
This for modifiying log particularly processConnection (all the native
methods are written in).
This was not possible under Tomcat 3.2.1
is this possible under Tomcat
no, Peter tells you that it is WORKING! Yep.
Way COOL ! It's great, because it would have been bad to sync anywhere on
the critical path (since findResourceInternal is called quite often). The
updated code doesn't hurt performance in any significant way (it strenghtens
a bit one sync, and makes
This patch is in reference to Bugzilla Bug 3474.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3474
--
cvs diff -u messages.properties (in directory D:\Tomcat4-cvs\jakarta-tomcat-4.0
craigmcc01/09/07 10:57:46
Modified:jasper/src/share/org/apache/jasper JspC.java
jasper/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
Log:
Update web.xml fragments generated by jspc command line compiler to
This patch fixes the following bug reports. Testing on Windows 2000 w/ SP2, JDK 1.3.1,
and jakarta-tomcat-4.0-20010906.
web.xml file generated by JspC is not valid as defined by DTD.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3474
Invalid url-pattern for servlet-mapping in web.xml file
Great minds think alike :-). I just committed exactly this fix, plus your
fix for the generated DOCTYPE heading. Thanks!
Craig
On Fri, 7 Sep 2001, Blakeslee, Todd wrote:
Date: Fri, 7 Sep 2001 14:02:53 -0400
From: Blakeslee, Todd [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: '[EMAIL
On Fri, 7 Sep 2001, GOMEZ Henri wrote:
Don't forget that many of us must evaluate
a KNOWN Apache 2.0 in real environnement.
The most known are Apache sites which use the released
version 2.0.24 :)
We could do that a each release (2.0.24/2.0.25) but
not in real-time ;)
Probably the
Does anyone have any objections to my modifying the realm authentication
classes so that hex digests are forced to uppercase for comparison? Case
is irrelevant in a base-16 hex value, so the comparison should really be
case-insensitive. I noticed this because authentication was inexplicably
On Fri, 7 Sep 2001, Christopher Cain wrote:
Date: Fri, 07 Sep 2001 12:25:31 -0600
From: Christopher Cain [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Tomcat Dev [EMAIL PROTECTED]
Subject: Catalina Authentication+HexUtils
Does anyone have any objections to my modifying the realm
Christopher Cain wrote:
forced to uppercase for comparison?
... equalsIgnoreCase(), is actually what I meant =)
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
*---Corneille
*/
yes, the solution looks like a great deal in both, performance and
stability,
enven though i found out that synchronizing the ResourceEntry entry is
enough. (at least it does not cause my good old error :-)
i think the concurrent access to the ResourceEntry-object is the point which
leads to the
I don't think the change you made fixes what I described in Bug #3499, which deals
with the file separator character on the Windows OS is being used instead of the '/'
character as used in a URL. That is why I called replace('\\', '/') on the string
representing the JSP filename for the
craigmcc01/09/07 11:39:08
Modified:catalina/src/share/org/apache/catalina/net
SSLServerSocketFactory.java
webapps/tomcat-docs ssl-howto.xml
Log:
Make it possible to specify either an absolute or relative (resolved
against $CATALINA_BASE)
I agree with Costin's suggestion to remove the Apache 2.0
version of mod_jk from jakarta-tomcat for Tomcat 3.3.
This would occur after any bug fixes missing from
jakarta-tomcat-connectors were ported.
It makes much more sense to have it live only in
jakarta-tomcat-connectors where it can quickly
+1
Costin
On Fri, 7 Sep 2001, Larry Isaacs wrote:
I agree with Costin's suggestion to remove the Apache 2.0
version of mod_jk from jakarta-tomcat for Tomcat 3.3.
This would occur after any bug fixes missing from
jakarta-tomcat-connectors were ported.
It makes much more sense to have it
+1
Keith
| -Original Message-
| VOTE:
|
| [ ] +1 REMOVE: Apache 2.0 mod_jk should be removed from
|jakarta-tomcat for Tomcat 3.3
| [ ] -1 KEEP: Apache 2.0 mod_jk should be kept in
|jakarta-tomcat for Tomcat 3.3
ccain 01/09/07 11:51:36
Modified:catalina/src/share/org/apache/catalina/realm JDBCRealm.java
JNDIRealm.java MemoryRealm.java
Log:
Change comparison of hex digests (in authentication) to be
case-insensitive, as base16 values themselves are
craigmcc01/09/07 11:52:14
Modified:jasper/src/share/org/apache/jasper JspC.java
Log:
Re-fix Bugzilla #3499 the way that the submitter posted it, including
dealing with backslash - slash conversion to create valid URL paths.
Revision ChangesPath
1.10 +4 -4
Hi developers
How can i develop a apache-tomcat connector using the nbio library?
http://www.cs.berkeley.edu/~mdw/proj/java-nbio/
Any guideline?
Thanks
Mauricio
yes, the solution looks like a great deal in both, performance and
stability,
enven though i found out that synchronizing the ResourceEntry entry is
enough. (at least it does not cause my good old error :-)
Most likely itwould be enough, since the sync block in findResourceInternal
made sure
remm01/09/07 12:16:31
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
Log:
- Since all threads are sharing the same ResourceEntry instance (thanks to
the syncing in findResourceInternal), we can sync on that object. That
Hola Christopher:
I think this change is not good, as it does *all* passwords case
insensitive, regardles of the use of digest or not.., i think plain
passwords need to be case sensitive ..
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL
+1
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Enviado el: viernes 7 de septiembre de 2001 20:45
Para: '[EMAIL PROTECTED]'
Asunto: [VOTE] Removal of mod_jk for Apache 2.0 from
jakarta-tomcat for
Tomcat 3.3
I agree with
+0
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: craigmcc@localhost [mailto:craigmcc@localhost]En nombre
de Craig R.
McClanahan
Enviado el: martes 4 de septiembre de 2001 22:24
Para: [EMAIL PROTECTED]
Asunto: [VOTE] Release Plan for Apache Tomcat 4.0 (final release)
craigmcc01/09/07 12:43:47
Modified:jasper/src/share/org/apache/jasper/compiler
TagGeneratorBase.java
Log:
When custom tag names have invalid Java identifier characters ('-', '.',
and ':'), replace them with strings that are legal.
PR: Bugzilla #3019
GOMEZ Henri [EMAIL PROTECTED] wrote:
Many users are still using Apache 2.0.24-alpha (including myself),
or even 2.0.18-beta (including IBM iSeries team porting Apache 2.0).
Ok, ok, I could understand your all developpers point of vue,
but let me say it appears just too elitist.
Not at
You might want to add this method to AccessLogInterceptor -- It basically flushes the
log to disk during shutdown. I ran into a couple of cases where the streams weren't
properly flushed and the log was missing.
It may be appropriate to do this in a finalize too.
public void
You're right ... d'oh! I assumed that a method called digest returned
a digest. I guess I should not assume so often =)
My bad ... but in some slight manor of defense, that method call is
poorly named :)
I'll repair this immediately.
- Christopher
Ignacio J. Ortega wrote:
Hola Christopher:
Ok, but that would still require some modifications in the JDBC realm, for
example, because it has the annoying habit to store H(password) ;-)
I was planning to add a mechanism a bit like you describe, but after 4.0.
Right, I had to touch existing realm code as well, since current realms
on 9/7/01 12:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
We use the following mapping: substitute '-' with
+ * #1, '.' with $2, and ':' with $3.
+ */
#1?
-jon
Ignacio J. Ortega [EMAIL PROTECTED] wrote:
Hola Christopher:
I think this change is not good, as it does *all* passwords case
insensitive, regardles of the use of digest or not.., i think plain
passwords need to be case sensitive ..
Good catch :)
Pier
You're right ... d'oh! I assumed that a method called
digest returned
a digest. I guess I should not assume so often =)
My bad ... but in some slight manor of defense, that method call is
poorly named :)
We can change it to a more apropiate digestedOrNot
:
Saludos ,
Ignacio
craigmcc01/09/07 13:27:52
Modified:jasper/src/share/org/apache/jasper/compiler
TagGeneratorBase.java
Log:
Correct a typo in the Javadocs to match the actual behavior.
Submitted by: Jon Stevens [EMAIL PROTECTED] -- Imagine that, a correction to
craigmcc01/09/07 13:27:52
Modified:jasper/src/share/org/apache/jasper/compiler
TagGeneratorBase.java
Log:
Correct a typo in the Javadocs to match the actual behavior.
Submitted by: Jon Stevens [EMAIL PROTECTED] -- Imagine that, a
correction to
Hola Tim:
I like this patch..
Larry can we include it for Tomcat 3.3 ?
I propose to change the file name from .ini to .properties..
And please send the patch following the guidelines at
http://jakarta.apache.org/site/source.html..
Basically:
* cvs diff -u
* As an attached file not inline
ccain 01/09/07 13:45:13
Modified:catalina/src/share/org/apache/catalina/realm JDBCRealm.java
JNDIRealm.java MemoryRealm.java RealmBase.java
Log:
Backs out the previous case-insensitive mod, which would have checked
non-hashed realm passwords
on 9/7/01 1:27 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Submitted by: Jon Stevens [EMAIL PROTECTED] -- Imagine that, a correction
to
a JSP patch :-)
Maybe now I can put on my resume that I contributed to the development of
JSP and
JspC bugs recently fixed in Tomcat 4.0 also exist in 3.2
cvs diff -u JspC.java (in directory
D:\jakarta-tomcat\jakarta-tomcat\src\share\org\apache\jasper)
Index: JspC.java
===
RCS file:
Close ... I added a hasMessageDigest() method =)
Also, I just realized that I was in such a hurry to get fixed code back
into the tree, I forgot to give you credit on the commit log. As Pier
said, that was an excellent catch ... you pulled my kahones out of the
fire on that one :)
I promise
This patches fixes Bug 2917. The name of the .java files generated by Jasper
includes the path name, which can be a problem in Windows if the path name
is long. Since the files are placed under the directories indicated by the
path name, there is really no reason to include the pathname with
craigmcc01/09/07 15:51:26
Modified:jasper/src/share/org/apache/jasper/compiler JspCompiler.java
Log:
Because JSP source and class files are now stored in a directory tree that
mirrors the context-relative path, there is no need to include the
directory path in the generated
I modified this patch a little before applying it:
* The jsp variable will have a context relative path that is already
normalized to forward slashes, so looking for File.separator would
fail on Windows.
* The generated filename will be the same length as the last component
of the path,
jGuru maintains FAQs and Forums on Servlets, JSP, and Tomcat (as well as
many other Java topics). Here is an automated update on recent postings to
Tomcat-related FAQs. Please direct flames and feedback to [EMAIL PROTECTED] .
- Alex
nacho 01/09/07 17:41:29
Modified:src/share/org/apache/tomcat/modules/server Ajp12.java
Log:
fix for 2629 ( userPrincipal not set when used with Ajp13 ).
This bug was suffered by ajp12 connector too..
Revision ChangesPath
1.21 +7 -2
66 matches
Mail list logo
