DO NOT REPLY [Bug 28805] - Tomcat can't start up

[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=28805


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|VERIFIED|CLOSED




-- 
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 28805] - Tomcat can't start up

[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=28805


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED
 OS/Version||All




--- Additional Comments From [EMAIL PROTECTED]  2005-02-11 07:23 ---
(In reply to comment #0)
> When i type "startup" in a dos prompt window, it says
> The system cannot find the file -Dsun.io.useCanonCaches=false.
> and Tomcat cannot start up.
> Help needed!

You need to set JAVA_HOME properly pointing to your jdk directory

-- 
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 33510] New: - recover_wait_time for workers in_error_state should be calculated using difftime()

[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=33510

   Summary: recover_wait_time for workers in_error_state should be
calculated using difftime()
   Product: Tomcat 5
   Version: 5.0.30
  Platform: PC
OS/Version: Solaris
Status: NEW
  Severity: normal
  Priority: P3
 Component: Connector:AJP
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I was diagnosing some failover issues we were having with our network setup, 
and I noticed strange logs when testing the error behavior when a tomcat server 
physically goes down.  The logs look like this (severly hacked for readability):

[Thu Feb 10 17:17:31 2005] [4106:0] [debug] jk_lb_worker.c (300): worker 
candidate giraffe (1) is in error state - will not yet recover (42 < 3600)
[Thu Feb 10 17:17:32 2005] [4106:0] [debug] jk_lb_worker.c (300): worker 
candidate giraffe (1) is in error state - will not yet recover (43 < 3600)
[Thu Feb 10 17:18:30 2005] [4101:0] [debug] jk_lb_worker.c (300): worker 
candidate giraffe (1) is in error state - will not yet recover (2475 < 3600)
[Thu Feb 10 17:19:24 2005] [4102:0] [debug] jk_lb_worker.c (300): worker 
candidate giraffe (1) is in error state - will not yet recover (1428 < 3600)

3600 is what I set the configuration value to.  The first number should be 
increasing by one per second, but as you can see when the minute changes, the 
number jumps dramatically.  So the time_t implementation I compiled with doesnt 
seem to support a simple time_t1 - time_t2 to get an elapsed time, as it is in 
the source code (jk_lb_worker.c:297).
Doing a little snooping found the recommendation to use the method difftime() 
to get the elapsed time value.  Should you be using this instead?

-- 
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 33505] - mod_jk does not build on OS/400

[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=33505





--- Additional Comments From [EMAIL PROTECTED]  2005-02-11 01:47 ---
Created an attachment (id=14247)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14247&action=view)
Changes to header file & build CL for correct compilation

This will patch:
- jk\native\common\jk_service.h to eliminate the char * conversion error
- jk\native\apache-2.0\bldjk.qclsrc to eliminate CRTSRVPGM errors

-- 
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-catalina/catalina/src/share/org/apache/catalina/session ManagerBase.java

[luehe]

luehe   2005/02/10 16:05:54

  Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java
  Log:
  Propagate value of context's "distributable" property to its session
  manager.
  
  This is to address SRV.7.7.2:
Within an application marked as distributable [...] The
container must be able to handle all objects placed into instances of
the HttpSession class using the setAttribute or putValue methods
appropriately. The following restrictions are imposed to meet these
conditions:
- The container must accept objects that implement the Serializable
  interface.
  
  Revision  ChangesPath
  1.39  +2 -1  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java
  
  Index: ManagerBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
  retrieving revision 1.38
  retrieving revision 1.39
  diff -u -r1.38 -r1.39
  --- ManagerBase.java  7 Feb 2005 21:56:32 -   1.38
  +++ ManagerBase.java  11 Feb 2005 00:05:54 -  1.39
  @@ -679,6 +679,7 @@
   StandardContext ctx=(StandardContext)this.getContainer();
   Engine eng=(Engine)ctx.getParent().getParent();
   domain=ctx.getEngineName();
  +distributable = ctx.getDistributable();
   StandardHost hst=(StandardHost)ctx.getParent();
   String path = ctx.getPath();
   if (path.equals("")) {
  
  
  

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

DO NOT REPLY [Bug 33505] New: - mod_jk does not build on OS/400

[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=33505

   Summary: mod_jk does not build on OS/400
   Product: Tomcat 5
   Version: Unknown
  Platform: Other
OS/Version: other
Status: NEW
  Severity: major
  Priority: P2
 Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Building mod_jk for Apache 2 on OS/400 (IBM HTTP Server powered by Apache)
fails. There are three problems.

1) jk_ajp12_worker.c: Cannot convert between 'char *' and 'const char *' in
ajpv12_handle_request
2) bldjk.qclsrc: STGMDL(*INHERIT) requires ACTGRP(*CALLER) in CRTSRVPGM call.
3) bldjk.qclsrc: Unresolved symbols during CRTSRVPGM call
(status_worker_factory, jk_shm_*)

These problems were experienced using CVS source checked out yesterday (2/9/05).

-- 
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 32424] - Redirecting directiories with missing trailing slash breaks web applications

[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=32424





--- Additional Comments From [EMAIL PROTECTED]  2005-02-10 23:34 ---
Didn't you promise the following: "Anyway I'll shutup since I'm clearly wasting
my time" ? ;)

-- 
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-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java

[luehe]

luehe   2005/02/10 14:25:55

  Modified:catalina/src/share/org/apache/catalina/startup
ContextConfig.java
  Log:
  Avoid allocating dummy LogConfig for every webapp that needs one.
  
  Revision  ChangesPath
  1.61  +6 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
  
  Index: ContextConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
  retrieving revision 1.60
  retrieving revision 1.61
  diff -u -r1.60 -r1.61
  --- ContextConfig.java14 Dec 2004 13:57:31 -  1.60
  +++ ContextConfig.java10 Feb 2005 22:25:55 -  1.61
  @@ -168,6 +168,10 @@
   protected static long deploymentCount = 0L;
   
   
  +private static final LoginConfig DUMMY_LOGIN_CONFIG =
  +new LoginConfig("NONE", null, null, null);
  +
  +
   // - 
Properties
   
   
  @@ -370,7 +374,7 @@
   return;
   LoginConfig loginConfig = context.getLoginConfig();
   if (loginConfig == null) {
  -loginConfig = new LoginConfig("NONE", null, null, null);
  +loginConfig = DUMMY_LOGIN_CONFIG;
   context.setLoginConfig(loginConfig);
   }
   
  
  
  

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

DO NOT REPLY [Bug 32424] - Redirecting directiories with missing trailing slash breaks web applications

[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=32424





--- Additional Comments From [EMAIL PROTECTED]  2005-02-10 23:04 ---
Keith thanks for making the logic behind this clearer.

I understand that this is desirable behaviour *when* the "default" servlet ends
up handling the request but the redirect happens in "Rule 7" of the mapper where
it is only *possible* that the "default" servlet will handle the request. In my
web app a filter forwards the request on so that in the end the "default"
servlet is never invoked which means the assumption made at "Rule 7" was 
invalid. 

In addition to this the spec is quite clear that a filter that is mapped to "/*"
should be given the opportunity to filter all requests - in this special case
Tomcat does not fulfil this requirement as it makes the *incorrect* assumption
that the redirected request is logically the same as the original. eg. In my web
app the request for "/images" is not the same as "/images/" (even though I don't
have a servlet mapped to "/images") however Tomcat does not allow our forwarding
filter to process the "/images" request and forward it on the the correct
servlet as there happens to be a directory called "images" in out web app. 

I'm currently using Jetty and it allows filters to process the request *before*
doing the 302. 

-- 
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-catalina/modules/cluster/src/share/org/apache/catalina/cluster/mcast McastServiceImpl.java

[fhanik]

fhanik  2005/02/10 12:44:37

  Modified:modules/cluster/src/share/org/apache/catalina/cluster/mcast
McastServiceImpl.java
  Log:
  make sure that we don't suck up CPU in case of multicast error
  
  Revision  ChangesPath
  1.14  +5 -3  
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/mcast/McastServiceImpl.java
  
  Index: McastServiceImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/mcast/McastServiceImpl.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- McastServiceImpl.java 11 Nov 2004 14:47:27 -  1.13
  +++ McastServiceImpl.java 10 Feb 2005 20:44:37 -  1.14
  @@ -243,7 +243,9 @@
   try {
   receive();
   } catch ( Exception x ) {
  -log.warn("Error receiving mcast package.",x);
  +log.warn("Error receiving mcast package. Sleeping 
500ms",x);
  +try { Thread.sleep(500); } catch ( Exception ignore ){}
  +
   }
   }
   }
  @@ -260,10 +262,10 @@
   while ( doRun ) {
   try {
   send();
  -Thread.sleep(time);
   } catch ( Exception x ) {
   log.warn("Unable to send mcast message.",x);
   }
  +try { Thread.sleep(time); } catch ( Exception ignore ) {}
   }
   }
   }//class SenderThread
  
  
  

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

ServletRequest to MBean Mapping

[Jess Holle]

Is there any way to map from a javax.servlet.ServletRequest (from within 
a filter or whatever) to the JMX data registered on this request by Tomcat?

I am trying to produce some servlet-engine independent MBeans to garner 
a certain level of data in an independent fashion but would like to be 
able to pluck out certain things from the corresponding Tomcat MBeans 
where appropriate, e.g. to jump from ServletRequest to the request 
processor to determine how many bytes are read and written by the 
request without having to try to redo all of this myself (without direct 
access to the buffers).

Ideas?
--
Jess Holle
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 33494] New: - jscv configure script fails on x86_64

[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=33494

   Summary: jscv configure script fails on x86_64
   Product: Tomcat 5
   Version: 5.5.7
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I have dual AMD Opteron server with Fedora Core 3.

configure script fails with: "configure: error: Unsupported CPU architecture
"x86_64".

I maneged to pass this by inserting:
 x86_64)
CFLAGS="$CFLAGS -DCPU=\\\"k8\\\"" ;;

at line 2636 in configure script.

It is obvious that this solution works only for AMD 64 bit. So please add
support for 64 bit processors.

-- 
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 33474] - tcpListenPort="0" won't get actual local port for cluster membership

[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=33474





--- Additional Comments From [EMAIL PROTECTED]  2005-02-10 16:43 ---
I have to disagree with marking this as invalid.  It _is_ marked as an 
enhancement and it would be much easier to tell when or if it is implemented 
with this for tracking.

I couldn't find any other dependencies on the listener port.  The only other 
issue is making the bind happen in the calling thread inside of start() and not 
in the listener's thread.  I don't know why you would continue processing the 
cluster (or even starting another thread in this case) if you can't get a 
required resource, even if it may save a little time.  I didn't see anything 
required for the bind that could block for any long period of time, so putting 
it in the calling thread wouldn't do any harm.

If there are any "dependencies" outside of that, that's non-OO and bad news.

-- 
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: DO NOT REPLY [Bug 33492] New: - When using LDAP realms Tomc at floods the LDAP server with searches instead of binding as a DN

[ops . bc]

Au Kin Leung
Barge Centre - Planner
Hongkong International Terminals 
Tel : (852) 2619 7932 
Fax : (852) 2615 9369 
E-mail : [EMAIL PROTECTED] 
Website : www.hit.com.hk  

IMPORTANT NOTICE 
The above job number serves only as a reference number of your booking
request.  This DOES NOT confirm HIT's berth availability to provide barge
services to you at your requested booking time.  

Please note that HIT Berth Schedule Report will be email/fax to you at 14:00
for requests from 17:00 to 22:59 and at 20:00 for requests from 23:00 to
16:59 on the next day.  Kindly please forward the HIT Berth Schedule Report
to your barge agents/operators and remind them to berth at HIT at the
confirmed berthing time.

Should you have any queries, please feel free to contact us at 2619-7932. 



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 10, 2005 11:27 PM
To: tomcat-dev@jakarta.apache.org
Subject: RE: DO NOT REPLY [Bug 33492] New: - When using LDAP realms Tomc at
floods the LDAP server with searches instead of binding as a DN




Au Kin Leung
Barge Centre - Planner
Hongkong International Terminals 
Tel : (852) 2619 7932 
Fax : (852) 2615 9369 
E-mail : [EMAIL PROTECTED] 
Website : www.hit.com.hk  

IMPORTANT NOTICE 
The above job number serves only as a reference number of your booking
request.  This DOES NOT confirm HIT's berth availability to provide barge
services to you at your requested booking time.  

Please note that HIT Berth Schedule Report will be email/fax to you at 14:00
for requests from 17:00 to 22:59 and at 20:00 for requests from 23:00 to
16:59 on the next day.  Kindly please forward the HIT Berth Schedule Report
to your barge agents/operators and remind them to berth at HIT at the
confirmed berthing time.

Should you have any queries, please feel free to contact us at 2619-7932. 



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 10, 2005 11:23 PM
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 33492] New: - When using LDAP realms Tomcat
floods the LDAP server with searches instead of binding as a DN


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=33492

   Summary: When using LDAP realms Tomcat floods the LDAP server
with searches instead of binding as a DN
   Product: Tomcat 5
   Version: 5.0.30
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I have the following Engine configuration in server.xml:


  

  ldap://localhost:388";
 authentication="simple"
 userBase="dc=altkom,dc=pl,o=Altkom" userSubtree="true"
 userSearch="uid={0}"
 userRoleName="ou"
 resourceName="LdapDatabase" />

  


The port 388 is used by a local stunnel proxy that forwards SSL-encapsulated
LDAP requests to a central LDAP authentication server (Tomcat stubbornly
uses plaintext communication even with ldaps:// URI's, but that's another
story...).

The Tomcat server starts up OK, and I can see it opening a connection to the
LDAP server. It's visible in OpenLDAP's logs:

Feb 10 16:08:30 ldap slapd[10446]: conn=36 fd=17 ACCEPT from
IP=xxx.xxx.xxx.xxx:49747 (IP=0.0.0.0:636) 
Feb 10 16:08:30 ldap slapd[10446]: conn=36 op=0 BIND dn="" method=128 
Feb 10 16:08:30 ldap slapd[10446]: conn=36 op=0 RESULT tag=97 err=0 text= 

Tomcat reports success in its logs too:

Feb 10, 2005 4:08:30 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.0
Feb 10, 2005 4:08:31 PM org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
Feb 10, 2005 4:08:31 PM org.apache.catalina.core.StandardHost getDeployer
INFO: Create Host deployer for direct deployment ( non-jmx ) Feb 10, 2005
4:08:31 PM org.apache.catalina.core.StandardHostDeployer install
INFO: Processing Context configuration file URL
file:/etc/tomcat5/Catalina/localhost/balancer.xml
...

However, if I try to authenticate a user by trying to log in to the standard
admin webapp, Tomcat floods the LDAP server with redundant search requests:

Feb 10 16:11:03 ldap slapd[10446]: conn=36 op=1 SRCH
base="dc=altkom,dc=pl,o=Altkom" scope=2 filter="(uid=someuser)" Feb 10
16:11:03 ldap slapd[10446]: conn=36 op=1 SRCH attr=ou Feb 10 16:11:03 ldap
slapd[10446]: conn=37 fd=19 ACCEPT from IP=127.0.0.1:40390
(IP=0.0.0.0:389)
Feb 10 16:11:03 ldap slapd[10446]: conn=37 op=0 BIND dn="" method=128 Feb 10
16:11:03 ldap slapd[10446]: conn=37 op=0 RESULT tag=97 err=0 te

RE: DO NOT REPLY [Bug 33492] New: - When using LDAP realms Tomc at floods the LDAP server with searches instead of binding as a DN

[ops . bc]

Au Kin Leung
Barge Centre - Planner
Hongkong International Terminals 
Tel : (852) 2619 7932 
Fax : (852) 2615 9369 
E-mail : [EMAIL PROTECTED] 
Website : www.hit.com.hk  

IMPORTANT NOTICE 
The above job number serves only as a reference number of your booking
request.  This DOES NOT confirm HIT's berth availability to provide barge
services to you at your requested booking time.  

Please note that HIT Berth Schedule Report will be email/fax to you at 14:00
for requests from 17:00 to 22:59 and at 20:00 for requests from 23:00 to
16:59 on the next day.  Kindly please forward the HIT Berth Schedule Report
to your barge agents/operators and remind them to berth at HIT at the
confirmed berthing time.

Should you have any queries, please feel free to contact us at 2619-7932. 



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 10, 2005 11:23 PM
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 33492] New: - When using LDAP realms Tomcat
floods the LDAP server with searches instead of binding as a DN


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=33492

   Summary: When using LDAP realms Tomcat floods the LDAP server
with searches instead of binding as a DN
   Product: Tomcat 5
   Version: 5.0.30
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I have the following Engine configuration in server.xml:


  

  ldap://localhost:388";
 authentication="simple"
 userBase="dc=altkom,dc=pl,o=Altkom" userSubtree="true"
 userSearch="uid={0}"
 userRoleName="ou"
 resourceName="LdapDatabase" />

  


The port 388 is used by a local stunnel proxy that forwards SSL-encapsulated
LDAP requests to a central LDAP authentication server (Tomcat stubbornly
uses plaintext communication even with ldaps:// URI's, but that's another
story...).

The Tomcat server starts up OK, and I can see it opening a connection to the
LDAP server. It's visible in OpenLDAP's logs:

Feb 10 16:08:30 ldap slapd[10446]: conn=36 fd=17 ACCEPT from
IP=xxx.xxx.xxx.xxx:49747 (IP=0.0.0.0:636) 
Feb 10 16:08:30 ldap slapd[10446]: conn=36 op=0 BIND dn="" method=128 
Feb 10 16:08:30 ldap slapd[10446]: conn=36 op=0 RESULT tag=97 err=0 text= 

Tomcat reports success in its logs too:

Feb 10, 2005 4:08:30 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.0
Feb 10, 2005 4:08:31 PM org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
Feb 10, 2005 4:08:31 PM org.apache.catalina.core.StandardHost getDeployer
INFO: Create Host deployer for direct deployment ( non-jmx ) Feb 10, 2005
4:08:31 PM org.apache.catalina.core.StandardHostDeployer install
INFO: Processing Context configuration file URL
file:/etc/tomcat5/Catalina/localhost/balancer.xml
...

However, if I try to authenticate a user by trying to log in to the standard
admin webapp, Tomcat floods the LDAP server with redundant search requests:

Feb 10 16:11:03 ldap slapd[10446]: conn=36 op=1 SRCH
base="dc=altkom,dc=pl,o=Altkom" scope=2 filter="(uid=someuser)" Feb 10
16:11:03 ldap slapd[10446]: conn=36 op=1 SRCH attr=ou Feb 10 16:11:03 ldap
slapd[10446]: conn=37 fd=19 ACCEPT from IP=127.0.0.1:40390
(IP=0.0.0.0:389)
Feb 10 16:11:03 ldap slapd[10446]: conn=37 op=0 BIND dn="" method=128 Feb 10
16:11:03 ldap slapd[10446]: conn=37 op=0 RESULT tag=97 err=0 text= Feb 10
16:11:03 ldap slapd[10446]: conn=37 op=1 SRCH
base="dc=altkom,dc=pl,o=Altkom" scope=2 filter="(uid=someuser)" Feb 10
16:11:03 ldap slapd[10446]: conn=37 op=1 SRCH attr=ou Feb 10 16:11:03 ldap
slapd[10446]: conn=38 fd=21 ACCEPT from IP=127.0.0.1:40391
(IP=0.0.0.0:389)
Feb 10 16:11:03 ldap slapd[10446]: conn=38 op=0 BIND dn="" method=128 Feb 10
16:11:03 ldap slapd[10446]: conn=38 op=0 RESULT tag=97 err=0 text= Feb 10
16:11:03 ldap slapd[10446]: conn=38 op=1 SRCH
base="dc=altkom,dc=pl,o=Altkom" scope=2 filter="(uid=someuser)" Feb 10
16:11:03 ldap slapd[10446]: conn=38 op=1 SRCH attr=ou Feb 10 16:11:03 ldap
slapd[10446]: conn=39 fd=23 ACCEPT from IP=127.0.0.1:40392
(IP=0.0.0.0:389)
Feb 10 16:11:03 ldap slapd[10446]: conn=39 op=0 BIND dn="" method=128 Feb 10
16:11:03 ldap slapd[10446]: conn=39 op=0 RESULT tag=97 err=0 text=

Tomcat opens many parallel connections until it clogs the LDAP server.

Looks like it tries to do an asynchronous search (why not a synchronous
one?), and instead of checking back for results later, opens new connections
and does new searches in an infinite loop.

DO NOT REPLY [Bug 33492] New: - When using LDAP realms Tomcat floods the LDAP server with searches instead of binding as a DN

[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=33492

   Summary: When using LDAP realms Tomcat floods the LDAP server
with searches instead of binding as a DN
   Product: Tomcat 5
   Version: 5.0.30
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: major
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I have the following Engine configuration in server.xml:


  

  ldap://localhost:388";
 authentication="simple"
 userBase="dc=altkom,dc=pl,o=Altkom" userSubtree="true"
 userSearch="uid={0}"
 userRoleName="ou"
 resourceName="LdapDatabase" />

  


The port 388 is used by a local stunnel proxy that forwards SSL-encapsulated
LDAP requests to a central LDAP authentication server (Tomcat stubbornly uses
plaintext communication even with ldaps:// URI's, but that's another story...).

The Tomcat server starts up OK, and I can see it opening a connection to the
LDAP server. It's visible in OpenLDAP's logs:

Feb 10 16:08:30 ldap slapd[10446]: conn=36 fd=17 ACCEPT from
IP=xxx.xxx.xxx.xxx:49747 (IP=0.0.0.0:636) 
Feb 10 16:08:30 ldap slapd[10446]: conn=36 op=0 BIND dn="" method=128 
Feb 10 16:08:30 ldap slapd[10446]: conn=36 op=0 RESULT tag=97 err=0 text= 

Tomcat reports success in its logs too:

Feb 10, 2005 4:08:30 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.0
Feb 10, 2005 4:08:31 PM org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
Feb 10, 2005 4:08:31 PM org.apache.catalina.core.StandardHost getDeployer
INFO: Create Host deployer for direct deployment ( non-jmx )
Feb 10, 2005 4:08:31 PM org.apache.catalina.core.StandardHostDeployer install
INFO: Processing Context configuration file URL
file:/etc/tomcat5/Catalina/localhost/balancer.xml
...

However, if I try to authenticate a user by trying to log in to the standard
admin webapp, Tomcat floods the LDAP server with redundant search requests:

Feb 10 16:11:03 ldap slapd[10446]: conn=36 op=1 SRCH
base="dc=altkom,dc=pl,o=Altkom" scope=2 filter="(uid=someuser)"
Feb 10 16:11:03 ldap slapd[10446]: conn=36 op=1 SRCH attr=ou
Feb 10 16:11:03 ldap slapd[10446]: conn=37 fd=19 ACCEPT from IP=127.0.0.1:40390
(IP=0.0.0.0:389)
Feb 10 16:11:03 ldap slapd[10446]: conn=37 op=0 BIND dn="" method=128
Feb 10 16:11:03 ldap slapd[10446]: conn=37 op=0 RESULT tag=97 err=0 text=
Feb 10 16:11:03 ldap slapd[10446]: conn=37 op=1 SRCH
base="dc=altkom,dc=pl,o=Altkom" scope=2 filter="(uid=someuser)"
Feb 10 16:11:03 ldap slapd[10446]: conn=37 op=1 SRCH attr=ou
Feb 10 16:11:03 ldap slapd[10446]: conn=38 fd=21 ACCEPT from IP=127.0.0.1:40391
(IP=0.0.0.0:389)
Feb 10 16:11:03 ldap slapd[10446]: conn=38 op=0 BIND dn="" method=128
Feb 10 16:11:03 ldap slapd[10446]: conn=38 op=0 RESULT tag=97 err=0 text=
Feb 10 16:11:03 ldap slapd[10446]: conn=38 op=1 SRCH
base="dc=altkom,dc=pl,o=Altkom" scope=2 filter="(uid=someuser)"
Feb 10 16:11:03 ldap slapd[10446]: conn=38 op=1 SRCH attr=ou
Feb 10 16:11:03 ldap slapd[10446]: conn=39 fd=23 ACCEPT from IP=127.0.0.1:40392
(IP=0.0.0.0:389)
Feb 10 16:11:03 ldap slapd[10446]: conn=39 op=0 BIND dn="" method=128
Feb 10 16:11:03 ldap slapd[10446]: conn=39 op=0 RESULT tag=97 err=0 text=

Tomcat opens many parallel connections until it clogs the LDAP server.

Looks like it tries to do an asynchronous search (why not a synchronous one?),
and instead of checking back for results later, opens new connections and does
new searches in an infinite loop.

Expected behaviour: Tomcat should receive search results, and if an entry is
found, it should try to bind using that entry's DN.
If bind operation succeeds, it should assume that the user/password is correct
and the user has the roles corresponding to values of the "ou" attribute (if
present).

In my case the search for ou would return the following results:
dn: uid=someuser,dc=warszawa,dc=altkom,dc=pl,o=altkom
ou: tk
ou: edu
ou: tomcat

So after authentication successfully, someuser should have the roles "tk", "edu"
and "tomcat" in the webapp.

-- 
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: DO NOT REPLY [Bug 33358] - jasper2 bug because classloader-p roblems

[ops . bc]

Please stop your mail



-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 10, 2005 10:10 PM
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 33358] - jasper2 bug because classloader-problems


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=33358


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2005-02-10 15:10 ---
The bug is actually a duplicate of bug 33373.

*** This bug has been marked as a duplicate of 33373 ***

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


The message represents the personal views and opinion of the individual
sender and under no circumstances represents those of Hutchison Port
Holdings Limited ("HPH") or its Group Companies. The shareholders, directors
and management of HPH and any of its Group Companies accept no
responsibility and accordingly shall have no liability to any party
whatsoever with respect to the contents of this message.

This message (including any attachments) is intended only for the use of the
addressee(s) named above. It may contain information that is PRIVILEGED and
CONFIDENTIAL and should not be read, copied or otherwise used by any other
person.

If you are not the intended recipient, you are hereby notified that any use,
retention, disclosure, copying, printing, forwarding or dissemination of
this communication is strictly prohibited. If you have received this
communication in error, please erase all copies of the message and its
attachments and notify us immediately.

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

DO NOT REPLY [Bug 33489] New: - typo in uninstaller

[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=33489

   Summary: typo in uninstaller
   Product: Tomcat 5
   Version: 5.0.27
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: minor
  Priority: P3
 Component: Unknown
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


when insintalling, using the uninstall.exe, there is a typo , two words are 
attached "anythingyou" instead of "anything you"

-- 
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 33373] - jspc precompiling jsp with absolute uri in taglib fails

[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=33373


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2005-02-10 15:10 ---
*** Bug 33358 has been marked as a duplicate of this bug. ***

-- 
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 33358] - jasper2 bug because classloader-problems

[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=33358


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2005-02-10 15:10 ---
The bug is actually a duplicate of bug 33373.

*** This bug has been marked as a duplicate of 33373 ***

-- 
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 33358] - jasper2 bug because classloader-problems

[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=33358


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |ASSIGNED




-- 
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: [VOTE] Proposed API change to the Manager interface

[Remy Maucherat]

Rainer Jung wrote:
I have the impression you fixed the jvmRoute in the new Session(-Id) in
ManagerBase, but not in DeltaManager? Even when the context is
distributable one might prefer to stick the session to the node where it
now originates.
You mean the commented out code ? It would need to be cut & pasted to 
the delta manager. I had it originally in both managers.

Furthermore: I did not really understand the use case of emptySessionPath,
The use case is when something abuses cross context, such as a portlet 
container.

but want to indicate 2 problematic areas:
1) If the cookie contains an expired session(-id) then you would allow a
new session to be started with the old id. That is not a naive security
problem, because the session is empty, so authentication has to be done
again etc.
It is still tied to the same user, and as you said the object will be 
brand new. I don't understand why it is a problem.

But there is a more complex threat: Security of webapps relies on the
fact, that session ids are not easily guessable. Once you move into a
situation where a user might use the same session id for a very long time
(in fact different sessions) the id will loose it's security. Normally
it's hard to find out the id of a user session while the session is still
active. And the user can at every time end his session. If he is going to
use the same Id for many sessions you have a much better chance to get
knowledge about the id between sessions and then to just wait for a new
session to begin.
That's what I thought at first, but I actually don't think it's a problem.
There was nothing preventing from using a session for a very long time 
before, depending on the server settings. With the session space (128 
bits) we are using, it does not matter, the ids will be unguessable as 
soon as the random number generator is properly seeded.

And if you really care about security, use SSL ;)
2) There might be problems by putting an arbitrary string coming from an
uncontrolled Cookie and using it as a session id inside tomcat. I don't
know, if there is a way related to cross site scrpting or injection of
malicious code for cookies (of course I know, that there is no scripting
inside Cookies, but atackers are very ingenious nowadays). At least one
should check the string for formal correctness (e.g. containing only
letters and numbers or something similar).
Besides the cross scripting used with a URL, I am not aware of any valid 
cookie which would cause problems. Invalid cookies will not be parsed.

A global session id list is needed to verify the submitted id exists 
(across all contexts). I don't think such a list is worth it, though.

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

Missing scripts in Tomcat Windows installer distribution

[Stepan Herold]

Hi,
I would like to ask what was the motivation for removing the startup 
scripts  catalina.bat, setclasspath.bat, etc. from the Windows installer 
distribution of Tomcat 5.5.x?

Our NetBeans Tomcat integration currently relies on existence of those 
scripts and I believe that there are others with the same problem. It is 
also quite weird that when you install the full instalation using the 
Tomcat Windows installer, you'll get less than what you would get from 
the zip distribution.

Is there any chance that those scripts will get back into the distro? I 
guess that normal Tomcat users would also appreciate having those 
scripts back.

Thanks for your answers,
Stepan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Custom load balancing algorithm and mod_jk???

[Henri Gomez]

+1, that's what the original goal of AJP14, extending protocol from
just requests forwarding to service/system messaging.

BTW, we should disable it by default on jk, to avoid problem with old
tomcats release :)

On Thu, 10 Feb 2005 11:02:22 +0100, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Henri Gomez wrote:
> > Well we could provide the Tomcat load by many ways but I rather like
> > keep them compatible with AJP13 :
> >
> > - Add a new message from jk to tomcat, like the CPING/CPONG, to get
> > the expect load on tomcat. jk could decide to send this information
> > packet each X requests.
> >
> 
> IMO those kind of things are OK for occasional info needed.
> For AJP14 it will be used for topology discovery, and everything
> related to dynamic configuration.
> 
> > - Add a custom header in reply but this one should be decoded by jk in
> > response and removed from browser response.
> >
> 
> Yes, all runtime data that are closely bound to per-request basis,
> ie. have tendency to change frequently should be used with custom
> headers (or on AJP14 with extra tags), and removed from the
> pipeline of course.
> Things like warnings of Tomcat going down, or not accepting any
> new connections should be implemented in this fashion, because they
> are instant messages.
> Now that we have shared memory, the status will be visible across
> all child processes.
> 
> Regards,
> Mladen.
> 
> -
> 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: Custom load balancing algorithm and mod_jk???

[Mladen Turk]

Henri Gomez wrote:
Well we could provide the Tomcat load by many ways but I rather like
keep them compatible with AJP13 :
- Add a new message from jk to tomcat, like the CPING/CPONG, to get
the expect load on tomcat. jk could decide to send this information
packet each X requests.
IMO those kind of things are OK for occasional info needed.
For AJP14 it will be used for topology discovery, and everything
related to dynamic configuration.
- Add a custom header in reply but this one should be decoded by jk in
response and removed from browser response.
Yes, all runtime data that are closely bound to per-request basis,
ie. have tendency to change frequently should be used with custom
headers (or on AJP14 with extra tags), and removed from the
pipeline of course.
Things like warnings of Tomcat going down, or not accepting any
new connections should be implemented in this fashion, because they
are instant messages.
Now that we have shared memory, the status will be visible across
all child processes.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP@brutus]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-jk-native has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 9 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-jk-native :  Connectors to various web servers


Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: 
Build)
Work ended in a state of : Failed
Elapsed: 
Command Line: make 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native]
-
Making all in common
make[1]: Entering directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
/bin/sh 
/usr/local/gump/public/workspace/apache-httpd/dest-10022005/build/libtool 
--silent --mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-10022005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR 
-I/usr/local/gump/public/workspace/apr/dest-10022005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c 
/usr/local/gump/public/workspace/apache-httpd/dest-10022005/build/libtool: 
/usr/local/gump/public/workspace/apache-httpd/dest-10022005/build/libtool: No 
such file or directory
make[1]: *** [jk_ajp12_worker.lo] Error 127
make[1]: Leaving directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
make: *** [all-recursive] Error 1
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml
- Atom: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2510022005, brutus:brutus-public:2510022005
Gump E-mail Identifier (unique within run) #26.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

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

Re: Custom load balancing algorithm and mod_jk???

[Henri Gomez]

Well we could provide the Tomcat load by many ways but I rather like
keep them compatible with AJP13 :

- Add a new message from jk to tomcat, like the CPING/CPONG, to get
the expect load on tomcat. jk could decide to send this information
packet each X requests.

- Add a custom header in reply but this one should be decoded by jk in
response and removed from browser response.

The first method is simpler, the second may be cleaner and more
responsive since we could get the information in real time, ie at each
reply

On Thu, 10 Feb 2005 08:28:43 +0100, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Albrecht Rieger wrote:
> > hi Mladen,
> >
> > are you able to tell me, how to get rid of all this apache and tomcat
> > emails I get and I do definitely NOT want ?
> >
> 
> Sure, unsibscribe from the Tomcat Developer List.
> You or someone that is using your account subscribed to this list.
> 
> Here is how-to:
> http://jakarta.apache.org/site/mail2.html#Tomcat
> 
> Regards,
> Mladen.
> 
> -
> 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]