Re: Tomcat sandbox

[Mladen Turk]

Costin Manolache wrote:

You mean to remove the 'single tree', and only have components ? I can live
with this,
but I don't think it's the best idea - and I haven't seen any reasons for
that.

The idea of the sandbox is that you can try things in it - including the
single source tree :-)



Right. But in a way to have multiple projects in the sandbox.
It changes nothing for a code you have in there right now.
Instead
/tomcat/sandbox/
the current code should be moved to something like
/tomcat/sandbox/tc6lite/ or what ever.

Its still the single source tree :)

OTOH it would allow to have experimental
/tomcat/sandbox/foo/ project also as a single source tree.

Regards,
Mladen.

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

svn commit: r417361 - /tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c

[mturk]

Author: mturk
Date: Tue Jun 27 00:29:42 2006
New Revision: 417361

URL: http://svn.apache.org/viewvc?rev=417361&view=rev
Log:
Make sure we are in the correct mix/max range.

Modified:
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c

Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c?rev=417361&r1=417360&r2=417361&view=diff
==
--- tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c Tue Jun 27 
00:29:42 2006
@@ -2212,7 +2212,7 @@
 i, elapsed, (int)(difftime(time(NULL), 
rt)));
 }
 }
-if ((cnt - n) < aw->ep_mincache_sz) {
+if ((cnt - n) <= aw->ep_mincache_sz) {
 if (JK_IS_DEBUG_LEVEL(l)) {
 jk_log(l, JK_LOG_DEBUG,
 "reached pool min size %u from %u cache slots",



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

Re: svn commit: r415813 - in /tomcat/sandbox/java/org/apache/tomcat/util/modeler: ./ modules/

[Remy Maucherat]

Costin Manolache wrote:
We could - but since JMX is in JDK anyway, I don't think it's that 
important

to
wrap it or not have a code dependency. Wrapping won't make it lighter at
runtime :-)


I thought you wanted to provide a modeler implementation using a more 
lightweight component model for your mini Tomcat.



I should just clean up the few places where jmx is abused ( i.e. used as an
introspection
equivalent in normal code paths ). It's use should be limitted to
'management' - i.e. configure and get runtime info.


I liked your earlier idea of removing all direct dependencies.

Rémy


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

DO NOT REPLY [Bug 39496] - Servlet mapping fails for subdirectory requests when subdirectory exists

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2006-06-27 09:29 ---
Hi,

I think the underlying problem is this: Tomcat nowadays deploys *any* directory
contained in the Host's appBase as a webapp. This has nothing to do with
localhost or not, which you can validate by using the same test-webapp described
above, but outside the "webapps"-Directory, e. g.






and then look at the webapps on this host. There is "/" and "/subdir", the
latter of which should not be there. This behaviour is the same if you use
localhost instead of testdomain.com, the difference was caused by the fact that
localhost has appBase="webapps", which does not contain a directory "subdir", so
the virtual mappings can pass unhindered by erroneously deployed webapps.


I dug through the sources and found that version 5.5.12 has these lines in
org.apache.catalina.startup.HostConfig.deployDirectories()
// Make sure there is an application configuration directory
// This is needed if the Context appBase is the same as the
// web server document root to make sure only web applications
// are deployed and not directories for web space.
File webInf = new File(dir, "/WEB-INF");
if (!webInf.exists() || !webInf.isDirectory() ||
!webInf.canRead())
continue;

I don't know when or why they were removed, but this clearly is the reason for
the new behaviour -- which I consider unwanted and wrong. Please do tell if
there is a rationale for auto-deploying *all* directories, regardless if they
are, in fact, a webapp; I at least can't see a reason to do so.

As a workaround I suggest using an empty directory as the Host's appBase, and
then putting absolute paths as the Context's docBases. This way, there simply
won't *be* any extra subdirectories for Tomcat to deploy.

Wolfgang

-- 
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 39909] New: - Tomcat as Windows service issues http error 404

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

   Summary: Tomcat as Windows service issues http error 404
   Product: Tomcat 5
   Version: 5.5.17
  Platform: Other
OS/Version: Windows Server 2003
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


For Tomcat version 5.5.16 AND 5.5.17 ONLY the Windows service version, gives 404
errors.  When the application version (tomcat5.exe) is run -NOT as a service-
There is no problem.  With no changes to any config.

Windows version: Server 2003 Enterprise Edition [version 5.2 build
3790.srv03_rtm.030324-2048]
JVM version: JDK 1.5.06

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

svn commit: r417457 - in /tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector: CoyoteAdapter.java InputBuffer.java OutputBuffer.java Request.java Response.java

[remm]

Author: remm
Date: Tue Jun 27 06:48:36 2006
New Revision: 417457

URL: http://svn.apache.org/viewvc?rev=417457&view=rev
Log:
- As redoing the encoders and decoders won't happen immediately, save some 
memory by cleaning the
  cache when starting a Comet request (which is supposed to last for a while).

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/InputBuffer.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/OutputBuffer.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?rev=417457&r1=417456&r2=417457&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java 
Tue Jun 27 06:48:36 2006
@@ -241,6 +241,11 @@
 if (!comet) {
 request.recycle();
 response.recycle();
+} else {
+// Clear converters so that the minimum amount of memory 
+// is used by this processor
+request.clearEncoders();
+response.clearEncoders();
 }
 }
 

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/InputBuffer.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/InputBuffer.java?rev=417457&r1=417456&r2=417457&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/InputBuffer.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/InputBuffer.java 
Tue Jun 27 06:48:36 2006
@@ -237,6 +237,14 @@
 
 
 /**
+ * Clear cached encoders (to save memory for Comet requests).
+ */
+public void clearEncoders() {
+encoders.clear();
+}
+
+
+/**
  * Close the input buffer.
  * 
  * @throws IOException An underlying IOException occurred
@@ -493,6 +501,5 @@
 }
 
 }
-
 
 }

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/OutputBuffer.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/OutputBuffer.java?rev=417457&r1=417456&r2=417457&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/OutputBuffer.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/OutputBuffer.java 
Tue Jun 27 06:48:36 2006
@@ -228,6 +228,14 @@
 
 
 /**
+ * Clear cached encoders (to save memory for Comet requests).
+ */
+public void clearEncoders() {
+encoders.clear();
+}
+
+
+/**
  * Close the output buffer. This tries to calculate the response size if 
  * the response has not been committed yet.
  * 

Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java?rev=417457&r1=417456&r2=417457&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Request.java Tue 
Jun 27 06:48:36 2006
@@ -357,8 +357,10 @@
  */
 protected String localName = null;
 
+
 // - Public Methods
 
+
 /**
  * Release all object references, and initialize instance variables, in
  * preparation for reuse of this object.
@@ -424,6 +426,14 @@
 
 }
 
+
+/**
+ * Clear cached encoders (to save memory for Comet requests).
+ */
+public void clearEncoders() {
+inputBuffer.clearEncoders();
+}
+
 
 //  Request Methods
 

Modified: tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java?rev=417457&r1=417456&r2=417457&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/connector/Response.java Tue 
Jun 27 06:48:36 2006
@@ -286,6 +286,14 @@
 }
 
 
+/**
+ * Clear cached encoders (to save memory for Comet requests).
+ */
+public void clearEncoders() {

svn commit: r417471 - /tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/membership/MemberImpl.java

[fhanik]

Author: fhanik
Date: Tue Jun 27 07:27:46 2006
New Revision: 417471

URL: http://svn.apache.org/viewvc?rev=417471&view=rev
Log:
don't print out the entire payload

Modified:

tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/membership/MemberImpl.java

Modified: 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/membership/MemberImpl.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/membership/MemberImpl.java?rev=417471&r1=417470&r2=417471&view=diff
==
--- 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/membership/MemberImpl.java
 (original)
+++ 
tomcat/container/tc5.5.x/modules/groupcom/src/share/org/apache/catalina/tribes/membership/MemberImpl.java
 Tue Jun 27 07:27:46 2006
@@ -342,15 +342,23 @@
 buf.append(port).append(", alive=");
 buf.append(memberAliveTime).append(",");
 buf.append("id=").append(bToS(this.uniqueId)).append(", ");
-buf.append("payload=").append(bToS(this.payload)).append(", ");
+buf.append("payload=").append(bToS(this.payload,5)).append(", ");
 buf.append("]");
 return buf.toString();
 }
-
 public static String bToS(byte[] data) {
+return bToS(data,data.length);
+}
+public static String bToS(byte[] data, int max) {
 StringBuffer buf = new StringBuffer(4*16);
 buf.append("{");
-for (int i=0; data!=null && i

svn commit: r417473 - /tomcat/container/tc5.5.x/modules/groupcom/VERSION

[fhanik]

Author: fhanik
Date: Tue Jun 27 07:32:12 2006
New Revision: 417473

URL: http://svn.apache.org/viewvc?rev=417473&view=rev
Log:
fixed MemberImpl.toString method

Modified:
tomcat/container/tc5.5.x/modules/groupcom/VERSION

Modified: tomcat/container/tc5.5.x/modules/groupcom/VERSION
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/modules/groupcom/VERSION?rev=417473&r1=417472&r2=417473&view=diff
==
--- tomcat/container/tc5.5.x/modules/groupcom/VERSION (original)
+++ tomcat/container/tc5.5.x/modules/groupcom/VERSION Tue Jun 27 07:32:12 2006
@@ -1,3 +1,5 @@
+0.9.3.2
+  - MemberImpl.toString has a limit on the size it prints out
 0.9.3.1
   - fixed a bug in the startup sequence. If the local member gets created, 
then we need to set the unique Id
   - default multicast packet can be 8kb



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

Who maintains jsvc ?

[Darryl Miles]

If my research is correct this the commons-daemon package ?

I'm looking to find out if a patch to add network support to the 'jsvc' 
program would be a welcome enhancement.  I would like to be able to 
reboot a JVM remotely in a development environment.  This is a building 
block in some larger work I am trying to do to enable IDE based 
development to be network transparent for the entire development 
process.  The function is very similar to the shutdown port (within TC) 
but it works over UDP.  Commands are cryptographically protected via a 
shared secret (the password) and a request/challenge/response cycle is 
needed to issue instructions to jsvc.  In some ways it is much more 
useful than inside jsvc than tomcat because it has the ability to 
forcefully kill of the TC JVM if/when things get out of hand (especially 
true in the development environment).


I have got a proof of concept patch for jsvc running tomcat on 
linux/unix, the patch adds support and provide a simple network client 
from the command line bundled with the jsvc build.  If this is thought 
to be a useful addition that would get approval for inclusion I will 
happily work on porting it to windows as well.


I do not intend to make network support enabled by default (you'd have 
to specify it in a cmdline option).  You'd have to configure a shared 
secret to use it.


At the moment it is built on top of OpenSSL for the secure hash 
implementation the simple protocol uses, however this dependency can 
probably be avoided if a public domain version of SHA1 (or MD5) was 
bundled instead.


Who/where do I approach on this matter.

Your thoughts and pointers in the right direction,

Thanks

Darryl


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

DO NOT REPLY [Bug 39914] New: - crash in ap_log_rerror() from jk_log_to_file()

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

   Summary: crash in ap_log_rerror() from jk_log_to_file()
   Product: Tomcat 5
   Version: 5.5.16
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Native:JK
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


mod_jk-1.2.15, httpd-2.0.52 with RH ES4 patches applied running on RH ES4 
update 3.

I haven't figured out what the root cause of this is:
  jk_log_lock doesn't appear to get initialized, so both the lock and the
  unlock fail with EINVAL (presumably coming from pthread_mutex_{lock,unlock}
()).
  The unlock error case calls ap_log_rerror() with a NULL request pointer, but
  this routine dereferences the pointer immediately to pick up the server
  information, causing a core dump.  I changed it to ap_log_error() and that
  fixes the crash.

  I still don't know why the mutex is not initialized; I can only assume that
  the post config hook is not being called or is failing for some reason.

Let me know if any further information is needed.

-- 
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 39914] - crash in ap_log_rerror() from jk_log_to_file()

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





--- Additional Comments From [EMAIL PROTECTED]  2006-06-27 19:58 ---
Generally this works.

I assume you are using the worker MPM and a 32Bit Linux?

If the lock could not be initialized correctly, we would expect at least one of
the following messages with levels:

mod_jk: could not init JK log lock in child (ERROR)
mod_jk: could not create jk_log_lock (CRITICAL)
mod_jk: Could not set permissions on jk_log_lock; check User and Group
directives (CRITICAL)

Any of these in you mod_jk-Log?

Just to make sure, could you also give the exact messages from the failed
lock/unlock.

Concerning ap_log_rerror: you are right, I will correct to ap_log_error for the
upcoming 1.2.16.

As always: any chance to test with 2.0.58 and Subversion HEAD of mod_jk?

Finally: Could you provide the following things form inside your Apache home:

bin/httpd -V
include/apr.h
include/apr.h


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

mod_jk release plan

[Rainer Jung]

Hi,

I would like to start releasing mod_jk 1.2.16 this week.

Since our last release was done from CVS and there are several updates 
to the tool chain (autoconf/automake/m4/libtool), there is some risk of 
breaking the release (additionally to mod_jk code bugs).
For that reason I would propose to tag as 1.2.16-rc1, because we might 
need to have a second try on releasing it.


So I would propose, that I will

- take the role as RM for mod_jk 1.2.16
- tag mod_jk soon as 1.2.16-rc1
- roll a tarball and inform the dev- and user-list about availability of 
a release candidate and invite to test it.

- in case of negative testing: fix, retag as rc2, reroll etc.
- after positive testing start the vote
- after positive voting copy the final rc-tag to 1.2.16 and reroll the 
final release containing the right version numbers.

- finally announce the official release

Any comments?

Rainer


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

DO NOT REPLY [Bug 39914] - crash in ap_log_rerror() from jk_log_to_file()

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





--- Additional Comments From [EMAIL PROTECTED]  2006-06-27 20:31 ---
Created an attachment (id=18541)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18541&action=view)
apr.h


-- 
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: mod_jk release plan

[Mladen Turk]

Rainer Jung wrote:

Hi,

I would like to start releasing mod_jk 1.2.16 this week.

Any comments?



+1

--
Mladen.

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

DO NOT REPLY [Bug 39914] - crash in ap_log_rerror() from jk_log_to_file()

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





--- Additional Comments From [EMAIL PROTECTED]  2006-06-27 20:48 ---
What I have realized now is that these messages are only coming out in between
   "graceful restart requested, doing restart" 
and
   "Apache configured -- resuming normal operations"
and only if a request is in progress during the graceful restart.  A normal
'apachectl graceful' does not produce this.

My ignorance of APR is vast since I only got sucked into this yesterday,
but since jk_log_lock is a global mutex, perhaps it is being cleaned up
during the restart by global_mutex_cleanup()?

I do not see any of the errors you list in the log.
[Tue Jun 27 13:19:41 2006] [notice] Graceful restart requested, doing restart
[Tue Jun 27 13:19:41 2006] [error] (22)Invalid argument:
apr_global_mutex_lock(jk_log_lock) failed
[Tue Jun 27 13:19:41 2006] [error] (22)Invalid argument:
apr_global_mutex_lock(jk_log_lock) failed
[Tue Jun 27 13:19:41 2006] [error] (22)Invalid argument:
apr_global_mutex_lock(jk_log_lock) failed
[Tue Jun 27 13:19:41 2006] [error] (22)Invalid argument:
apr_global_mutex_lock(jk_log_lock) failed
[Tue Jun 27 13:19:41 2006] [error] (22)Invalid argument:
apr_global_mutex_lock(jk_log_lock) failed
...
...
[Tue Jun 27 13:19:42 2006] [notice] Apache configured -- resuming normal 
operations

 httpd -V 
[EMAIL PROTECTED] logs]# /usr/sbin/httpd -V
Server version: Apache/2.0.52
Server built:   Dec 15 2005 04:09:14
Server's Module Magic Number: 20020903:9
Architecture:   32-bit
Server compiled with
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D HTTPD_ROOT="/etc/httpd"
 -D SUEXEC_BIN="/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"


apr.h added as an attachment.

-- 
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: mod_jk release plan

[David Rees]

On 6/27/06, Rainer Jung <[EMAIL PROTECTED]> wrote:

- take the role as RM for mod_jk 1.2.16
- tag mod_jk soon as 1.2.16-rc1
- roll a tarball and inform the dev- and user-list about availability of
a release candidate and invite to test it.
- in case of negative testing: fix, retag as rc2, reroll etc.
- after positive testing start the vote
- after positive voting copy the final rc-tag to 1.2.16 and reroll the
final release containing the right version numbers.


Why not do releases like tomcat/httpd do it? Go ahead and
rollup/release 1.2.16, then vote on the stability. If there are
problems, roll up another release (1.2.17) for more testing. Repeat
until you have a tarball that is ready for production, that way you
still don't risk the chance of breaking something when you re-tag the
non-rc release and rebuild the tarball (however small that chance may
be) because if you do, you'll have to bump the version number and
re-release anyway.

-Dave

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

Re: mod_jk release plan

[Mladen Turk]

David Rees wrote:

On 6/27/06, Rainer Jung <[EMAIL PROTECTED]> wrote:

- take the role as RM for mod_jk 1.2.16
- tag mod_jk soon as 1.2.16-rc1


Why not do releases like tomcat/httpd do it? Go ahead and
rollup/release 1.2.16, then vote on the stability. If there are
problems, roll up another release (1.2.17) for more testing.


Right, release numbers are cheap.
We are number 16 after so many years after all :)

Anyhow, just release 1.2.16, and if its broken
make 1.2.17.

Regards,
Mladen.


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

DO NOT REPLY [Bug 39914] - crash in ap_log_rerror() from jk_log_to_file()

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2006-06-27 20:56 ---
If the problem is only occuring during graceful restart it's most likely BZ
39834. I noticed a mutex error when reproducing 39834 to. Should be fixed by
Mladen in Subversion HEAD and in the soon to come 1.2.16. 

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

-- 
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 39834] - JkLogLevel debug causes Segmentation fault

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




--- Additional Comments From [EMAIL PROTECTED]  2006-06-27 20:56 ---
*** Bug 39914 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]

svn commit: r417586 - /tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c

[rjung]

Author: rjung
Date: Tue Jun 27 14:04:59 2006
New Revision: 417586

URL: http://svn.apache.org/viewvc?rev=417586&view=rev
Log:
Use ap_log_error instead of ap_log_rerror when we don't know, whether we are in 
a request context.

Modified:
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?rev=417586&r1=417585&r2=417586&view=diff
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Tue Jun 27 14:04:59 
2006
@@ -2192,8 +2192,8 @@
 }
 rv = apr_global_mutex_unlock(jk_log_lock);
 if (rv != APR_SUCCESS) {
-ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, NULL,
-  "apr_global_mutex_unlock(jk_log_lock) 
failed");
+ap_log_error(APLOG_MARK, APLOG_ERR, rv, NULL,
+ "apr_global_mutex_unlock(jk_log_lock) 
failed");
 /* XXX: Maybe this should be fatal? */
 }
 }



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

svn commit: r417587 - /tomcat/connectors/trunk/jk/native/TODO

[rjung]

Author: rjung
Date: Tue Jun 27 14:05:40 2006
New Revision: 417587

URL: http://svn.apache.org/viewvc?rev=417587&view=rev
Log:
Clean up todo list.

Modified:
tomcat/connectors/trunk/jk/native/TODO

Modified: tomcat/connectors/trunk/jk/native/TODO
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/TODO?rev=417587&r1=417586&r2=417587&view=diff
==
--- tomcat/connectors/trunk/jk/native/TODO (original)
+++ tomcat/connectors/trunk/jk/native/TODO Tue Jun 27 14:05:40 2006
@@ -114,11 +114,11 @@
 not hold true for millisecond time, but in several cases we use the time,
 it's not very critical, that it is exact. These cases are related to:
 
+Some of this is already been done, the remaining parts are:
+
 - last_access for usage against timeout value that is ~minutes
 - error_time for usage against retry timeout that is ~minutes
-- maintain_time for usage against transfer division interval, that is ~minutes
 - uri_worker_map checked for usage against JK_URIMAP_RELOAD=1 minute
-- check against worker_maintain_time which is ~minutes
 
 So I think, it would suffice to set an actual time at the beginning of
 the request/response cycle (used by everything before the request is being
@@ -127,8 +127,6 @@
 
 For which cases would it be OK, to use the time before sending to TC:
 - uri_worker_map "checked" (uri map lookup starts early)
-- maintain (starts in front of the request)
-- "now" inside retry_worker could be taken from the calling maintain
 - setting/testing last_access in
   - jk_ajp_common.c:ajp_connect_to_endpoint()
   - jk_ajp_common.c:ajp_get_endpoint()



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

Re: mod_jk release plan

[Henri Gomez]

+0

2006/6/27, Mladen Turk <[EMAIL PROTECTED]>:

David Rees wrote:
> On 6/27/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
>> - take the role as RM for mod_jk 1.2.16
>> - tag mod_jk soon as 1.2.16-rc1
>
> Why not do releases like tomcat/httpd do it? Go ahead and
> rollup/release 1.2.16, then vote on the stability. If there are
> problems, roll up another release (1.2.17) for more testing.

Right, release numbers are cheap.
We are number 16 after so many years after all :)

Anyhow, just release 1.2.16, and if its broken
make 1.2.17.

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: mod_jk release plan

[David Rees]

On 6/27/06, Mladen Turk <[EMAIL PROTECTED]> wrote:

Right, release numbers are cheap.
We are number 16 after so many years after all :)

Anyhow, just release 1.2.16, and if its broken
make 1.2.17.


I'll be sure to give it a test on Linux and IRIX once the tarball is rolled. :-)

-Dave

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

Re: mod_jk release plan

[Yoav Shapira]

Hi,
+1 to Rainer's general plan, +0 to making release numbering / release
candidate approach consistent with Tomcat.

Yoav

On 6/27/06, David Rees <[EMAIL PROTECTED]> wrote:

On 6/27/06, Mladen Turk <[EMAIL PROTECTED]> wrote:
> Right, release numbers are cheap.
> We are number 16 after so many years after all :)
>
> Anyhow, just release 1.2.16, and if its broken
> make 1.2.17.

I'll be sure to give it a test on Linux and IRIX once the tarball is rolled. :-)

-Dave

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





--
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
[EMAIL PROTECTED] / www.yoavshapira.com

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

Re: Who maintains jsvc ?

[Jean-frederic Clere]

Darryl Miles wrote:



If my research is correct this the commons-daemon package ?


jakarta-commons (See http://jakarta.apache.org/commons/daemon/)



I'm looking to find out if a patch to add network support to the 
'jsvc' program would be a welcome enhancement.  I would like to be 
able to reboot a JVM remotely in a development environment.  This is a 
building block in some larger work I am trying to do to enable IDE 
based development to be network transparent for the entire development 
process.  The function is very similar to the shutdown port (within 
TC) but it works over UDP.  Commands are cryptographically protected 
via a shared secret (the password) and a request/challenge/response 
cycle is needed to issue instructions to jsvc.  In some ways it is 
much more useful than inside jsvc than tomcat because it has the 
ability to forcefully kill of the TC JVM if/when things get out of 
hand (especially true in the development environment).


There is an example in daemon see 
http://svn.apache.org/viewvc/jakarta/commons/proper/daemon/trunk/src/samples/SimpleDaemon.java




I have got a proof of concept patch for jsvc running tomcat on 
linux/unix, the patch adds support and provide a simple network client 
from the command line bundled with the jsvc build.


Add a issue and put it as attachement

Cheers

Jean-Frederic

  If this is thought to be a useful addition that would get approval 
for inclusion I will happily work on porting it to windows as well.


I do not intend to make network support enabled by default (you'd have 
to specify it in a cmdline option).  You'd have to configure a shared 
secret to use it.


At the moment it is built on top of OpenSSL for the secure hash 
implementation the simple protocol uses, however this dependency can 
probably be avoided if a public domain version of SHA1 (or MD5) was 
bundled instead.


Who/where do I approach on this matter.

Your thoughts and pointers in the right direction,

Thanks

Darryl


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

DO NOT REPLY [Bug 39909] - Tomcat as Windows service issues http error 404

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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE




--- Additional Comments From [EMAIL PROTECTED]  2006-06-28 00:41 ---


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

-- 
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 39787] - Tomcat 5.5.16 cannot serve pages (http status404) on Windows Server 2003

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





--- Additional Comments From [EMAIL PROTECTED]  2006-06-28 00:41 ---
*** Bug 39909 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]