Hi,
who is going to attend ApacheCon next week?
I will be there the whole time starting saturday. I would very much like
to meet the tomcat developers attending the conference. So, who will be
there and which days will you be attending?
I've got no idea how many of you know each other personally
attribute to "https" for an SSL Connector. The default value is "http".
See SSL Support for more information.
Rainer Jung
Tino Schwarze wrote:
On Thu, Feb 16, 2006 at 03:24:52PM -0800, Casey Haakenson wrote:
We have a customer who is hitting our web GUI through a fairly
c
Hi Mladen,
are you sure? I have the impression default is
c->options = JK_OPT_FWDURIDEFAULT;
and
#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPAT
#define JK_OPT_FWDURICOMPAT 0x0001
but needed is
#define JK_OPT_FLUSHPACKETS 0x0020
It looks like JK_OPT_FLUSHPACKETS is o
.
Mladen Turk wrote:
Rainer Jung wrote:
Hi Mladen,
are you sure? I have the impression default is
I meant that the '+' is default:
if (action == '-') {
conf->options &= ~opt;
}
else if (action == '+') {
conf->options |= opt;
}
else {
Hi Filip, hi all developers,
I think TC clustering from a users perspective got more robust in the
last two years. Whe we started playing around with it in 2004 it was
great, that we all basic functionality already worked, but you might
remember, that I contributed a couple of fixes to make De
Hi Filip,
thanks for taking it seriously!
1. If we don't primary/secondary will not be available until TC.6
> 3. Many people are opting out of clustering today because of lack of
> primary/sec. all-to-all is too inefficient for the general public
I understand your primary motivation. It#s tru
Hi Remy,
1. If we don't primary/secondary will not be available until TC.6
2. TC 6 doesn't have a skeleton nor a date yet.
It could have that tomorrow.
...
I agree with Peter: it's obvious no one should be doing major
refactoring of existing components in 5.5.x. You could create a separate
+1 (non-binding)
Filip Hanik - Dev Lists wrote:
+1 from myself
Filip Hanik - Dev Lists wrote:
Sounds like there is a consensus amongst folks. So to summarize
everyones thoughts, let me know if this sounds like a solution
agreeable to everyone.
1. Keep 5.5.x as a maintenance module as it was
: http://svn.apache.org/viewcvs?rev=380835&view=rev
Log:
Fix for bug
http://issues.apache.org/bugzilla/show_bug.cgi?id=38740
looks like we got trigger happy with the resetDeltaRequest
Thanks to Nick Wesselman and Rainer Jung that pointed this out.
Modified:
tomcat/container/tc5.5.x/mod
Hi,
I started to trace TC cluster with DTrace. I did a first simple exam for
the mcast subcomplex. CPU usage and especially elapsed times might be
slightly larger than expected, because I used the more intrusive
extended DTrace probes.
All tests were done with JDK 1.6.0 build 72 on Solaris 10 SP
e way too
many synchronized calls locking down the sockets, the code is somewhat
cluttered then I am gonna move on to serialization. In the current
cluster module, too much gets serialized, in the new module "ha" I have
already removed a lot of serialization and will continue stripping it out.
I have a small patch that I think improves the session listing in the
manager webapp:
The doc says
Session Statistics
Display the default session timeout for a web application, and the
number of currently active sessions that fall within ten-minute ranges
of thei
Hi Remy,
I saw you taking over classes from commons modeler into tc 6. Just
yesterday William Barker commited a very small and non-risky patch I
submitted two years ago to bugzilla against Registry.convertValue():
http://issues.apache.org/bugzilla/show_bug.cgi?id=31608
The method has convers
While playing around with svn checkout of mod_jk trunk (1.2.16-dev) I
saw, that in jk/native/configure.in there is still a line
VERSION=1.2.14
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [
eems to be relevent for distribution
building, which Mladen said does not exist. So we might be able to throw
it out completely.
Mladen Turk wrote:
Rainer Jung wrote:
While playing around with svn checkout of mod_jk trunk (1.2.16-dev) I
saw, that in jk/native/configure.in there is still a line
Some hints, although I didn't go deeper into it and most of it might
still be experimental:
1) Java Isolate API JSP-221
http://java.sys-con.com/read/99716.htm
http://jcp.org/en/jsr/detail?id=121
2) Building on top Java Resource Consumption Management API JSR-284
http://jcp.org/en/jsr/detail?
I logged a bug a couple of days ago:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39218
Since nobody gave any response, I wanted to ping the list.
The current implementation of the server, common and shared class
loaders use the catalina.properties file to make the group of
repositories
svn: Commit failed
...
403 Forbidden (http://svn.apache.org)
Seriously: I would like to, but I'm only a contributor :)
Remy Maucherat wrote:
Rainer Jung wrote:
I logged a bug a couple of days ago:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39218
I found this was a reaso
Hi List, hi Mladen (master of mod_jk):
a year ago we changed to algorithm in mod_jk, that "counts" weighted
requests in the lb worker to decide, which balanced worker should
receive the next request.
The new algorithm three main advantages:
a) using only integers
b) using only a limited rang
Good news.
Will you cut another mod_jk version close to 5.5.17 (it will be to late
for that one), or are you planning to keep 1.2.16 in development for at
least 1-2 weeks further on?
In any case I will prepare a patch.
Any other comments?
Mladen Turk wrote:
Rainer Jung wrote:
Hi List, hi
OK, I expect to send the patches late Friday german time (tomorrow, but
in 3 minutes today).
Mladen Turk wrote:
Rainer Jung wrote:
Good news.
Will you cut another mod_jk version close to 5.5.17 (it will be to late
for that one), or are you planning to keep 1.2.16 in development for at
least 1
Hi Mladen,
I've got another one for that file. You optimized the original Solaris
contribution by changing division with a value to multiplication with
the reciprocal value. Unfortunately we are in integer land and the
divisor was bigger than 1, so now we always multiply by 0 :(
Patch attached a
I sent a patch for the Solaris part of tcnative to Mladen and the list
this morning which is not yet included. The Bug is *not* critical (CPU
used and idle in the manager status page for Solaris will be 0 always).
Rainer
Yoav Shapira wrote:
Hi,
Is tcnative 1.1.3 ready? The default build prop
Peter Rossbach wrote:
Yes, thing a real refactoring must start at ManagerBase. Then we get a
better interface for easier subclassing Manager like DeltaManager at
existing cluster and ha modules and other implementation like JBoss.
I thing we have now some options:
a) Refactoring at tomcat 5
Apache Tomcat v5.5.17 is:
[X] Stable - no major issues
Tested with Java 1.6.0-beta2-b72 under Solaris 10 with a simple 2 node
cluster in fastasync mode.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e
What about commented out entries for the admin and manager roles and
resp. users and password set to "changeme"?
Peter Rossbach wrote:
Yes, defaults are very fine, but secret parameter need active user
interaction.
also -1
Peter
Am 28.04.2006 um 11:54 schrieb Remy Maucherat:
Mladen Tu
I'm wondering if we should split the (possibly huge) char arrays in
BodyContentImpl into smaller chunks of char arrays. Each chunk will be
able to grow big enough to handle the usual cases efficiently (e.g.
64KB). Whenever a bigger size is needed we allocate more of these chunks
from a pool. Af
Hi,
Remy started a thread talking about source tree reorg. It soon turned
into a discussion about various integration questions.
I would be interested in discussing a couple of questions concerning TC
6, most of them already came up during the last week. I hope it's not to
much shortly befor
- Dev Lists wrote:
Remy Maucherat wrote:
Rainer Jung wrote:
I'm wondering if we should split the (possibly huge) char arrays in
BodyContentImpl into smaller chunks of char arrays. Each chunk will
be able to grow big enough to handle the usual cases efficiently
(e.g. 64KB). Whenever a bigg
So people think it TC 6 should be focused on JEE 5 compatibility and
other major changes should only be done, if they pose no risk on an
early date. Somehow we are to late in the J2EE time frame.
On the other hand, major changes to e.g. the configuration management
should not be done for a rel
From my understanding PageContextImpls are pooled, but not the JSP
output (body). Those are written using JspWriterImpls that buffer only
8KB of output.
If you are using tags, then their content is kept in a char array inside
BodyContentImpls. Each (pooled) PageContextImpl has a stack of these
Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
Rearrange configure.in, such that in case we
got with-apxs we detect CC from apxs and warn,
if the CC environment variable differs.
Is this really needed?
I mean having that the apxs wouldn't work for
any custom module thought.
I think that instead
Mladen Turk wrote:
Rainer Jung wrote:
Still vetoing?
No, I just said that I don't like the way we
try to fix other peoples faults.
I'm sure it would leads us to no where pretty soon.
What I'm saying is that the problem you fixed
is not something all of our users are seeing.
I didn't follow this, but the comment in the httpd 2.x module code says:
/*
* The 2.2 servlet spec errata says the uri from
* HttpServletRequest.getRequestURI() should remain encoded.
* [http://java.sun.com/products/servlet/errata_042700.html]
*
* We use JkOptions to
Why do you think the default is bad?
Because it breaks the spec's and allows unexpected handling of url that
are encoded (for example: /context-A/%252E%252E/context-B that is send
to Tomcat as /context-A/%2E%2E/context-B and mapped by Tomcat
as /context-B).
So what how do you suggest to handle
Hello to all Tomcat project members,
mod_jk 1.2.23 is available for testing under
http://tomcat.apache.org/dev/dist/tomcat-connectors/jk/
It has been created from a branch based on 1.2.22 with only one code
change (default forwarding option for Apache httpd module) and the
corresponding clari
Apache Tomcat Connectors 1.2.23 is:
[X] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what it is
[ ] Alpha - multiple significant issues -- tell us what they are
Tested on Linux 64 Bit.
-
Hi,
I think Yoav might have misunderstood your suggestion. I interprete the
branch you posted as the one, you suggest to use for the maintenance of
the existing 6.0.x source and to use trunk to proceed with working on
annotations, comet etc.
What I would find a little strange, would be using
We received five stable votes (Mark, Mladen, Günter, Jim and me) and no
other votes.
Since we should do this release quick, I'm now starting to publish the
release.
Thanks to everyone who helped in immediate testing!
Regards,
Rainer
The Apache Tomcat team is pleased to announce the immediate availability
of version 1.2.23 of the Apache Tomcat Connectors.
It contains connectors, which allow a web server such as Apache HTTPD,
Microsoft IIS and Sun Web Server to act as a front end to the Tomcat web
application server.
This ver
Hi,
now that we changed the default way how to forward URIs from mod_jk to
Tomcat (mod_jk 1.2.23) because of a directory traversal issue, I want to
propose a better long term solution.
What's the problem?
===
- Access control is often defined in terms of URI prefixes, because
Mladen Turk wrote:
My proposal is that we make our own decoder if the URI is encoded
and then do a match and forward that.
As far as I understand you suggestion, this would not help.
There's nothing wrong with "our" decoder (the httpd decoder), what's
wrong is, that the decoded URI gets decod
Jean-Frederic wrote:
On Sat, 2007-05-19 at 14:27 +0200, Rainer Jung wrote:
Hi,
now that we changed the default way how to forward URIs from mod_jk to
Tomcat (mod_jk 1.2.23) because of a directory traversal issue, I want to
propose a better long term solution.
What's the pr
Mladen Turk wrote:
You got me wrong. I suggest we decode the encoded uri, do mapping,
remove ;jsessionid=xxx and send that to the Tomcat.
This way tomcat won't have double encoding issue.
And it's completely legitimate if we comply to the RFC.
This would also solve malicious mapping attempts lik
Jean-Frederic wrote:
What about url like /context-a/../context-b/?
There could be a problem if the goal is not to map /context-b.
Should we normalise /context-a/../context-b/ to /context-b and then do
the mapping.
If the *original* URI is "/context-a/../context-b/" then apache httpd
normalizes
Mladen Turk wrote:
Jean-Frederic wrote:
What about url like /context-a/../context-b/?
There could be a problem if the goal is not to map /context-b.
Should we normalise /context-a/../context-b/ to /context-b and then do
the mapping.
Yes. It would require some programming of course, but
it'll
Look, what I'm saying is that we should simplify all the JkOptions
ForwardURI* . IMHO they all originate from the fact that uri in the Apache
can come from multiple pre-processing stages that modify the original
URI. The solution is very simple but it would require that we write
the URI decoder. W
Mladen Turk wrote:
Rainer Jung wrote:
OK Mladen, I understand that, but I think it's not correct.
Might be.
But: none of the existing options does the right thing. That's why I
suggested another way of handling the forward. I think my sugeggested
variant "forward r-&g
Maybe that helps: mod_proxy_ajp (httpd 2.2.4) does something very similar.
In mod_proxy_ajp.c function proxy_ajp_canon() calls ap_proxy_canonenc().
This function for a reverse proxy request does encode a couple of chars
in the already decoded URI before forwarding it. It encodes all chars
exce
Before I answer, let me first ask a question: What's wrong withg my
suggestion? Or even better: use the encoding done with mod_proxy_ajp?
Original URI:
/myapp/%252e%252e/otherapp/danger
JkMount /myapp/*
Apache httpd will correctly decode the URI to
/myapp/%2e%2e/otherapp/danger
mod_jk does
I'm trying to follow this thread, I hope i'm not duplicating things.
Mark Thomas wrote:
Guenter Knauf wrote:
this makes me ask a couple of questions:
Remember we only *have* to make the source available. Anything we do
on the binary front is just being helpful and the release manager is
unlike
I fixed this (BZ 42459) now in r539895.
Remy Maucherat wrote:
Tim Funk wrote:
The only 2 things I noticed (which aren't a big deal)
The index pages had a bad links to the docs. (Now fixed)
The status screen has a rendering bug when a webapp is stopped. I
didn't have a chance to dig into it -
Then I found on the main docu page:
http://tomcat.apache.org/connectors-doc/
that there are direct links to the previous source versions, but all end up in
a 'NOT FOUND';
should we change these to point to the archive now?
I would point all of these to the download pages. We should never
include
Jean-Frederic wrote:
On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote:
Before I answer, let me first ask a question: What's wrong withg my
suggestion? Or even better: use the encoding done with mod_proxy_ajp?
For me there is nothing wrong except it adds 2 JKoptions or 3 :-)
If we
Well thinking to it I am not very happy with the change:
+++
-#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPATUNPARSED
+#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURIESCAPEDMINIMAL
+++
Because that is what the SPEC's says.
I doubt, that the SPEC is very relevant for the reverse proxy s
Jean-Frederic wrote:
On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote:
Before I answer, let me first ask a question: What's wrong withg my
suggestion?
Well thinking to it I am not very happy with the change:
+++
-#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPATUNPARSED
+#d
Why do you think, that
/myapp/%252e%252e/otherapp/danger
is equivalent to
/myapp/../otherapp/danger ?
Because it is on the Tomcat side and it ends up
as /otherapp/danger.
No it is not. If you send
/myapp/%252e%252e/otherapp/danger
to Tomcat, it will map the URL into the /myapp context (wh
William A. Rowe, Jr. wrote:
Rainer Jung wrote:
I had no permissions to delete them, I'll write to the owners directly
to remove them.
You can often find someone with root perms hanging out on #asfinfra on
irc.freenode.net, or can email [EMAIL PROTECTED] to ask for perms to be
reset to 6
Mladen Turk wrote:
It is part of Tomcat release and that shouldn't change.
Each tomcat release has a detection of the Tomcat native, and
it prints out the suggested version compared with the one user is
running.
For 6.0.13 the required version is 1.1.8 and recommended
is 1.1.10 and that is clear
Hi,
this while mail only concerns non Win and non Netware platforms.
Our detection of multi-threading during configure for mod_jk is broken.
We rely on the fact, that APR set -D_REENTRANT during build for
multi-threaded APR. But in fact
- APR doesn't set it for various platforms including AI
William A. Rowe, Jr. wrote:
Rainer Jung wrote:
I checked installed Apache httpd to find out, how we could detect the
threading model of the apache httpd against we compile. Unfortunately we
can only find out the name of the MPM, but not (at least not in a robust
way) if it is threaded or not
Henri Gomez wrote:
BTW, configure fail since some release and can't works with apx2-mpm
(The SLES apxs2 for mpm mode). I located the problem in configure and
will report it later.
Yes, let me know.
BTW, on i5/OS, the -D_REENTRANT is forced in module compilation.
OK, so my proposal wouldn't
T -D_XOPEN_SOURCE=500 -D_BSD_SOURCE
-D_SVID_SOURCE -D_GNU_SOURCE -DAP_DEBUG -I /usr/lib/java/include -I
/usr/lib/java/include/ -c jk_connect.c -o jk_connect.lo
2007/5/31, Rainer Jung <[EMAIL PROTECTED]>:
> Henri Gomez wrote:
> > BTW, configure fail since some release and can't wo
Could you try to find out, how pthread_t is defined on OS X?
Does the following patch help?
Index: jk_util.c
===
--- jk_util.c (revision 542900)
+++ jk_util.c (working copy)
@@ -1686,12 +1686,87 @@
pthread_getunique_np(&t, &
- Lots of Tomcat talks at ApacheCon EU Amsterdam (Filip, Mladen)
- 2 mod_jk releases (1.2.22, 1.2.23), 1.2.23 was a security release
Yoav Shapira wrote:
... by June 18th at the latest, because the Board meeting is on June
20th. But since I'll be leaving the country on vacation the preceding
wee
Sorry for being offline for 2 weeks :(
Sorry for the long post coming :((
I just now read the URL rewriting discussion. Although the discussion
seems to have come to an end, I find it worthwhile to actually add some
structure to it:
1) How to forward the URL
I already suggested a different f
Jess,
I didn't really carefully think about the case of a saturated pool. But
nevertheless some hints:
1) There is always one thread waiting for the accept, which is a usual
pool thread. So an offset of one between threeads processing requests
and the pool size is normal.
2) There is no or
Date: Wed Jun 20 19:21:36 2007
New Revision: 549328
URL: http://svn.apache.org/viewvc?view=rev&rev=549328
Log:
Allow for large-file support on downloads as well as uploads.
Reported By: Rainer Jung
Modified:
tomcat/connectors/trunk/jk/java/org/apache/coyote/ajp/AjpAprProcessor.java
to
Not really: I tested >4GB downloads. Instead of setContentLength() you
can also setHeader for "Content-Length". Then you have the freedom to
format a larger number, because this API takes strings. It works for me.
Regards,
Rainer
Tim Whittington wrote:
This would limit dynamic (servlet) resp
After all the discussions I did some commits today to produce a
consistent URi handling result for the Apache, IIS and Netscape connectors.
Here is the summary:
1) How do the web servers pass URLs to the plugins?
- Apache: decoded, normalized
- Netscape: decoded, normalized
- IIS: original URL
Whenever I had a couple of hours I was doing small tests with scripting.
I think the most valuable first step would be the transformation to APR.
Unfortunately this is something I could hekp with, but I wouldn't want
to lead, because my experience with APR programing is only medium.
Once APR woul
Just in case anyone likes to make his words persist: Mladen created a
roadmap file some weeks ago which includes the basic thoughts we
(Mladen, Jean-Frederic and me) had during ApacheCon about bigger JK
improvements.
/tomcat/connectors/trunk/jk3/ROADMAP
Regards,
Rainer
Remy Maucherat schrieb:
>
I'll test sometime during this week and will vote then. Sorry for not
responding faster/earlier. I really appreciate that you are doing the
release work, because 5.5 still needs to be supported in a reliable way.
Filip Hanik - Dev Lists wrote:
if we want this release to go out, we need folks to
Hi,
implementing a management communication between the lb and the backend
is on the roadmap for jk3. It is somehow unlikely, that this will help
in your situation, because when doing a GC the jvm will no longer
respond to the management channel. Traditional Mark Sweep Compact GC is
not disti
OK, this culd make sense, i.e. heap nearly full on node1 failover to
other cluster member node2 (replcation assumed) and trigger GC by
System.gc() on node1. Interesting idea ... (for JK3 and beyond).
Yefym Dmukh wrote:
Mladen wrote:
This won't help much. The sticky session requests must be se
I'm not sure. They provide an easy entry point for people using Tomcat
because it is so simple to just use them. There are a couple of choices:
- leave the examples in the download and take their security serious.
This is what we do now.
- leave the examples in the download, but don't bother
Hi all,
The next version of mod_jk is approaching its release. A code snapshot
(revision 59730) is available at:
http://people.apache.org/~rjung/mod_jk-dev/
It is in the same format as a release download, so easy to build.
Under the same URL you can find the updated documentation.
It would b
Hi,
we had exactly 10 downloads of our quality check tarball since the
announcement yesterday. Three of the testers reported back positively
(one of them via direct mail), no reports were negative. Since I
received already a lot of positive feedback from the preceding internal
testing (6 test
Hello to all Tomcat project members,
JK 1.2.24 has been available for testing for some days as a svn
snapshot. Only very small bugs have been found and fixed. So I would
like to proceed with the release vote.
If you want to take a look, the final source distribution can be
downloaded from:
Yoav Shapira wrote:
Hey,
On 7/27/07, Rainer Jung <[EMAIL PROTECTED]> wrote:
JK 1.2.24 has been available for testing for some days as a svn
snapshot. Only very small bugs have been found and fixed. So I would
like to proceed with the release vote.
The bugs were fixed and 1.2.24 retagge
Forwarding for Günter Knauf, his provider is blacklisted
on tomcat-dev at the moment, so he sent it to me directly.
Original Message
Hi,
Apache Tomcat Connectors 1.2.24 is:
[X] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what
Hi,
I updated the link for Bugzilla on the JK docs to Tomcat 6.
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%206
Now I noticed, that Tomcat 6 has no longer a JK:Native component.
Furthermore nearly all of the old components are gone.
Only two components are there: "catalina
Yoav Shapira wrote:
Catalina
Catalina:Cluster
Catalina:Modules
Connector:AJP
Connector:Coyote
Connector:HTTP
Jasper
Native:Integration
Native:JK
Native:Packaging
Servlet & JSP API
Servlets:CGI
Servlets:SSI
Servlets:WebDAV
Tester
Unknown
Webapps:Administration
Webapps:Documentation
Webapps:Example
Rainer Jung wrote:
So here's the vote. Because we already had several days of testing, the
vote will be closed on Monday July 30, 24:00 GMT.
Apache Tomcat Connectors 1.2.24 is:
[X] Stable - no major issues, no regressions
[ ] Beta - at least one significant issue -- tell us what
We received six stable votes (Henri, Yoav, Mladen, Peter, Günter and me)
and no other votes.
I'm now starting to publish the release.
Thanks for supporting this release.
Regards,
Rainer
-
To unsubscribe, e-mail: [EMAIL PROTE
The Apache Tomcat team is pleased to announce the immediate availability
of version 1.2.24 of the Apache Tomcat Connectors.
It contains connectors, which allow a web server such as Apache HTTPD,
Microsoft IIS and Sun Web Server to act as a front end to the Tomcat web
application server.
This ver
98549 -50
53111 Bonn www.kippdata.de
HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417
Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann
===
kippdata
informationstechnologie GmbH Tel: +49 228 98549 -0
Bornheimer Str. 33aFax: +49 228 98
David Blevins wrote:
My personal opinion: java.util.logging very much lacks a good
formatter. The default 2 line formatting of messages, splitting
timestamps and message in separate lines, is not really useful in
production. Many ad hoc log analysis practices work on a line oriented
basis.
W
ainer
Remy Maucherat wrote:
Rainer Jung wrote:
That's why it would be nice if someone took the burden of writing a
better log formatter for j.u.l.
What should it look like ?
Rémy
Object[] getParameters()
Get the parameters to the log message.
Reso
calls the setters oneself (or use juli).
Regards,
Rainer
Remy Maucherat wrote:
Rainer Jung wrote:
That's why it would be nice if someone took the burden of writing a
better log formatter for j.u.l.
What should it look li
That's why it would be nice if someone took the burden of writing a
better log formatter for j.u.l.
Got it. Yea, that format is certainly grep unfriendly.
Looks like Harmony has a formatter we could copy from and fix to not add
the new line.
http://svn.apache.org/repos/asf/harmony/enhanced/
Hi,
OK with me. I've one outstanding patch related to fail on status. I
think Ben short is testing today. I wrote mails about it to the user
list and the patch is not committed yet. It's
http://people.apache.org/~rjung/mod_jk-dev/patches/fail-on-status.patch
(in short: fail on status has to
Hi Mladen,
I don't full yunderstand this fix. From your other mail i though it's a
regression, but the code in this region is the same at least since
1.2.18 (more than a year). So I have the impression, that this is not a
regression. If so, I would prefer to not push 1.2.25 through with very
e code was supposed to let httpd produce the error
page in case we got an error status without any content. But: for a 401
we actually do get a body content from tomcat. So in fact something is
wrong with sent_bodycnt. I'll investigate.
Regards,
Rainer
Mladen Turk wrote:
Rainer Jung wrote:
Update: The problem seems to be coming from a global change of AS400
defines, which unintentionally also hit two ifndefs, which were
transformed into ifdefs. As a result, we didn't flush any more, so small
responses were not flushed before we came to the line checking
sent_bodyct. That way the
I think the problem with JK 1.2.24 is big enough to release soon. I
would also suggest to officially withdraw 1.2.24 from the download and
web site (with a comment indicating the problem) so that people will not
run into more complex problems related to the missing flush. Although
we've got no
I withdrew the release from the server:
- removed 1.2.24 source and binaries from www.apache.org/dist/...
- put back 1.2.23 source and binaries from archive
- reverted the download page and added a warning
- added a withdrawal note to the index and news page in the live online
docs.
It will ta
The Apache Tomcat team needs to withdraw release 1.2.24 of the Apache
Tomcat Connectors.
The release contains a bug that prevents the correct flushing of parts
of responses from the web server to the client. This might result in
unpredicted communication behaviour. We therefore have removed th
for a
JdkLoggerFormatter that would do
the trick. I may have forgot to add it, I have it on my machine ( I hate too
the default format ).
There's also a config override allowing default properties to be loaded from
a different location.
Costin
On 8/2/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:
R
And in fact it doesn't matter. I found it more logical, to have
JK_STATUS_ERROR and JK_STATUS_FATAL_ERROR closer together (for those
reading the code). The constants are not used outside JK, so there is no
compatibility problem.
It looks like your are closely following todays JK changes. I rea
1 - 100 of 2105 matches
Mail list logo
