cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_isapi_plugin.c
mturk 2002/07/06 01:05:49
Modified:jk/native2/server/isapi jk_isapi_plugin.c
Log:
Fix the Q250397 bug introducing authComplete registry param
that one when set enables the SF_NOTIFY_AUTH_COMPLETE
filter notification.
Remove the iis5 version checking acordingly using new approach.
Revision ChangesPath
1.35 +83 -46
jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c
Index: jk_isapi_plugin.c
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_isapi_plugin.c,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- jk_isapi_plugin.c 5 Jul 2002 08:12:09 - 1.34
+++ jk_isapi_plugin.c 6 Jul 2002 08:05:49 - 1.35
@@ -85,6 +85,7 @@
#define SERVER_ROOT_TAG (serverRoot)
#define EXTENSION_URI_TAG (extensionUri)
#define WORKERS_FILE_TAG(workersFile)
+#define USE_AUTH_COMP_TAG (authComplete)
static char file_name[_MAX_PATH];
@@ -93,7 +94,7 @@
static int is_inited = JK_FALSE;
static int is_mapread = JK_FALSE;
static int was_inited = JK_FALSE;
-static int iis5 = -1;
+static int auth_notification_flags = 0;
static jk_workerEnv_t *workerEnv;
static apr_pool_t *jk_globalPool;
@@ -117,7 +118,7 @@
static jk_env_t* jk2_create_config();
-
+static int get_auth_flags();
static void write_error_response(PHTTP_FILTER_CONTEXT pfc,char *status,char * msg)
@@ -151,20 +152,23 @@
if (pVer-dwFilterVersion http_filter_revision) {
pVer-dwFilterVersion = http_filter_revision;
}
-
+auth_notification_flags = get_auth_flags();
#ifdef SF_NOTIFY_AUTH_COMPLETE
-
-pVer-dwFlags = SF_NOTIFY_ORDER_HIGH|
-SF_NOTIFY_SECURE_PORT |
-SF_NOTIFY_NONSECURE_PORT|
-SF_NOTIFY_PREPROC_HEADERS |
-SF_NOTIFY_AUTH_COMPLETE;
-#else
-pVer-dwFlags = SF_NOTIFY_ORDER_HIGH|
-SF_NOTIFY_SECURE_PORT |
-SF_NOTIFY_NONSECURE_PORT|
-SF_NOTIFY_PREPROC_HEADERS;
+if (auth_notification_flags == SF_NOTIFY_AUTH_COMPLETE) {
+pVer-dwFlags = SF_NOTIFY_ORDER_HIGH|
+SF_NOTIFY_SECURE_PORT |
+SF_NOTIFY_NONSECURE_PORT|
+SF_NOTIFY_PREPROC_HEADERS |
+SF_NOTIFY_AUTH_COMPLETE;
+}
+else
#endif
+{
+pVer-dwFlags = SF_NOTIFY_ORDER_HIGH|
+SF_NOTIFY_SECURE_PORT |
+SF_NOTIFY_NONSECURE_PORT|
+SF_NOTIFY_PREPROC_HEADERS;
+}
strcpy(pVer-lpszFilterDesc, VERSION_STRING);
@@ -201,28 +205,8 @@
}
if (is_inited is_mapread) {
env = workerEnv-globalEnv-getEnv( workerEnv-globalEnv );
-if (is_inited (iis5 0) ) {
-char serverSoftware[256];
-DWORD dwLen = sizeof(serverSoftware);
-iis5=0;
-if (pfc-GetServerVariable(pfc,SERVER_SOFTWARE, serverSoftware,
dwLen)){
-iis5=(atof(serverSoftware + 14) = 5.0);
-if (iis5) {
-env-l-jkLog(env, env-l, JK_LOG_INFO,Detected IIS =
5.0\n);
-} else {
-env-l-jkLog(env, env-l, JK_LOG_INFO,Detected IIS 5.0\n);
-}
-}
-}
-#ifdef SF_NOTIFY_AUTH_COMPLETE
-if (is_inited
- (((SF_NOTIFY_PREPROC_HEADERS == dwNotificationType) !iis5) ||
- ((SF_NOTIFY_AUTH_COMPLETE == dwNotificationType) iis5)
- )
-)
-#else
-if (is_inited (SF_NOTIFY_PREPROC_HEADERS == dwNotificationType))
-#endif
+
+if (auth_notification_flags == dwNotificationType)
{
char uri[INTERNET_MAX_URL_LENGTH];
char snuri[INTERNET_MAX_URL_LENGTH]=/;
@@ -240,22 +224,18 @@
DWORD szTranslate = sizeof(Translate);
#ifdef SF_NOTIFY_AUTH_COMPLETE
-if (iis5) {
+if (auth_notification_flags == SF_NOTIFY_AUTH_COMPLETE) {
GetHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)-GetHeader;
SetHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)-SetHeader;
AddHeader=((PHTTP_FILTER_AUTH_COMPLETE_INFO)pvNotification)-AddHeader;
-} else {
+}
+else
+#endif
+{
GetHeader=((PHTTP_FILTER_PREPROC_HEADERS)pvNotification)-GetHeader;
SetHeader=((PHTTP_FILTER_PREPROC_HEADERS)pvNotification)-SetHeader;
cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi jk_iis.h
mturk 2002/07/06 01:06:55 Modified:jk/native2/server/isapi jk_iis.h Log: Some #defines for getting the erver version from registry Revision ChangesPath 1.9 +1 -0 jakarta-tomcat-connectors/jk/native2/server/isapi/jk_iis.h Index: jk_iis.h === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/jk_iis.h,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- jk_iis.h 27 Apr 2002 00:48:33 - 1.8 +++ jk_iis.h 6 Jul 2002 08:06:55 - 1.9 @@ -100,6 +100,7 @@ #define SERVER_SOFTWARE (SERVER_SOFTWARE) #define REGISTRY_LOCATION(Software\\Apache Software Foundation\\Jakarta Isapi Redirector\\2.0) +#define W3SVC_REGISTRY_KEY (SYSTEM\\CurrentControlSet\\Services\\W3SVC\\Parameters) #define BAD_REQUEST -1 #define BAD_PATH-2 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native2/server/isapi isapi_redirector2.reg
mturk 2002/07/06 01:07:41 Modified:jk/native2/server/isapi isapi_redirector2.reg Log: The new DWORD param authComplete set to any nonzero value to activate. Revision ChangesPath 1.4 +1 -1 jakarta-tomcat-connectors/jk/native2/server/isapi/isapi_redirector2.reg Index: isapi_redirector2.reg === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/server/isapi/isapi_redirector2.reg,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- isapi_redirector2.reg 30 Jun 2002 10:11:11 - 1.3 +++ isapi_redirector2.reg 6 Jul 2002 08:07:41 - 1.4 @@ -4,4 +4,4 @@ serverRoot=E:\\tomcat\\jakarta-tomcat\\build\\tomcat extensionUri=/jakarta/isapi_redirector2.dll workersFile=E:\\tomcat\\jakarta-tomcat\\build\\tomcat\\conf\\workers2.properties - +authComplete=dword: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AuthComplete WAS POST problems
Hi, Introduced a new registry configuration parameter 'authComplete'. The problem is that we cannot use the existing config functions cause the reading should be done prior we have a environment, so it had to go into a separate function. The default is to disable the SF_NOTIFY_AUTH_COMPLETE notification, and can be enabled setting the authComplete registry key to a nonzero value, for the working WIN2K versions (sorry don't know what are the working IIS Service Pack combinations, so its up to you guys :). Once when we have a SP1 for XP (and if it works :) then we'll put that to be enabled by the default back again. I've also rearranged the iis5 version checking to use the registered notification type. MT. ICQ# 163961212 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10526] New: - Authenticators do not always cache the Principal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10526.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10526
Authenticators do not always cache the Principal
Summary: Authenticators do not always cache the Principal
Product: Tomcat 4
Version: Nightly Build
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Once a user is authenticated a Principal object is supposed to be cached for
the duration of the user's session. This is especially important when using
JDBCRealm or JNDIRealm to reduce the load on external authentication services.
Most authenticators (BasicAuthenticator, SSLAuthenticator and
DigestAuthenticator) call AuthenticatorBase.register()to cache the Principal.
However register() does nothing if a session object does not already exist, so
caching does not occur when the application does not create a session object
itself. The problem can be seen by setting a security constraint on tomcat-docs
and then browsing the Tomcat documentation - the external authentication
service is hit on every request.
The problem does not occur with form based login, because FormAuthenticator
caches the Principal itself and creates a new session if necessary to do it.
Probably the best fix would be to change AuthenticatorBase.register() to create
a new session by calling getSession(request, true) instead of getSession
(request, false). However, perhaps there is a reason why this is not being
done - though if so I cannot see what it is.
An alternative is to change the concrete authentication classes to make sure a
session exists before calling register(), e.g.
--- BasicAuthenticator.java 23 Mar 2002 17:52:16 - 1.12
+++ BasicAuthenticator.java 6 Jul 2002 12:46:30 -
@@ -160,6 +160,7 @@
String password = parsePassword(authorization);
principal = context.getRealm().authenticate(username, password);
if (principal != null) {
+ Session session = getSession(request, true);
register(request, response, principal, Constants.BASIC_METHOD,
username, password);
return (true);
Similar patches would be required for SSLAuthenticator and DigestAuthenticator
of course.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9703] - Two extra authentications occur for each JNDIRealm authentication
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9703. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9703 Two extra authentications occur for each JNDIRealm authentication --- Additional Comments From [EMAIL PROTECTED] 2002-07-06 13:19 --- Such caching is already supposed to be done by the Authenticator classes, and mostly it is. However, if you are not using form-based login and the web application does not itself create a session object, caching will not take place (bug 10526). This explains the problem here. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 9224] - JNDI realm documentation not up to date
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9224. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9224 JNDI realm documentation not up to date [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-07-06 13:28 --- Thanks Remy! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] experimental jk2 iis thread pool
Hi, Before going to commit something I would like to hear some opinions, and tests preferably. Here are some facts: IIS maintains a pool of threads to handle incoming HTTP requests. When all of these threads are in use, new requests will be rejected. If all the pool threads are in a wait state (for instance, running our dll), IIS may reject incoming requests even if there is plenty of CPU power to handle them. Now since we basically most of the are waiting for a TC to respond, the thread pool and the patch I'm proposing effectively deals with choking the server. To set the things up, you'll need to (beside the patches) put the 'threadPool' with the value of 10 or higher in the i_r2 registry configuration. Lesser values doesn't make sense. The thread pool manager currently doesn't do anything, but my intention is to make him a watcher for a hanged responses, and dynamic pool allocator. The pool itself is static (defined by the threadPool configuration value), but it will be extended with the min/max size, closing unused connections after a peak load. Comments? MT. ICQ# 163961212 jk_iis.h.patch Description: Binary data /* = * * * * The Apache Software License, Version 1.1 * * * * Copyright (c) 1999-2001 The Apache Software Foundation. * * All rights reserved.* * * * = * * * * Redistribution and use in source and binary forms, with or without modi- * * fication, are permitted provided that the following conditions are met: * * * * 1. Redistributions of source code must retain the above copyright notice * *notice, this list of conditions and the following disclaimer. * * * * 2. Redistributions in binary form must reproduce the above copyright * *notice, this list of conditions and the following disclaimer in the * *documentation and/or other materials provided with the distribution. * * * * 3. The end-user documentation included with the redistribution, if any, * *must include the following acknowlegement: * * * * This product includes software developed by the Apache Software * *Foundation http://www.apache.org/. * * * *Alternately, this acknowlegement may appear in the software itself, if * *and wherever such third-party acknowlegements normally appear. * * * * 4. The names The Jakarta Project, Jk, and Apache Software * *Foundation must not be used to endorse or promote products derived * *from this software without prior written permission. For written * *permission, please contact [EMAIL PROTECTED].* * * * 5. Products derived from this software may not be called Apache nor may * *Apache appear in their names without prior written permission of the * *Apache Software Foundation.* * * * THIS SOFTWARE IS PROVIDED AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES * * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY * * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL * * THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY * * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN * * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * * POSSIBILITY OF SUCH DAMAGE. * *
DO NOT REPLY [Bug 10527] New: - SSL socket error shuts down access to HTTPS pages
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10527. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10527 SSL socket error shuts down access to HTTPS pages Summary: SSL socket error shuts down access to HTTPS pages Product: Tomcat 4 Version: 4.0.4 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Blocker Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Migrating from 4.03 to 4.04 and Coyote, getting error using HTTPS with the Coyote connector. Some access to HTTPS pages works, but once error occurs, subsequent access to HTTPS pages is blocked (and one gets 404 errors) for a time. Then HTTPS access works again for a while, then blocked, etc. Here is my config for Coyote, followed by the console error messages: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=80 minProcessors=5 maxProcessors=100 bufferSize=4096 enableLookups=false redirectPort=443 acceptCount=20 debug=0 connectionTimeout=6/ Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=443 minProcessors=5 maxProcessors=100 bufferSize=4096 enableLookups=false acceptCount=20 debug=0 scheme=https secure=true Factory className=org.apache.coyote.tomcat4.CoyoteServerSocketFactory clientAuth=false protocol=TLS keystorePass=mypasssword keystoreFile=mycertificate.p12 keystoreType=pkcs12/ PoolTcpEndpoint: Handshake failed java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) PoolTcpEndpoint: Handshake failed at java.net.SocketOutputStream.write(SocketOutputStream.java:126) at com.sun.net.ssl.internal.ssl.OutputRecord.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec (DashoA6275) at com.sun.net.ssl.internal.ssl.ServerHandshaker.d(DashoA6275) at com.sun.net.ssl.internal.ssl.ServerHandshaker.a(DashoA6275) at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage (DashoA6275) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275) at java.io.OutputStream.write(OutputStream.java:58) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275) at org.apache.tomcat.util.net.JSSESocketFactory.handshake (JSSESocketFactory.java:270) at org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java:493) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:518) at java.lang.Thread.run(Thread.java:536) java.net.SocketException: Software caused connection abort: JVM_recv in socket input stream read at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:116) ThreadPool: Caught exception executing org.apache.tomcat.util.net.TcpWorkerThread@e4245, terminating thread at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA6275) at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275) at java.io.OutputStream.write(OutputStream.java:58) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275) at org.apache.tomcat.util.net.JSSESocketFactory.handshake (JSSESocketFactory.java:270) at org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java:493) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:518) at java.lang.Thread.run(Thread.java:536) java.lang.NullPointerException at org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java:512) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:518) at java.lang.Thread.run(Thread.java:536) ThreadPool: Caught exception executing org.apache.tomcat.util.net.TcpWorkerThread@e4245, terminating thread java.lang.NullPointerException at
Fix for bug #8331??
I am on Apache 2.0.39 and Tomcat 4.1.3, and the latest webapp connector code, fresh from CVS. I am facing a Invalid virtual host name error from Apache with this configuration: LoadModule webapp_module libexec/mod_webapp.so WebAppConnection conn warp localhost:8008 WebAppDeploy examples conn /examples This seems to be identical to bug#8331. Any fixes? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8331 Tx __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Fix for bug #8331??
Sam Ewing [EMAIL PROTECTED] wrote: I am on Apache 2.0.39 and Tomcat 4.1.3, and the latest webapp connector code, fresh from CVS. I am facing a Invalid virtual host name error from Apache with this configuration: LoadModule webapp_module libexec/mod_webapp.so WebAppConnection conn warp localhost:8008 WebAppDeploy examples conn /examples This seems to be identical to bug#8331. Any fixes? http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8331 I runs on my own system here... Did you remember to put the ServerName directive in your virtual host? This is how my httpd.conf (relevant part of virtualhosts looks like): [...] LoadModule webapp_module libexec/mod_webapp.so [...] ServerName blossom.betaversion.org:80 [...] WebAppConnection local warp 127.0.0.1:8008 [...] NameVirtualHost * VirtualHost * ServerName blossom.betaversion.org:80 # DocumentRoot [inherited from main] # ServerAdmin [inherited from main] WebAppInfo /webapp-status [...] /VirtualHost VirtualHost * ServerName www1.blossom:80 DocumentRoot /Library/Services/Apache2/Sites/www1 # ServerAdmin [inherited from main] WebAppDeploy svnview local /svnview [...] /VirtualHost Anyhow, this is being fixed... TC should have no clue of what is a virtual host, it just needs to know that a request is mapped to a particular context, no need to care about anything else... Pier -- [Perl] combines all the worst aspects of C and Lisp: a billion of different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript. [Jamie Zawinski - DNA Lounge - San Francisco] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: CVS problem
How? I'm not running any CVS commands. You need admin access to delete the #cvs.wfl or #cvs.lock files, which I don't have. If there's a way for me to fix this, please let me know. -Dan Remy Maucherat wrote: Trying to tag the CVS with 4.1.7 ... cvs server: [03:59:27] waiting for dsandberg's lock in /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets cvs server: [04:00:00] waiting for dsandberg's lock in /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets Dan, can you fix it ASAP ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
