Hi,
Seems there is low interest on JK 1.2.15 although it resolves
lots of issues compared with released 1.2.14.1 :(
So far, seems only Henri voted +1 (I hope I read his vote
properly).
Do you guys find something that would prevent 1.2.15 to
be declared as stable that I'm missing?
If not,
William A. Rowe, Jr. wrote:
Do you guys find something that would prevent 1.2.15 to
be declared as stable that I'm missing?
I'll try to find cycles to test myself, next week. I know I'm having
alot of trouble with the apache 1.3 build on odd architectures, probably
because the clash of a
Fenlason, Josh wrote:
Hey everybody!
I'm trying to build the native apr connector from Tomcat 5.5.12 on HPUX
Itanium and I'm running into a problem during the configure. APR 1.2.2
built fine. I built OpenSSL 0.9.8a as a static library (I couldn't get
it to build as a shared library.)
Have
The Apache Tomcat team is pleased to announce the release of
version 1.2.15 of the Apache Tomcat mod_jk web server connector.
Tomcat is the reference implementation of a web application server
which implements the Java Servlet and JavaServer Pages specifications.
mod_jk is a connector which
Remy Maucherat wrote:
Costin Manolache wrote:
NIO is used AFAIK by Jetty and Resin, and probably others. And it's
the 'standard'
solution for select-like operations ( even if the standard is as usual
not the best solution ).
I think we need to organize a community vote then, so that I do not
Jess Holle wrote:
Mladen Turk wrote:
So, from my point of view I see this vote as useless, because
anyone can create a connector using what ever technology he prefers.
The only valid question would be, what to use as a default one,
but that's a minor issue thought.
As Mladen says, anyone
Yoav Shapira wrote:
I'm planning to do it at 9am my time, which is 1400h UTC/GMT tomorrow,
December 6th.
Perfect.
By that time the mirrors will pick up
the new tomcat-native-1.1.1.tar.gz.
Regards,
Mladen.
-
To unsubscribe,
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: mturk
Date: Mon Dec 5 08:29:19 2005
New Revision: 354093
URL: http://svn.apache.org/viewcvs?rev=354093view=rev
Log:
Use tomcat-native-1.1.1 version.
Modified:
tomcat/build/tc5.5.x/build.properties.default
Remy Maucherat wrote:
There are a couple problems remaining:
- the AprEndpoint should be updated to require version number 1.1.1 (I
did it, but see point 2)
- the binaries on the Ireland download site
(http://tomcat.heanet.ie/native/1.1.1/) are still numbered 1.1.0, so the
AprEndpoint check
Andre Gebers wrote:
Hi,
newer versions of opera send the Cookie2-header along with the
Cookie-header which looks somewhat like this:
Right, but the patch would not work.
It would be a security hole, because the http rfc
diferentiates cookie from cookie2.
Right now the Cookie2 header is
Bill Barker wrote:
I agree that the patch is simply masking the real problem. With the current
mod_jk code what Tomcat sees is:
Cookie: myCookie=1234
Cookie: $Version=1
Huh, looking at the source I see the problem.
we are using:
'if (memcmp(p, OOKIE, 5)'
so both cookie and cookie2
Bill Barker wrote:
Without actually checking, mod_jk/mod_proxy_ajp should only send an
unrequested initial bodyChunk if the client sends a CL. So if there is no
CL, Tomcat will send back GET_BODY_CHUNK message, and act on the response
from Httpd/IIS/SunOne.
For reading initial body
Marsh David W Maj AFIT/ENG wrote:
Tomcat Developers,
While I understand that the libraries and extensions used by Tomcat
*should* provide that assurance, what would happen if someone
inadvertently wrote some code that could create a new object with rights
never intended by developers?
What I
Marsh David W Maj AFIT/ENG wrote:
What I would consider useful is a 'compile time note'
There would have to be a way to capture design intent through explicit
markers (or perhaps an inference) identifying both the protected code
and those code segments that are allowed to access the protected
Yoav Shapira wrote:
[X] Stable - no major issues
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bob Herrmann wrote:
seems you need both ant1.5 and ant1.5 to compile tomcat 5.0
Come one :)
I think you have a serious problems with your setup.
If you first run ant1.5 (from a clean setup) you will get this error,
Well, lots of us are building Tomcat on a daily basis, so
I would
Hi,
There was lots of changes for Tomcat Native that needs a
new tag and release bump.
1. IPV6 support fix
2. Bind fix
3. sendb(b) fixes
I would like to tag the TOMCAT_NATIVE_1_1_2 later this
evening. Any objections?
Regards,
Mladen.
Tim Funk wrote:
I see the point of the native dir.
Right, anything but bin is OK.
lib/native/{platform}/ !-- any needed .so, or dll files
This makes sense too, even more then my proposed /native.
Although I doubt the (platform) would make sense, unless
we decide to ship the bins for all
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_bind fails for 0.0.0.0 address.
Seems that 0.0.0.0 is not acceptable with APR_UNSPEC.
Further then
Jim Jagielski wrote:
That's an APR bug you're hitting; it hits some httpd
sites as well, and we have a work-around documented
about that. I need to check on the status of
the fix in APR and which version the bug
exists.
In any case, your changes simply perform
a safe-enough test, so, even
Eric Lenio wrote:
All -
Apologies in advance if this should go to tomcat-users but I'm
suspecting a problem with the way the source code is being distributed
so I'm starting here.
I downloaded the source file for 5.5.15 and built it. After installing
it I ran bin/version.sh which said I had
[EMAIL PROTECTED] wrote:
char sb[TCN_BUFFER_SZ];
if ((ss = (*s-net-recv)(s-opaque, sb, nbytes)) == APR_SUCCESS)
-(*e)-SetByteArrayRegion(e, buf, offset, (jsize)nbytes, sb);
+(*e)-SetByteArrayRegion(e, buf, offset, (jsize)nbytes,
(jbyte*)sb);
This
Eric Lenio wrote:
Well if the RM must generate this file for each release
perhaps then it could be added to subversion?
That way any time 'svn update' is used to refresh sources
the current Tomcat version can be known.
Right, it might be useful to split the build.properties.default
to two
Pelikan Stephan wrote:
Hello,
I detected that the FlushPackets JkOption does not work. I could solve
the problem by the patch
FlushPacket works, and the patch is invalid.
The service ws_flush is invoked from ajp_common.
In theory there can be problems if there
is no content_body packets,
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 { /* for now +Opt == Opt */
conf-options |= opt;
}
So
George Sexton wrote:
This assumes that committers are an practically unlimited
resource, and they
Of course we have, because we actually own the Intellectual Property.
You are forgetting that we have PMC (Project Management Committee),
that is responsible to deal with all administrative
Jean-frederic Clere wrote:
Sure... But my question was more why are the permission not ok in the
tar file?
Because I messed up ;)
They probably should have svn:executable set on them at some point.
Right.
Regards,
Mladen.
Yoav Shapira wrote:
The Apache Tomcat Team has voted to certify v5.5.16 as stable.
Binding +1 votes were cast by Mladen Turk, Peter Rossbach, Remy
Maucherat, Henri Gomez, Jeanfrancois Arcand, and myself.
Just figured out that the 5.5.16 was shipped with tomcat-native-1.1.1,
and it should
Jean-frederic Clere wrote:
Hi,
One of the patches I need to get TC working with JSP in EBCDIC is the
following:
Any comments?
Yes. Fix your clock. You live in the future :)
Cheers,
Mladen.
-
To unsubscribe, e-mail:
Yoav Shapira wrote:
Hola,
The one thing I don't want to do is repackage 5.5.16. The do nothing
option is viable, as is just sending a message (ideally a response to
my stable vote announcement) to the mailing lists saying by the way,
it's stable but it has native 1.1.1 just fyi. If you want to
José Iván González Vidal wrote:
Hi!!
I´m begining to use the apache-tomcat-5.5.16, I install it and start the
service but , when I try to open the page: http://127.0.0.1:8080 it doesn'
found, and if I go to see the process who are opening ports this doesn´t
open the port 8080...
!!!
William A. Rowe, Jr. wrote:
Fenlason, Josh wrote:
I should have checked this before the vote for 5.5.16 was closed, but I
just realized that in 5.5.16 the native connector is still at 1.1.1.
Question, does TC-Native 1.1.1 share the same flaw as mod_jk,
mod_proxy_ajp?
It's irrelevant.
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_WIN64)
(for the later) is misleading, and doesn't match
Hi all,
There is quite large list of fixed bugs for mod_jk
from the 1.2.15:
#37469: Fix shared memory close for forked childs.
#37332: Fix potential misuse of buffer length with snprintf.
#38859: Protect mod_jk against buggy or malicious AJP servers.
#38889: Use worker map sorting depending on
[EMAIL PROTECTED] wrote:
Fix gcc 4.0.1 compiler warning at mac os x!
Man, your are really serious with macosx.
Now, since it runs on Intel, I should try
one for myself :)
Cheers,
Mladen.
-
To unsubscribe, e-mail: [EMAIL
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...
Rainer made initial implementation for linux and solaris,
so he might have some ideas. Although this is
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 using for commits.
However, I saw you already commit a patch.
Remy Maucherat wrote:
+1, but make sure you test it (I see lots of last minute fixes).
Well, I hope I won't be the only one doing testing.
I'll create a private .tar.gz so everyone interested
(beside myself) could build and test it, before
official vote and release.
This is for those lazy to
Peter Rossbach wrote:
+1
Can you please create a windows binaries?
Sure. Already have them :)
I start testing at weekend and I hope Rainer can also do testing at
solaris.
I'll put that somewhere in the people.apache.org.
I'll let you know, when I upload the bins.
--
Mladen.
Jim Jagielski wrote:
Oh. I had thought that someone said that MaxOS did NOT
report itself as IS_UNIX (which would itself be a bug).
If that is no longer the case, then the MacOS side-benefit
is moot.
Right, and with the latest patch to the OS.java there is
no more 'Address already in use
Remy Maucherat wrote:
About the rebinding issues, this is quite funny, I remember asking for
explanations to Mladen and Jim (who did apply a patch for it in the
native code, as far as I can remember, but it's not in tcnative 1.1.2),
and was ignored.
The problem was in OS.java, not in native.
William A. Rowe, Jr. wrote:
If there's any hope of waiting a day or few, I'd like to ensure this can
be configured and built to both 2.0 and 2.2 on windows and unix.
Sure, no problem.
I wish that we have at least a stable release as 1.2.15 was,
so what ever it takes :)
Regards,
Mladen.
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
VERSION=1.2.14
Right, but it's irrelevant.
We have jk_version.h. I think this was
meant to be used for packaging tasks
that BTW doesn't
Henri Gomez wrote:
well client and server should be in phase about the buffer size and
the better way to accomplish that will be via AJP13 extensions (ie
AJP14), with connect time negociation datas like packet buffer size :)
Right. Extensions could contain packet size. The problem is that
KARNATI, SRINIVASA R [AG/1000] wrote:
Possible. But, I have no idea why connector should be constraining this.
???
It is obvious by your comment that you have no clue how AJP
protocol works, and why it has a fixed packet size in the spec.
Also take a look at what protocol and specification
Peter Rossbach wrote:
Hi,
I have test the sendfile apr connector feature with MAC OS X 10.4.5,
Java 1.5, APR 1.2.2, Tomcat svn head,
Every time as sendfile is use the AprEndpoint.add(SendfileData data)
Socket.sendfilen() L1417 returned code 70023 APR_ENOTIMPL
Not yet implemented?!
Looks
Peter Rossbach wrote:
Arrg,
you are right! It seems that MAC OS X have no sendfile support. I have
search, but I can't find sys/sendfile.h
I don't understand why Library.APR_HAS_SENDFILE not set correctly :-(
apr.h is correct generate without sendfile support #define
APR_HAS_SENDFILE 0
Peter Rossbach wrote:
Ups, now I find the root of my strange problem...
Start with zero, but jnilib.c starts with one?!
I think that isn't correct or every one at the middle decrement the
has() value! Can I change the Library.java ?
If you have a commit right, sure :)
It seems it's an
Peter Rossbach wrote:
Ups, now I find the root of my strange problem...
I think that isn't correct or every one at the middle decrement the
has() value! Can I change the Library.java ?
Sorry...
Fix the jnilib.c instead Library.java
--
Mladen.
Jeff Turner wrote:
On Sat, Apr 08, 2006 at 06:56:06PM +0200, Remy Maucherat wrote:
Jeff Turner wrote:
We experienced this before on the old issues.apache.org box, but Remy
said he fixed it (and it is fixed on that box):
Nothing unusual. Ubuntu 5.10, 1x2.8Ghz Xeon. Java is started with:
Remy Maucherat wrote:
Yoav Shapira wrote:
I'm ready to do a 5.5.17 later this week, if the other committers
think this is a decent time.
We would need a new release of tcnative (1.1.3) as well, so some updates
are needed.
Right. I was hoping to have the native release by the end of the
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)
+1.
1.1.3 will be out on Friday, by
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-2 weeks further on?
We had a preliminary vote two weeks ago, and everyone agreed
to go for the 1.2.16, so if
Yoav Shapira wrote:
Never mind, it looks like the binaries are in www.apache.org/dist, I
(and the build script) was looking in archive.apache.org/dist. Will
tag and build 5.5.17 in a few minutes.
Right. I'm not sure when the files from /dist gets moved
to archive.apache.org
The sources and
Filip Hanik - Dev Lists wrote:
Apache Tomcat v5.5.20 is:
[x] +1 Stable - no major issues
Works great.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Rainer Jung wrote:
Apache Tomcat Connectors 1.2.19 is:
[X] Stable - no major issues, no regressions
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
The problem is that we presume that socket timeout
is keep-alive timeout, and that is wrong.
The reason is simple because the time between two
requests has noting to do with the the time the data
will be read.
Also, the thing like reading the request is dependent
on the number of client
Filip Hanik - Dev Lists wrote:
you are correct, soTimeout should not, imho, change depending on the
thread count.
if the user sets 20 seconds for soTimeout then it should stay that way.
Right. With the current code you can only deduct what the actual
timeout will be. Like said, for 40 sec
Remy Maucherat wrote:
Mladen Turk wrote:
Filip Hanik - Dev Lists wrote:
you are correct, soTimeout should not, imho, change depending on the
thread count.
if the user sets 20 seconds for soTimeout then it should stay that way.
Right. With the current code you can only deduct what
Remy Maucherat wrote:
Mladen Turk wrote:
semi useless, LOL :)
when the number of threads gets lower, it tends to use fewer threads
Ok, it's the opposite: when the number of threads gets higher, it will
try using fewer threads. Looking at the code will makes this obvious.
Look. My patch
Filip Hanik - Dev Lists wrote:
where is this proposed, 6.0 or 5.5.x dot release?
Sorry it's targeted for 6.0
(I thought it was clear from the patches)
Regards,
Mladen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Bill Barker wrote:
I pretty much agree with Remy: Anything useful this would do has been in
place since the early days of Coyote. Also, anybody that actually would
care about this option almost certainly wouldn't be using the JIO Connector
:).
Fair enough.
Someone even said that there is
[EMAIL PROTECTED] wrote:
Log:
- At the moment, I prefer version 1.1.3.
Remy,
I have uploaded the 1.1.6 tag that fixes the problems with 1.1.4.
1.1.5 was not made as public, because of few small compile problems.
Also I have changed the source distribution naming, so it follows the
APR name
Rainer Jung wrote:
Hi,
fredk2 wrote:
The question is - how can you set secret in mod_proxy_ajp ?
Not at the moment.
If this feature is not (yet) implemented, can this be easily added -
aka can
we expect this in a later version :) ?
Please let me know if this post should be made on
[EMAIL PROTECTED] wrote:
-ssl = endpoint.getSecure();
+ssl = on.equalsIgnoreCase(endpoint.getSSLEngine());
Like Remy said, anything except Off is acceptable.
It can be either On or EngineName (eg, SSLEngine=nuron)
Regards,
Mladen.
Filip Hanik - Dev Lists wrote:
no need to get edgy :), your point is well taken.
I was edgy? Wasn't my intention.
I have two suggestions
1. The SSLEngine attribute should be in the APR lifecycle listener, and
not in the connector, since its static, I can't have more than one, so
why do I
Filip Hanik - Dev Lists wrote:
Let's keep SSLEngine: it's explicit, and it works.
not really, this wouldn't work
Connector port=8444 scheme=https secure=true
protocol=org.apache.coyote.http11.Http11AprProtocol
SSLEngine=oneengine/
Connector port=8555 scheme=https secure=true
Remy Maucherat wrote:
Mladen Turk wrote:
If that is the case the secure=true|false can be used to determine
if the transport is ssl or not, and fake the front end handled
https/ssl connection.
I find that doubtful.
I am against such a change right now, since it might restrict usage
[EMAIL PROTECTED] wrote:
SSLEngine is an attribute of the APR lifecycle listener to initialize the
native SSL layer once per VM.
I don't get it, really.
Did you read my reply about:
1. scheme=https secure=true
2. scheme=https secure=false
3. scheme=http secure=false
4. scheme=http
Filip Hanik - Dev Lists wrote:
The scenario we are trying to achieve is this:
Connector port=8443 scheme=https secure=true SSLEnabled=false/
How will in that case behave:
Connector port=8443 scheme=https secure=false SSLEnabled=false/
Connector port=8443 scheme=https secure=true
Filip Hanik - Dev Lists wrote:
Let me see if I can explain
Connector port=8443 scheme=https secure=false SSLEnabled=false/
c) if there is a transport user constraints, ie the page is only allowed
to be server CONFIDIENTIAL, tomcat will throw a 403 error
Connector port=8443 scheme=https
Hi,
Beyond the fact that org.apache.jk.* provides a generator for
the mod_jk.conf, is there any reason to have that connector
in parallel with org.apache.coyote.ajp.*
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL
Remy Maucherat wrote:
Filip Hanik - Dev Lists wrote:
I don't have any preference either way, since we are pretty few active
folks at the moment, the less code is usually better
My plan was not to do that (org.apache.jk is not that huge) and keep
people happy.
Nevertheless, the Apache/IIS
Peter Rossbach wrote:
Hi Malden,
Must be tcnative at tomcat60 not an external svn link?
I would like that we have the subset of connectors/jni
inside tc6/native (only the parts that are used).
The probable version will be 2.x while the version
in connectors/jni will stay as 1.x for tc 5.5.x
Hi,
With Native connector if the OS supports IPV6 the
default address (null) is translated to ::, thus
it only listens to the IPV6 addresses. In case the
OS doesn't support IPV6 (hardly to be found nowadays), the
null address is equivalent to the address=0.0.0.0.
The same is for any Java
Remy Maucherat wrote:
Comments?
As you say, 0.0.0.0 is ipv4 so it looks like a bad default value to me,
while null means whatever the connector wants. Internally, it's up to
the native layer to figure it out, I think.
Sure, but the fact is that Java connectors will always
use IPV4. APR
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: mturk
Date: Fri Nov 10 06:23:52 2006
New Revision: 473346
URL: http://svn.apache.org/viewvc?view=revrev=473346
Log:
Add version control flags like in 5.5
No, it's to be added when building only, according to what the user is
building.
Sven Köhler wrote:
Hi,
i see, you're developing Tomcat 6.0.
Will Tomcat 6.0 send flush packets, when the flush()-method of the
OutputStreams or the Writers are called?
Yes. It's done in a way that is backward compatible.
When out.flush() is called an empty data packet is sent.
It's
William A. Rowe, Jr. wrote:
Guys - something got broken again in your release process against ASF policy...
I don't see three +1's for any of the recent postings to your downloads page.
Nothing got broken.
Tomcat is probably one of the latest remaining projects
where the developers and PMC
[EMAIL PROTECTED] wrote:
URL: http://svn.apache.org/viewvc?view=revrev=476817
-if (ae-worker-socket_timeout 0) {
-if (!jk_is_socket_connected(ae-sd)) {
+if (!jk_is_socket_connected(ae-sd)) {
+1. That's possible because socket connect detection
is not dependent on
Rainer Jung wrote:
If you think you can do that in a simple way, then fine.
But if it would require a lots of changes, then I think
we should go with the more powerful solution as part
of 1.3 branch, by using shared memory, web interface, etc.
I just don't think that this is so important if
Rainer Jung wrote:
E.g. if one empties the uriworkermap.properties, reloading it does not
change the internal mount list. Temporarily adding and later removing an
entry will not remove the entry.
That's the entire point.
But this is not what a user expects from a change in a list.
I know,
Rainer Jung wrote:
Hi,
I suggest to tag mod_jk 1.2.20 next weekend. There are a couple of
additions to the status worker, and only small changes concerning the
apache integration (env vars, JkOptions and virtual hosts) coming from
me in the next days, but I would be ready to tag around
Rainer Jung wrote:
Hi Mladen,
very nice idea making things easier for users. I like it. But dots are
standard separation characters in host names and host names might not be
totally uncommon as jvm routes. I know, that they can be symbolic, but
we might break configs or deny using such a simple
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 real retry.
Right, and that is the problem.
With
[EMAIL PROTECTED] wrote:
Modified: tomcat/connectors/trunk/jk/native/common/jk_status.c
URL:
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_status.c?view=diffrev=479316r1=479315r2=479316
==
---
Rainer Jung wrote:
since this has already been out in the wild for a few month,
You are right. I've reverted the commit. I thought it was
introduced more recently. The name should be fine, although
it is a little bit strange (route or jvmroute would fit
better thought)
Regards,
Mladen.
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
+Integer i =
responseTransHash.get(header.toLowerCase(Locale.US));
-0. The String operations take away any benefit this could have.
Perhaps for CPU usage on the Tomcat, that is annihilated by the
lower processing on the mod_jk side.
Remy,
Can you change the permissions for the files in
/x1/www/tomcat.apache.org/tomcat-6.0-doc-v6.0.2
from 0644 to 0664?
Add group write permission, so other can modify the docs.
I know, it's a version related, but we should not
create a new tag if there is error in the docs thought.
Regards,
Hi,
Just committed two files, and again I've bumped
upon the coding style.
Although it seems we are quite good relating to the
tabs, the trailing spaces are a real mess in some files.
There are lots of files where we have
if (...) {
followed with the one or more spaces.
Also there are lots empty
Remy Maucherat wrote:
Mladen Turk wrote:
Comments?
-1. This will screw up diffs, and these really irrelevant things will be
added back very quickly. Tabs is one thing since it can be hard to work
with, but this is simply ridiculous.
Right, but at least the empty lines with spaces
Remy Maucherat wrote:
-1 for enforcing any coding style (except tabs, since it can make code
unreadable very easily).
You must be joking, right?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
Henri Gomez wrote:
I remember the cold days of the 'Tab brigade' :)
Right.
Anyhow, the point of my post was 'minimal', and
removing the trailing spaces.
It seems that the trailing spaces are very important,
so fine with me.
Cheers,
Mladen.
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: mturk
Date: Wed Nov 29 04:26:37 2006
New Revision: 480552
URL: http://svn.apache.org/viewvc?view=revrev=480552
Log:
Commit the voted keepAliveTimeout patch.
It is still as bad as what the original version was. -1 for this, +0 for
my
[EMAIL PROTECTED] wrote:
Author: remm
-timeout = keepAliveTimeout * 50;
+timeout = soTimeout * 50;
-sendfilePollset = allocatePoller(size, pool, keepAliveTimeout);
+sendfilePollset = allocatePoller(size, pool, soTimeout);
-
Remy Maucherat wrote:
Mladen Turk wrote:
Looks like we can do few things:
1. Revert your patch
2. Revert mine patch
3. Go on and forget all about programming, and do some shepherding.
So, please, unless you are going to adopt 3), revert your patch
for my patch. You know, Tomcat is not your
Remy Maucherat wrote:
Mladen Turk wrote:
Further more I collected enough votes, so your explanation is useless.
I am free to commit things, especially since I actually fixed some of
your patch. You are free to veto my commit, in which case it would be
time to take this to the PMC
+1
BTW, Can we make minimum native version required
for 6.0.x to 1.1.7 (It's 1.1.3 right now copied
from 5.5.x)?
I mean there was no released versions of 6.0, and
the latest one has more stable API.
Regards,
Mladen.
Remy Maucherat wrote:
Hi,
In line with what Filip wanted to have, I
Remy Maucherat wrote:
[EMAIL PROTECTED] wrote:
Author: mturk
Date: Sun Dec 3 01:49:18 2006
New Revision: 481745
URL: http://svn.apache.org/viewvc?view=revrev=481745
Log:
Update binaries with --ServiceUser/ServicePassword option.
Modified:
tomcat/connectors/trunk/procrun/bin/tomcat5.exe
Rainer Jung wrote:
I think it's perfectly valid having to simply use in URLs, no need
to encode. On the other hand as long as we don't have a proper decoding
for the incoming URLs and I don't know, if all supported web servers
decode before putting the query string into our service struct, I
1 - 100 of 1171 matches
Mail list logo
