a reminder, only Tomcat committer votes are
> binding, but everyone else is welcome to voice their opinion.
>
[X] Stable - no major issues
Via local testing here
--
=======
Jim Jagielski [|] [EMAIL PROTECTED]
There's a bug report (37788) regarding allowing AprEndpoint
to use APR IPv6 addresses. Their patch is almost right, but
instead the value should be to use APR_UNSPEC instead
of APR_INET6 (or the current APR_INET) to allow APR
to correctly determine IP version and do a graceful
recovery... As well
Markus =?iso-8859-1?q?Sch=F6nhaber?= wrote:
>
> Jean-frederic Clere wrote:
> > Jean-frederic Clere wrote:
> > > Jim Jagielski wrote:
> > >> There's a bug report (37788) regarding allowing AprEndpoint
> > >> to use APR IPv6 addresses. Their p
On Jan 29, 2006, at 5:07 AM, Jean-frederic Clere wrote:
Jim Jagielski wrote:
There's a bug report (37788) regarding allowing AprEndpoint
to use APR IPv6 addresses. Their patch is almost right, but
instead the value should be to use APR_UNSPEC instead
of APR_INET6 (or the current APR_INE
On Feb 5, 2006, at 2:03 PM, Mark Thomas wrote:
My C is very rusty. I *think* this is OK and doesn't do anything
dangerous but I would be grateful if someone could review it.
It looks like this just handles the case where pfc->pFilterContext
isn't NULL, which means memory has already been all
Looking at the implementation in network.c, we can only leave
the loop upon a write error, in which case we return the
APR error (negative) or we've sent more (or the
exact same) as we've decided to send, which must
be positive. So it doesn't look like it, no. In
any case, the inf loop would be in
On Feb 10, 2006, at 6:14 AM, Mladen Turk wrote:
[EMAIL PROTECTED] wrote:
Author: mturk
protected long serverSockPool = 0;
-+
I have an editor that removes trailing spaces sorry :).
-long inetAddress = Address.info(addressStr,
Socket.APR_UNSPEC,
+int family = So
s
what APR does, I see no reason to back it out.
On Feb 10, 2006, at 9:42 AM, Mladen Turk wrote:
Jim Jagielski wrote:
httpd uses APR_UNSPEC pretty much exclusively.
Well, if the APR was compiled on a host that does not have
defined APR_HAVE_IPV6, then when passing APR_UNSPEC to
apr_socket_
I agree that the change is a big benefit, and for
most OSs we care about, SO_REUSEADDR is available.
The APR call should gracefully fail...
I'll plug this in later on today after some edge-case tests.
On Feb 23, 2006, at 11:02 AM, Fenlason, Josh wrote:
Remy or anyone else working on the native
On Feb 23, 2006, at 11:53 AM, Remy Maucherat wrote:
Jim Jagielski wrote:
I agree that the change is a big benefit, and for
most OSs we care about, SO_REUSEADDR is available.
The APR call should gracefully fail...
I'll plug this in later on today after some edge-case tests.
In AprEnd
On Feb 24, 2006, at 11:15 AM, Jim Jagielski wrote:
On Feb 23, 2006, at 11:53 AM, Remy Maucherat wrote:
Jim Jagielski wrote:
I agree that the change is a big benefit, and for
most OSs we care about, SO_REUSEADDR is available.
The APR call should gracefully fail...
I'll plug this in lat
On Mar 7, 2006, at 5:59 PM, Remy Maucherat wrote:
Yoav Shapira wrote:
Hola,
Let's all try to stay professional.
Then why do you selectively ignore this guy's blatant whining ?
Yaroslav or whomever else is interested: if you can produce a
patch that
(a) Can be turned on or off
(b) Is set
I'm thinking... the behavior we want is that non-Windows
OSs want the APR_SO_REUSEADDR before the bind; Windows
wants it after. So checking for (OS.IS_UNIX) at
one point (for the former) and then (OS.IS_WIN32 || OS.IS_WIN64)
(for the later) is misleading, and doesn't match what
we do elsewhere. So
On Mar 17, 2006, at 5:10 AM, Mladen Turk wrote:
Jim Jagielski wrote:
I'm thinking... the behavior we want is that non-Windows
OSs want the APR_SO_REUSEADDR before the bind; Windows
wants it after. So checking for (OS.IS_UNIX) at
one point (for the former) and then (OS.IS_WIN32 || OS.IS_
On Mar 17, 2006, at 5:27 AM, Peter Rossbach wrote:
The current os.c patch works well at mac os x. and currently the
IS_UNIX
flag is enough.
But my research for more mac os x system info is hard. Help is
needed...
ping me offline about OSX/Darwin.
--
+1 for current trunk.
On Mar 17, 2006, at 7:55 AM, Mladen Turk wrote:
Peter Rossbach wrote:
Hey Malden,
I have found one compile error:
Can be that we must use
jk_shmem.attached instead jk_shmem.hdr.attached ?
Right, a stupid copy/paste error from the testing
linux box to a windows one I'm
On Mar 17, 2006, at 12:38 PM, Remy Maucherat wrote:
Yoav Shapira wrote:
Alright, I'll cut out 5.5.17. When is the earliest time that's good
for you, i.e. you (everyone who's been discussing the native issues)
feel comfortable me cutting a release from trunk?
-0. These are quite minor issues
On Apr 5, 2006, at 1:04 PM, KARNATI, SRINIVASA R [AG/1000] wrote:
I would like to extend AJP buffer size (in
org.apache.jk.common.MsgAjp) as a
configurable option. We really needed the buffer above 8 kb
(because of
Kerberos integration.)
Here is the plan:
i) maxAJPBufferSize on connector
+1
On Apr 10, 2006, at 10:46 AM, Yoav Shapira wrote:
I'm also OK with Friday morning / afternoon. Should we tentatively
plan on Mladen cutting tcnative 1.1.3 and updating the installer
dependency Friday morning, and then me tagging and cutting 5.5.17
Friday afternoon? (All times GMT)
Yoav
O
The main idea is that once a tarball is placed in an
"official" download location, it should have the support
of the PMC behind it, and thus a vote. This is to avoid
people downloading it, using it, and considering it
as "really released" when it really isn't :)
However, 5.5.17 is noted as BETA s
Guys, can we keep this to *technical* discussions? A Veto
is a Serious Thing, and requires good solid reasons for it.
But the only arguments that have any weight are
technical ones, not personal or otherwise.
-
To unsubscribe, e-
Technical issues aside, refactoring of stable code is best
done in a SVN branch, so that it can be totally independent
of anything else. Thus, development can happen there,
people can see what is going on, and at some future
time decide on whether or not to merge that into
the then-current stable
On Apr 24, 2006, at 2:15 PM, Yoav Shapira wrote:
Hey dudes and dudettes,
Our test candidate v5.5.17-beta has been available for a little more
than a week now. I hope you've had time to test it. If so, please
vote on its stability below. If you haven't had time to test it, this
vote will run
Cool!
On May 8, 2007, at 11:05 AM, [EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk3/
ROADMAP?view=auto&rev=536215
==
--- tomcat/connectors/trunk/jk3/ROADMAP (added)
+++ tomcat/con
On May 17, 2007, at 7:46 AM, Remy Maucherat wrote:
Hi,
Because of the amount of proposed API changes, it could be a good
idea to start a new 6.x branch (with a short release cycle). Or is
it acceptable to do these in 6.0.x ?
The list would be:
- new Comet capabilities, with non blocking
On May 18, 2007, at 3:33 AM, Rainer Jung wrote:
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 f
On Jun 27, 2007, at 10:55 AM, Mladen Turk wrote:
jean-frederic clere wrote:
I have noted that nothing has happened in tomcat/connectors/trunk/
jk3.
Nearly 2 months without real road map nor clear specifications,
what is wrong?
I don't think anything is wrong. We are waiting for the list
On Jun 27, 2007, at 11:27 AM, jean-frederic clere wrote:
Rainer Jung wrote:
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
On Aug 2, 2007, at 1:42 PM, [EMAIL PROTECTED] wrote:
==
--- tomcat/connectors/trunk/jk/native/common/jk_ajp13.h (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp13.h Thu Aug 2
10:42:23 2007
@@ -45,7 +
So far, so good.
+1
On Aug 3, 2007, at 2:40 AM, Rainer Jung wrote:
Hi all,
unfortunately we had to withdraw mod_jk 1.2.24. It had a serious
regression bug. To ensure the quality of the new 1.2.25 we invite
you to actively participate in testing.
A code snapshot (revision 562250) is avai
On Aug 7, 2007, at 6:28 AM, Rainer Jung wrote:
Apache Tomcat Connectors 1.2.25 is:
[X] Stable - no major issues, no regressions
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Aug 2, 2007, at 4:29 PM, Rainer Jung wrote:
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 lik
:)
It just seemed like a conscious coding style and didn't want
to confuse things...
Or else it was some normal C array/pointer confusion :)
*duck*
On Aug 8, 2007, at 12:09 PM, Rainer Jung wrote:
You are missing nothing. Feel free to scratch :)
Regards,
Rainer
Jim Jagielski wrote:
O
On Aug 20, 2007, at 5:38 AM, Remy Maucherat wrote:
Since the community is a bit small, it could be useful to precise
that a single +1 (from the committer who proposes the commit) is
enough for a commit to go through, rather than the usual 3 +1s.
If the community is so small as to not b
On Aug 20, 2007, at 11:13 AM, Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
[X] +0 What revolution?
everything is backwards compatible, even Comet, if you take a
6.0.x comet app, it would work in trunk, there was just new
features added
Given the additional calls that were added,
On Aug 21, 2007, at 8:54 PM, Yoav Shapira wrote:
Hey,
On 8/21/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote:
Beyond withdrawing the silly vote, asking for the code you veto to be
removed, and moving forward, don't you think you should hold a
vote to
make trunk R-T-C first?
The latte
On Aug 22, 2007, at 9:32 AM, Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
and so the pissing contest begins, just in a different area.
ok, the so the only thing required for the fix is
1. available() call on the intermediate stream
2. make sure the B2CConverter uses while(available) in
On Aug 22, 2007, at 10:47 AM, Remy Maucherat wrote:
Jim Jagielski wrote:
IMO, code talks, bullshit walks. And I've been on both sides
of the argument many times in many places.
Yeah right.
And what do you mean by that? What is "Yeah right" about
me claiming to at times bei
On Aug 22, 2007, at 11:43 AM, David Jencks wrote:
While it's more fun to watch from the sidelines, I'm afraid I'll
have to get involved here to point out that you are wrong about
this. trunk contains an entirely new and incompatible with 6.0.x
annotation processing framework which is in
On Aug 27, 2007, at 7:36 PM, Mark Thomas wrote:
Filip Hanik - Dev Lists wrote:
Release candidate can be found at
http://people.apache.org/~fhanik/tomcat/tomcat-5.5/v5.5.25/
I will run the TCK tests on it, and then we can have a vote next
week,
Looks good so far on some basic tests.
+1
On Aug 30, 2007, at 11:45 AM, Mladen Turk wrote:
Rainer Jung wrote:
+/* Always do memcmp including the final \0-termination
character.
+ */
switch (header[0]) {
case 'A':
-if (memcmp(p, "CCEPT", 5) == 0) {
+if (memcmp(p, "CCEPT", 6) == 0) {
Rig
On Aug 30, 2007, at 12:46 PM, Rainer Jung wrote:
Jim Jagielski wrote:
On Aug 30, 2007, at 11:45 AM, Mladen Turk wrote:
Rainer Jung wrote:
+/* Always do memcmp including the final \0-termination
character.
+ */
switch (header[0]) {
case 'A':
-if
On Sep 3, 2007, at 2:06 AM, Mladen Turk wrote:
Mark Thomas wrote:
Hi,
Following on from my previous over eager attempt to clean up the
duplicate code in connectors I would like to propose the following
- remove connectors/trunk/ajp/CHANGES
- remove connectors/trunk/ajp/proxy
- move connectors/
On Sep 4, 2007, at 4:53 AM, jean-frederic clere wrote:
Hi,
I would also propose that we take an handling of release branches
similar to httpd.
The release branches are:
/tomcat/tc6.0.x/trunk
/tomcat/build/tc5.5.x/
/tomcat/container/tc5.5.x
/tomcat/jasper/tc5.5.x/
(Note it uses /tomcat/connec
On Sep 5, 2007, at 5:51 AM, Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
yes, it is also easily abused by folks who throw around vetoes as
often as I change underwear.
Ouch, that must smell.
I don't see a need to slow down development even further, at this
point if the previous v
On Sep 6, 2007, at 1:22 PM, Remy Maucherat wrote:
Most of the comments were that it was too annoying to do for casual
bugfixing, and it's true it's not justified for all patches. Maybe
a finer rule could be devised, something like using a RtisTC (tis =
the important stuff) model.
To gi
On Sep 6, 2007, at 1:39 PM, Mladen Turk wrote:
If you read my post I was careful enough to not mention the RTC
policy.
All I was saying is that current CTR caused too many problems,
because trunk was our stable branch, and disagreement on API
caused drastic things like putting trunk to sand
How about:
o CTR on trunk
o Various release branches are made (ala httpd, apr, etc...).
These include a STATUS file.
o All code applied to the release branch is under
lazy consensus but *must* be specified in STATUS.
(eg: "I plan on applying rev786987 in 3 days under
On Sep 10, 2007, at 8:00 PM, Mark Thomas wrote:
Jim Jagielski wrote:
How about:
o CTR on trunk
o Various release branches are made (ala httpd, apr, etc...).
These include a STATUS file.
o All code applied to the release branch is under
lazy consensus but *must* be
On Sep 10, 2007, at 4:47 PM, Remy Maucherat wrote:
The main idea is that since there's only one trunk branch, there
should be agreement on APIs and important topics to proceed
++1. So let's start that now. Since there is not agreement on APIs,
how do we proceed from here? Or, in other wo
On Sep 14, 2007, at 3:30 PM, Filip Hanik - Dev Lists wrote:
Costin Manolache wrote:
I'm not sure the security discussion is that simple, this seems
quite a
dangerous change.
Currently the user is restricted to the webapps/ directory
( well, he can
add a context
with the base in /etc an
On Sep 14, 2007, at 2:49 PM, Costin Manolache wrote:
It may also have some implications on other use cases - deployment
( the
current pattern
is that all files for a webapp are in one place ), replication
( i.e. if
someone wants same webapps
on a pool of servers ).
To me this is an im
On Sep 14, 2007, at 3:50 PM, Remy Maucherat wrote:
Jim Jagielski wrote:
On Sep 14, 2007, at 2:49 PM, Costin Manolache wrote:
It may also have some implications on other use cases -
deployment ( the
current pattern
is that all files for a webapp are in one place ), replication
( i.e. if
On Sep 14, 2007, at 4:27 PM, Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
Writing a portable webapp, is doable, and essentially has nothing
to do with the optional feature set in Tomcat. If you want a
portable webapp, simply don't use the non portable features in
Tomcat.
It's an
ve that with your 2nd statement about a simple
vote...
Thanks!
--
=======
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
---
http://marc.info/?l=tomcat-dev&m=118646143216543&w=2
> even offered to maintain a WIKI page for this, so that anyone could add
> their stuff to it.
Better late than never then. :)
--
=======
Jim Jagielski [|] [E
On Sep 14, 2007, at 11:08 PM, Bill Barker wrote:
Now, I'd prefer that TC is just the Servlet/JSP container
that it is meant to be, and not try to add on proprietary
features. But
that is just me ;).
Others too I think.
Open Source, esp open source at the ASF, has a long and useful
tradit
On Sep 19, 2007, at 10:43 PM, William A. Rowe, Jr. wrote:
If Joe says "this feature isn't going to be acceptable because Y",
well
then there isn't much to discuss at that point, and it probably
should be
backed out right away while the basic idea is debated.
Certainly it depends on wha
On Sep 19, 2007, at 10:28 PM, Bill Barker wrote:
And, yet again, Filip chooses to question the validity of the vote,
instead
of discussing ideas :(.
How can one vote when the details of what one is voting for
are still being discussed? Or, on the other hand, why call
for a (premature) vot
On Sep 19, 2007, at 10:55 PM, Bill Barker wrote:
TC 4.1.x and TC 5.5.x represented major changes to the core API, and
resulted in much more stable Tomcat code. There is no such issue
for TC
6.0.x (just a disagreement on the comet API, which we have already
dealt
with, and decided to let
On Sep 20, 2007, at 9:57 AM, Costin Manolache wrote:
On 9/20/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
On Sep 19, 2007, at 10:55 PM, Bill Barker wrote:
TC 4.1.x and TC 5.5.x represented major changes to the core API, and
resulted in much more stable Tomcat code. There is n
On Sep 21, 2007, at 4:45 AM, Henri Gomez wrote:
+1
RTC is a good idea for release and fixes.
Let's make use of RTC for release and CTR for more experimental code.
I agree. I think that no on can disagree that, more than
anything else, right now, more people will be focused on
patches, watc
On Sep 21, 2007, at 4:07 AM, jean-frederic clere wrote:
Filip Hanik - Dev Lists wrote:
It could be a simple as (as opposed to trying to reinvent the
apache way)
1. Through out a vote for the 6.0.x/5.5.x/5.0.x/4.1.x branches RTC
or CTR
Every one should why Sun had forked from Tomcat... I
Posted on another list, but adding it here with some
refinements:
If I had my druthers I'd say we have all release branches
created and set as RTC. We then follow a release
number similar to httpd and others where even number
minors are release, and odd numbers are development.
We then have a rea
On Sep 21, 2007, at 11:12 AM, Costin Manolache wrote:
I agree with the previous mail that for a while people will be
careful to
discuss and review - so probably we don't really need to do anything,
this long thread may have raised enough awareness.
Regarding release numbers - I also agree wi
On Sep 21, 2007, at 1:23 PM, Costin Manolache wrote:
I'm a bit confused - what happens with the trunk then ? Usually the
trunk will become the new release - or the code from the trunk will
somehow
get released.
There are 2 ways for code in trunk to get released:
1. trunk, the whole ki
On Sep 21, 2007, at 1:59 PM, Jim Jagielski wrote:
All good points. It just seems to me that the voting should be
on code that, as you said, affects people. When the code enters
a release branch, then approval is needed. The fact that it's
been in trunk and has worked well and that o
On Sep 21, 2007, at 2:13 PM, Jim Jagielski wrote:
Patches which would go to review would be:
- API changing patches (any protected or above signature change)
on APIs which are accessible to the user either from confirguration
or programmatically
- any other commit for which a
On Sep 21, 2007, at 2:46 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
So how about this... this is something that has been done, and
is being done, in just about every ASF project. Why don't
we vote on this and give it a time-table at which point we
review how it's worke
On Sep 21, 2007, at 3:10 PM, Costin Manolache wrote:
Let's assume CTR ( lazy consensus - i.e. assume everyone agrees ) -
what if
it
turns that the consensus is lacking, not on the technical validity
of the
change
but on weather a particular change is the right direction. Should
tomcat
On Sep 21, 2007, at 3:49 PM, Costin Manolache wrote:
Certainly the rest of the community out there in addition to the
PMC determines a lot of that. In which point, I think the
majority would rule.
Then I guess we are in agreement :-)
woo hoo!
Just propose a polite way to move from the
On Sep 21, 2007, at 4:27 PM, Costin Manolache wrote:
On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
Just propose a polite way to move from the commit for a
controversial
change ( i.e. when someone feels strongly it's going to the wrong
direction,
even
if technically code
ways,
normal ASF policies with some differences due to not understanding
all the normal aspects (like "formal review request")... Once
that was explained, I think, at least based on Costin's comments,
we have some sort of workable solution.
--
======
On Sep 21, 2007, at 4:36 PM, Jim Jagielski wrote:
On Sep 21, 2007, at 4:27 PM, Costin Manolache wrote:
On 9/21/07, Jim Jagielski <[EMAIL PROTECTED]> wrote:
Just propose a polite way to move from the commit for a
controversial
change ( i.e. when someone feels strongly it's g
On Sep 22, 2007, at 9:10 AM, Jim Jagielski wrote:
Remy Maucherat wrote:
Hi,
After all these discussions, I think the review model as I
proposed it
puts commonly agreed development processes in black & white, which
should help the project (while not hindering development in any way).
On Sep 22, 2007, at 9:45 AM, Jim Jagielski wrote:
[X] +1. Yes, the above works and addresses my concerns
as well as the problems which started this whole
thing.
[ ] 0. Whatever.
[ ] -1. The above does not work for the following reasons:
The vote will run for
Here is the synopsis:
o Existence of release and development branches
in parallel with each other (dev are odd numbered,
release are even numbered).
o Development branches are CTR. If code or patches
to this branch change the API, advanced warning
is required even before
Remy Maucherat wrote:
>
> Jim Jagielski wrote:
> >[X] +1. Yes, the above works and addresses my concerns
> >as well as the problems which started this whole
> >thing.
> >[ ] 0. Whatever.
> >[ ] -1. The above does not wor
Mladen Turk wrote:
>
> Jim Jagielski wrote:
> >
> >
> >[X] +1. Yes, the above works and addresses my concerns
> >as well as the problems which started this whole
> >thing.
> >[ ] 0. Whatever.
> >[ ] -1. T
Mark Thomas wrote:
>
> Jim Jagielski wrote:
> >[X] +1. Yes, the above works and addresses my concerns
> >as well as the problems which started this whole
> >thing.
> >[ ] 0. Whatever.
> >[ ] -1. The above does not work for t
I'd like to call a vote on acceptance of the above methodology,
as crafted and fine-tuned by Costin and myself. It is worthwhile
to note that, really, these are the typical ASF methods, but
with some "grainy" aspects better defined. In essence, some
typical "niceties" are now mandated (changes,
On Oct 5, 2007, at 8:07 AM, Remy Maucherat wrote:
Mark Thomas wrote:
Next attempt.
Taking account of the comments so far, a slightly modified
proposal is
below.
svn cp https://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk
https://svn.apache.org/repos/asf/tomcat/trunk
svn cp https://svn.apac
On Oct 5, 2007, at 11:42 AM, Rainer Jung wrote:
[EMAIL PROTECTED] wrote:
+* Fix explicit flush before response commit in the org.apache.jk
AJP connector.
+ http://svn.apache.org/viewvc?view=rev&revision=580815
+ + +1: remm
I admit, that I don't have a better solution, but nevertheless a
It doesn't seem like these suffered from the same
issues than core TC did though, so either way is cool.
On Oct 7, 2007, at 4:41 AM, Peter Rossbach wrote:
Hi Rainer,
I think we need a clear policy for all tomcat parts. Currently this
means that we
must also change the commit policy for jk a
On Oct 8, 2007, at 12:21 PM, Mark Thomas wrote:
Peter Rossbach wrote:
OK!
How we can easier promote and discuss those patches? You are
right, an
email threads are not easy to reference at STATUS file. Arrg!
I don't think that the apache developer home folder are the right
place
for tho
On Nov 6, 2007, at 7:37 PM, Rémy Maucherat wrote:
On Sun, 2007-11-04 at 16:10 +, Mark Thomas wrote:
Do the (unless there is a pressing need - eg a major security
issue) final
stable release of 6.0.x.
Freeze development of the 6.0.x branch.
-1. Branches should continue to be open as lon
+1
On Dec 15, 2007, at 4:41 AM, Peter Rossbach wrote:
Hi Filip,
good news :-) I am happy to test this features :-)
Regards
Peter
Am 14.12.2007 um 20:53 schrieb Filip Hanik - Dev Lists:
In the near future, I plan to add the following to trunk
1. annotation dependency injection patch
2. cl
On Dec 21, 2007, at 9:56 AM, Rainer Jung wrote:
Hi Tim,
Tim Whittington wrote:
There's one in particular that we feel is very useful that hasn't
been accepted though, which is the addition of chunked encoding
support to the ISAPI Redirector, which allows IIS to use HTTP keep
alives betwe
On Nov 24, 2006, at 3:06 PM, Mladen Turk wrote:
Rainer Jung wrote:
In my opinion the only change is:
- old code: retries=2 means first try to close all conns and
second try
with new connection
- new code: retries=2 means first try to close all conns and
immediate
new conn, second try a "
On Nov 28, 2006, at 9:36 AM, Mladen Turk wrote:
Remy Maucherat wrote:
-1 for enforcing any coding style (except tabs, since it can make
code unreadable very easily).
You must be joking, right?
One hopes...
-
To unsub
On Nov 28, 2006, at 10:44 AM, Remy Maucherat wrote:
Jim Jagielski wrote:
On Nov 28, 2006, at 9:36 AM, Mladen Turk wrote:
Remy Maucherat wrote:
-1 for enforcing any coding style (except tabs, since it can
make code unreadable very easily).
You must be joking, right?
One hopes...
Why
On Nov 28, 2006, at 3:55 PM, Rainer Jung wrote:
From a very personal view I'm tempted to share Mladens dislike of
trailing spaces. If I try to express, why I don't like them, then
it all
comes back to diffs.
Same here. Maybe 3/4 of a year ago I cleaned up the entire httpd
codebase removin
On Dec 11, 2006, at 5:00 AM, Mladen Turk wrote:
Hi,
I'll tag the 1.1.8 later today and put the distro files in regular
places, so they can be used for Tomcat builds.
BTW, can we again consider to use the minimum version required
to that version (1.1.8).
Although the API is compatible with 1.1
On Dec 16, 2006, at 8:16 AM, Rainer Jung wrote:
Apache Tomcat Connectors 1.2.20 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
On Jan 18, 2007, at 6:53 AM, Remy Maucherat wrote:
http://people.apache.org/~remm/tomcat-6/v6.0.8/
Votes ?
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Don't we also have a HPUX11 specific check like
the 2nd line after this one? Seems consistent to me :/
On Feb 2, 2007, at 12:14 PM, Rainer Jung wrote:
Hi Jean-Frederic,
shouldn't we be able to find out about the necessity to include it
via configure? At least HP-UX should be able to use the
On Feb 2, 2007, at 12:36 PM, Rainer Jung wrote:
I can't test on HP-UX, but maybe you (jfc) could try:
-#if !defined(_OSD_POSIX) && !defined(AS400) && !defined(CYGWIN)
&& !defined(HPUX11)
+#if !defined(_OSD_POSIX) && !defined(AS400) && !defined(CYGWIN)
&& !defined(HAVE_SYS_SOCKETVAR_H)
#in
On Feb 3, 2007, at 2:38 PM, Ted Husted wrote:
Or,
1. create tarball and unofficial binaries, put them on
people.apache.org/~remm/tomcat-6
2. call for alpha/beta/stable vote on build
3. wait 72 hours
4. if 3 +1's and more +1s than -1s, publish previously created tarball
and binaries to www.apac
efined(AS400)
#include
#endif
#endif
Of course you would need to rebuild configure via buildconf.sh after
changing configure.in.
Regards,
Rainer
Jim Jagielski wrote:
Don't we also have a HPUX11 specific check like
the 2nd line after this one? Seems consistent to me :/
On Feb 2, 20
On Feb 4, 2007, at 3:41 PM, Remy Maucherat wrote:
Hi,
I propose the following release process for Tomcat 6.0.x:
1. create tarball and unofficial binaries, put them on
people.apache.org/~remm/tomcat-6
2. announce candidate binaries are available for testing
3. wait 2-3 days for testing
4. c
1 - 100 of 269 matches
Mail list logo
