french translation for servletapi5

Ditto than previous for servletapi5 # Default localized string information # Localized for Locale fr_FR err.not_iso8859_1={0} n''est pas un caractère ISO 8859-1 value.true=true value.false=false # Default localized string information # Localized for Locale fr_FR err.cookie_name_is_token=Le nom

french translation for servletapi (2.2)

Could it be commited ? Thanks # Default localized string information # Localized for Locale fr_FR err.not_iso8859_1={0} n''est pas un caractère ISO 8859-1 value.true=true value.false=false # Default localized string information # Localized for Locale fr_FR err.cookie_name_is_token=Le nom de c

Re: french translation for servletapi (2.2)

err.cookie_name_is_token=Le nom de cookie {0} est un "token" réservé err.io.negativelength=Taille négative donnée dans la méthode "write" err.io.short_read=Lecture réduite Non. partielle. (That sounds better according to the java sources). Exact so replace : err.io.short_read=Lecture réduit

Re: cvs commit: jakarta-servletapi-5/jsr154/src/share/javax/servletLocalStrings_fr.properties

err.io.short_read=Lecture réduite Could you replace by : err.io.short_read=Lecture partielle -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: french translation for servletapi (2.2)

Jeanfrancois Arcand wrote: OK c'est fait (Done :-) ) Thanks to update to use partielle instead of réduite ... -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: cvs commit: jakarta-servletapi-5/jsr154/src/share/javax/servletLocalStrings_fr.properties

Don't forget also to update the second LocalString_fr.properties, the one in javax.servlet with : # Default localized string information # Localized for Locale fr_FR err.not_iso8859_1={0} n''est pas un caractère ISO 8859-1 value.true=true value.false=false -- To unsubscribe, e-mail:

French translations - who's interested ?

There is still some works to finish french translation in TC4+CATALINA2+JASPER. Who's planning to make some works ? (JFC/JFA/REMM ?) Regards -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11InternalInputBuffer.java

[EMAIL PROTECTED] wrote: remm2002/11/05 08:26:38 Modified:http11/src/java/org/apache/coyote/http11 InternalInputBuffer.java Log: - I think a 0 result is an error according to the JVM javadocs (we are using InputStream.read(byte[], int, int)). Under

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11InternalInputBuffer.java

Remy Maucherat wrote: Henri Gomez wrote: [EMAIL PROTECTED] wrote: > remm2002/11/05 08:26:38 > > Modified:http11/src/java/org/apache/coyote/http11 > InternalInputBuffer.java > Log: > - I think a 0 result is an error according to th

Re: Overwhelmed docs

I'll add an 'impatient page' in jk docs with strict minimum, will need help for IIS/NES. I think the same should be done for jk2. Pier Fumagalli wrote: Forwarding... Pier "Lambert, Stephen : CO IR" <[EMAIL PROTECTED]> wrote: Is there any way the web site could be updated to include a

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resourcesmessages_fr.properties

This should end the french translation of Tomcat 4.1 & Catalina 2.0. Changes should be back ported to Tomcat 4.0 and now tomcat-jasper should be translated (may be 99% of the works is allready done from the translation done in TC 4.1 jasper). Regards -- To unsubscribe, e-mail:

Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resourcesmessages_fr.properties

[EMAIL PROTECTED] wrote: jfclere 2002/11/06 03:39:41 You should probably port them to tomcat-jasper ;) -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resourcesmessages_fr.properties

[EMAIL PROTECTED] wrote: hgomez 2002/11/06 03:38:49 Added: jasper2/src/share/org/apache/jasper/resources messages_fr.properties Log: Add french translation Ok this should be the last part of french translation (ouf). French readers should make a revue a

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreStandardWrapper.java

Tim Funk wrote: In case you weren't joking ... It can easily break compatibility if someone introduces a new class with the same class name as another class in a different package. ex: import foo.*; /* has class A */ import bar.*; /* has class B */ class Foo { A a; B b; } Imagine time

New jakarta logo to be included in tomcat 3/4/5 ?

Hi, I just updated in jtc/jk docs the jakarta logo by the new one. Any objection I do the same for the others tomcat projects ? -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [VOTE] Proposed jspc refactoring

Remy Maucherat wrote: Hi, jspc is IMO overly complex, with many features nobody knows how to use, and nobody cares to test (hence sometimes some of them are randomly broken during Jasper refactorings). I propose that: - In Tomcat 5, all jspc options are removed, in favor of allowing only the

Re: New jakarta logo to be included in tomcat 3/4/5 ?

Larry Isaacs wrote: Hi Henri, I have no objection to updating Tomcat 3.3.x. Thanks. Done. What about TC 4 and 5 ? -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [ADDON] tomcat.nsi for Nullsoft 2.0

Is the Nullsoft 2.0 the OpenSource installer found under www.nullsoft.com? http://nsis.sourceforge.net/ -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [ADDON] tomcat.nsi for Nullsoft 2.0

Remy Maucherat wrote: Henri Gomez wrote: > Is the Nullsoft 2.0 the OpenSource installer found under > www.nullsoft.com? http://nsis.sourceforge.net/ The only problem with NSIS 2 is that the set of macros is changing twice a day (or close to it). Yes it seems ;) BTW, which version

Re: [ADDON] tomcat.nsi for Nullsoft 2.0

http://nsis.sourceforge.net/ The only problem with NSIS 2 is that the set of macros is changing twice a day (or close to it). Exact, I tried to remake with alpha7 and got : MakeNSIS v2.0a7 - Copyright 1999-2002 Nullsoft, Inc. Portions Copyright (C) 1995-1998 Jean-loup Gailly and Mark Adler

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

Mladen Turk wrote: Personally don't like hardcoded defines. me too. Could that be guessed or forced in makefiles? I searched thru Apache 2.0.43 source and find these included by hand in files, but configure specialists should be able to fix it. JF ? -- To unsubscribe, e-mail:

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

Mladen Turk wrote: -Original Message- From: jean-frederic clere It must be guessed in the configure... Why? Think we just add the -DBSD_COMP to the JK_CFLAGS in Makefile.in Sure but it's not very clean and didn't take use of configure "detection" features. BTW: we'll need to fin

Re: [VOTE] Proposed jspc refactoring

Costin Manolache wrote: To clarify - I agree jspc has a lot of broken options and features. My use case is: I'm using a similar way with jspc fr

Re: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c

Mladen Turk wrote: -Original Message- From: Henri Gomez Why? Think we just add the -DBSD_COMP to the JK_CFLAGS in Makefile.in Sure but it's not very clean and didn't take use of configure "detection" features. BTW: we'll need to find a way to add it to

Re: [VOTE] Proposed jspc refactoring

BTW, no matter how I look at it, the practice of generating servlets seems really ugly to me (of course, there are so many ugly things about JSPs, I guess it's only one of them). Another big advantage of using JSP -> servlet is that you didn't have security problems of code exposure ;) -- T

Re: [VOTE] Proposed jspc refactoring

Another big advantage of using JSP -> servlet is that you didn't have security problems of code exposure ;) Hey, stop making fun of me, and get back to work ;-) Oui patron ;) -- To unsubscribe, e-mail: For additional commands, e-mail:

catalina won't compile on JDK 1.3.1

In o.a.c.loader.WebAppClassLoader.java, realFile.toURI() isn't known by SDK 1.3.1 .. /** * Get URL. */ protected URL getURI(File file) throws MalformedURLException { File realFile = file; try { realFile = realFile.getCanonicalFile();

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/xmlparserXMLEncodingDetector.java

[EMAIL PROTECTED] wrote: remm2002/11/07 07:23:43 Modified:jasper2/src/share/org/apache/jasper/xmlparser XMLEncodingDetector.java Log: - This appreas to fix the stack overflow. is the xerces dependencie is normal ? import org.apache.xerces.util.Encoding

Re: DO NOT REPLY [Bug 14405] - Tomcat uses 90% of CPU

[EMAIL PROTECTED] wrote: 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://nagoya.a

Re: Xerces 2.2.x & Struts 1.0.2 problem.

Jeanfrancois Arcand wrote: Hi, finally, with the help of Craig, I was able to isolate the problem Tomcat have with Xerces 2.2.x. When you have an In our case, file web-app_2_3.dtd included with Struts 1.0.2 is causing the problem (Strangely, this is not the same as the web-app_2_3.dtd inclu

Re: [PATCH] Fixing Interoperability problem in iis connector

Steven Velez wrote: OK... I wasn't sure if that was an acceptable solution. In that case, the patch for existing files is one attachment and the two new files are two other attachments. They need to go in jakarta-tomcat-connectors\jk\native\iis. Thanks. If Nacho agree on this patch and comm

jk and jk2 doc on jakarta site

What about moving documentation for jk and jk2 to : http://jakarta.apache.org/jakarta-tomcat-connectors/jk/ http://jakarta.apache.org/jakarta-tomcat-connectors/jk2/ And make ref to them from : http://jakarta.apache.org/tomcat/ (documentation) and http://jakarta.apache.org/ (subproject) --

AJP13 problem on Tomcat 4.1.15

While playing with 4.1.15, I discovered some nasty problem with the AJP13 implementation from JTC. 1) TC 4.1.15 set socket timeout (2 = 20s) which make give you Read exception after 20s of inactivity between webserver and Tomcat : 90577 [Thread-6] ERROR common.ChannelSocket - Error, clos

Re: Nightly TC 3.3.x builds not working anymore?

Hans Schmid wrote: Hi, the nightly build of Tomcat 3.3.x seems to have stopped at 08-Nov-2002. Any Idea, why? Cheers, Hans -- To unsubscribe, e-mail: For additional commands, e-mail: What's the error ? -- To unsubscribe, e-mail:

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml

[EMAIL PROTECTED] wrote: hgomez 2002/11/21 01:42:36 Modified:catalina/src/conf server.xml Log: No timeout to be set in AJP13 connector, it's the webserver responsability to drop unused connections Revision ChangesPath 1.65 +1 -1 jakarta-tomcat-4.0/catalin

Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c

[EMAIL PROTECTED] wrote: costin 2002/11/21 09:53:48 Modified:jk/native/common jk_ajp_common.c Log: Do not send the initial chunk for chunked encoding ( only for regular POST ). Ajp13 servers ( tomcat x.y, etc ) expect this initial chunk only if a content-length is specified.

Tagging JK 1.2.1

I'll tag next week JK 1.2.1, after conducting tests to see if latest Costin path on chunked didn't break anything. -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: Tagging JK 1.2.1

jean-frederic clere wrote: Henri Gomez wrote: I'll tag next week JK 1.2.1, after conducting tests to see if latest Costin path on chunked didn't break anything. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROT

strange problem with jasper on TC 4.1.x HEAD :

The generated JSP didn't have the import org.apache.jasper.runtime.* : . package jsp.snp; import javax.servlet.*; import javax.servlet.http.*; import javax.servlet.jsp.*; public class _0002fjsp_0002fsnp_0002fsnoop_0002ejspsnoop_jsp_0 extends org.apache.jasper.runtime.HttpJspBase { s

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/serverJkCoyoteHandler.java

Bill Barker wrote: - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 22, 2002 10:34 PM Subject: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java hgomez 2002/11/22 22:34:48 Modified:jk/java/org

Re: [4.1.16] New tag ?

Mladen Turk wrote: -Original Message- From: Remy Maucherat It would be good to have updated native connectors at the same time or before. Before, IMO. I'm posting this to confirm that all the fixes which were needed in JK are in. Think that Henri is preparing a tag this wee

catalina 2.0 still only SDK 1.4 ?

There is still in o.a.c.loader.WebappClassLoader : /** * Get URL. */ protected URL getURI(File file) throws MalformedURLException { File realFile = file; try { realFile = realFile.getCanonicalFile(); } catch (IOException e) {

Re: cvs commit: jakarta-servletapi/src/share/javax/servlet LocalStrings_fr.properties

[EMAIL PROTECTED] wrote: jfarcand2002/11/25 06:45:24 Added: src/share/javax/servlet LocalStrings_fr.properties Log: French Translation Submitted by: Henry Gomez Revision ChangesPath 1.1 jakarta-servletapi/src/share/javax/servlet/LocalStrings_fr.pr

TC 3.3.2

Hi to all, I commited the last part of clean imports and started to take a look at bugzilla where many reports seems still open. What's the strategy now ? Should we close those which seems invalid ? - To unsubscribe, e-mail: [EM

Re: mod_jk release packaging and connector download move to www.apache.org/dist mirror and archive.apache.org

Glenn Nielsen a écrit : As part of the mod_jk 1.2.5 release I promised to move the JTC download to www.apache.org/dist so that the downloads can be mirrored. Here are the changes I propose to make as I set this up. First, here is the directory layout for mirrored downloads at /www/www.apache.org/d

What's is Property Helper in J-T-C naming

Hi to all, While working on cleaning imports in J-T-C, I've found an unknown class PropertyHelper in org.apache.naming.ant.JndiProperties. Is it related to Ant 1.6.x ? Did this code is still active ? - To unsubscribe, e-mail

Re: [PATCH] ./jk/native/apache-2.0/mod_jk.c compile with Apache 2.1

Günter Knauf a écrit : Thanks Gunter, I'll apply it ASAP - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: TC 3.3.2

Bill Barker a écrit : - Original Message - From: "Henri Gomez" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Monday, September 29, 2003 2:55 AM Subject: TC 3.3.2 Hi to all, I commited the last part of clean imports and st

Re: [PATCH] ./jk/native2/server/apache2/mod_jk2.c compile with Apache 2.1

Günter Knauf a écrit : Hi, with Apache 2.1 and APR 1.0 seems that apu_compat.h is removed (see APR-util Changes); attached a patch which works for me with both APR 0.9.4 and APR 1.0.0 Thanks to send it as an attached file please --

Re: What's is Property Helper in J-T-C naming

Henri Gomez a écrit : Hi to all, While working on cleaning imports in J-T-C, I've found an unknown class PropertyHelper in org.apache.naming.ant.JndiProperties. Is it related to Ant 1.6.x ? Ok, it's in ant HEAD (1.7 beta ?) Did this code is still active ? But this question

Re: What's is Property Helper in J-T-C naming

Stefan Bodewig a écrit : On Tue, 30 Sep 2003, Henri Gomez <[EMAIL PROTECTED]> wrote: While working on cleaning imports in J-T-C, I've found an unknown class PropertyHelper in org.apache.naming.ant.JndiProperties. Is it related to Ant 1.6.x ? Yes, I think so, although Costin has w

Re: [PATCH] ./jk/native2/server/apache2/mod_jk2.c compile with Apache2.1

Günter Knauf a écrit : Hi Henri, with Apache 2.1 and APR 1.0 seems that apu_compat.h is removed (see APR-util Changes); attached a patch which works for me with both APR 0.9.4 and APR 1.0.0 Thanks to send it as an attached file please it was already attached as file too; but seems the attachm

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java

[EMAIL PROTECTED] a écrit : hgomez 2003/10/01 00:54:09 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: More setters for gzip compression support. Here is the correction for getRemoteAddr(), getRemoteHost(), getRemotePort(). I det

Tomcat 3.3.2 default HTTP connector ?

Do you agree to use Coyote2 as the default HTTP connector for Tomcat 3.3.2 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml

Remy Maucherat a écrit : [EMAIL PROTECTED] wrote: hgomez 2003/10/01 02:43:40 Modified:catalina/src/conf server.xml Log: Add comments about gzip settings + + +

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java

Remy Maucherat a écrit : Henri Gomez wrote: [EMAIL PROTECTED] a écrit : hgomez 2003/10/01 00:54:09 Modified:http11/src/java/org/apache/coyote/http11 Http11Processor.java Log: More setters for gzip compression support. Here is the correction for

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml

Remy Maucherat a écrit : Henri Gomez wrote: Urg. Should I back port change to coyote_10 ? I'd prefer using the Coyote HEAD in TC 4.1, I think. I'm sick of all those branches ;-) +1, less branches, less works --

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml

Remy Maucherat a écrit : Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: Urg. Should I back port change to coyote_10 ? I'd prefer using the Coyote HEAD in TC 4.1, I think. I'm sick of all those branches ;-) +1, less branches, less works I'll try to build

Re: Tomcat 3.3.2 default HTTP connector ?

Larry Isaacs a écrit : I have my 3.3.2-dev builds running again. Currently it uses the MAIN branch of JTC to build "util" and the coyote_10 branch to build coyote/http11. Once upon a time, I thought there was a reason that 3.3.2-dev couldn't use MAIN for coyote. I'm not sure what that reason was

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml

Remy Maucherat a écrit : Remy Maucherat wrote: Henri Gomez wrote: I'll try to build it, and see if it works. I'll also diff the adapter between the two branches, to see if there aren't any forgotten patches. If it works well, we can try to include that with 4.1.28. It doesn&#

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml

Remy Maucherat a écrit : Henri Gomez wrote: Remy Maucherat a écrit : Remy Maucherat wrote: Henri Gomez wrote: I'll try to build it, and see if it works. I'll also diff the adapter between the two branches, to see if there aren't any forgotten patches. If it works well, we can

Re: cvs commit: jakarta-tomcat build.xml

[EMAIL PROTECTED] a écrit : larryi 2003/10/01 19:50:59 Modified:.build.xml Log: Update to build using MAIN branch of JTC coyote and http11. The jars are a little different from coyote_10 version. Thanks Larry -

Re: [next] What's next ?

Remy Maucherat a écrit : Usually, when a Tomcat branch nears its release, a new branch is created. However, I only have a few feature ideas that make some sense, and the problem is that they are minor evolutions (hence, they could perfectly fit inside the 5.0 branch). This includes: - Updating

Re: [next] What's next ?

3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it. So you want to do a HTTP

Re: [next] What's next ?

Henri Gomez a écrit : 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more examples/documentation so that people start using it

Re: [next] What's next ?

Jean-Francois Arcand a écrit : Henri Gomez wrote: Henri Gomez a écrit : 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have the jvmRoute mechanism, but I think it needs more

Re: [next] What's next ?

Henri Gomez a écrit : Jean-Francois Arcand a écrit : +1 The security mechanism in TC 4.x and higher (due to digester) avoid me to use such easy configuration tuning and so we have to stay with Tomcat 3.3.x for now. I'm probably missing something herewhy the digester suffer from

Re: [next] What's next ?

Craig R. McClanahan a écrit : Henri Gomez wrote: Jean-Francois Arcand a écrit : Henri Gomez wrote: Henri Gomez a écrit : 3. Provide a complete working configuration example for a cluster of tomcat servers with a front-end tomcat as well, i.e. a pure tomcat-only solution. We already have

Re: [next] What's next ?

Henri Gomez a écrit : Henri Gomez a écrit : Jean-Francois Arcand a écrit : +1 The security mechanism in TC 4.x and higher (due to digester) avoid me to use such easy configuration tuning and so we have to stay with Tomcat 3.3.x for now. I'm probably missing something herewh

Re: [next] What's next ?

Henri Gomez a écrit : Henri Gomez a écrit : Henri Gomez a écrit : Jean-Francois Arcand a écrit : +1 The security mechanism in TC 4.x and higher (due to digester) avoid me to use such easy configuration tuning and so we have to stay with Tomcat 3.3.x for now. I'm probably mi

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Constants.java

Remy Maucherat a écrit : [EMAIL PROTECTED] wrote: jfclere 2003/10/03 03:05:57 Modified:http11/src/java/org/apache/coyote/http11 Constants.java Log: getBytes() uses platform's default charset... Bad on my EBCDIC machine! /** @@ -239,8 +256,28 @@ /** * Ack s

Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c

[EMAIL PROTECTED] a écrit : mturk 2003/10/04 02:20:59 Modified:jk/native/common jk_ajp_common.c Log: "Normal" C compiler doesn't allow to declare variables like C++ does. Revision ChangesPath 1.40 +15 -21jakarta-tomcat-connectors/jk/native/common/jk_ajp_commo

Http Connector / Gzip

Hi to all, What about using regexp in HTTP 1.1 connector to include/exclude browser which could/couldn't use gzip compression ? May be it could be use also to drop to HTTP 1.0 browser which claims to be 1.1 compatible, but are not. CF: Apache HTTPD server -

Re: Http Connector / Gzip

Remy Maucherat a écrit : Henri Gomez wrote: Hi to all, What about using regexp in HTTP 1.1 connector to include/exclude browser which could/couldn't use gzip compression ? May be it could be use also to drop to HTTP 1.0 browser which claims to be 1.1 compatible, but are not. CF: Apache

Re: Http Connector / Gzip

Remy Maucherat a écrit : Henri Gomez wrote: Hi to all, What about using regexp in HTTP 1.1 connector to include/exclude browser which could/couldn't use gzip compression ? May be it could be use also to drop to HTTP 1.0 browser which claims to be 1.1 compatible, but are not. CF: Apache

Re: Http Connector / Gzip

>>> Here is the patch against latest remy changes ... Index: build.properties.sample === RCS file: /home/cvs/jakarta-tomcat-connectors/http11/build.properties.sample,v retrieving revision 1.2 diff -u -r1.2 build.properties.sample ---

Re: Http Connector / Gzip

Remy Maucherat a écrit : Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: Hi to all, What about using regexp in HTTP 1.1 connector to include/exclude browser which could/couldn't use gzip compression ? May be it could be use also to drop to HTTP 1.0 browser which claims

Re: Http Connector / Gzip

Well I take my inspiration from what is done in some TC 4.1 Valves... I know ;-) Some problematic stuff went away, though (the various mappers), but some remain. This feature would really need to be seriously optimized, as ideally this would be enabled by default. We could do better as usua

Re: Http Connector / Gzip

Remy Maucherat a écrit : Henri Gomez wrote: Could I commit my changes and start working on an optimizing version ? Yes, of course. There's no big rush to start optimizing this ;-) (it's really disabled by default, right ?) Yes, since the restrictedUserAgents and restrictedUserAgen

regexp 1.3 ?

Shouldn't we upgrade TC 4.1 and JTC to regexp 1.3 ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Notes in HTTP 1.1 connectors

What about the idea to add notes in HTTP 1.1 connector ? It will mimic the way HTTPD teams using BrowserMatch : - Disable HTTP 1.0 for some browsers BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 BrowserMatch "RealPlayer 4\.0" force-

Re: Http Connector / Gzip

Remy Maucherat a écrit : Henri Gomez wrote: Remy Maucherat a écrit : +0 if disabled by default; -1 otherwise. All this stuff is inefficient, as it uses Strings. Ie, we take the byte array we have for the header value, convert it to a String, and then regexp will likely convert it to something

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml

[EMAIL PROTECTED] a écrit : remm2003/10/07 06:25:17 Modified:catalina/src/conf server.xml Log: - The connector class being used by Tomcat 4.1 doesn't have the appropriate setters, nor the "set-any-property" mod that is in 5.0. As a result, the example won't work right no

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/conf server.xml

Remy Maucherat a écrit : Henri Gomez wrote: [EMAIL PROTECTED] a écrit : remm2003/10/07 06:25:17 Modified:catalina/src/conf server.xml Log: - The connector class being used by Tomcat 4.1 doesn't have the appropriate setters, nor the "set-any-property" mod

Re: DO NOT REPLY [Bug 23675] New: - Ajp13Connector contains code that works only on JDK1.3+

[EMAIL PROTECTED] a écrit : 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://nago

Re: DO NOT REPLY [Bug 23675] New: - Ajp13Connector contains code that works only on JDK1.3+

[EMAIL PROTECTED] a écrit : 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://nago

Important requirement : Re: [next] What's next ?

Remy Maucherat a écrit : Henri Gomez wrote: Henri Gomez a écrit : Note: I really love Xerces' error messages. Great it seems to works with : http://java.sun.com/dtd/web-app_2_3.dtd"; [ %appconf; ] > Servlet 2.4 Examples Servlet 2.4 Examples. .

Re: Committing binaries in CVS [Was] RE: cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe

Ignacio J. Ortega a écrit : Hola a todos: (Many time from my last post, things are settling here, so hope i will contribute some code in future :) shields up, nacho will be messing things shortly, now i'm only moderating our lists, and as some person said time ago "moderation is to coding what w

[Fwd: Re: Restarted Tomcat (again)]

FYI : --- Begin Message --- On 9 Oct 2003, at 08:37, Noel J. Bergman wrote: Leif, No worries about time. You replied before I left for the road, and I won't be posting this reply until at least 15 hours after your note. The platform is Solaris. The application is Tomcat. The major "problem

Re: [5.0.13] [4.1.28] VOTES

Remy Maucherat a écrit : For 4.1.28: [ ] Alpha [ ] Beta [ ] Stable For 5.0.13: [ ] Alpha [ ] Beta They didn't include my late patch to remove setKeepAlive from JTC ? We should avoid problem with JDK 1.2/1.3 users ,( - To uns

Re: [5.0.13] [4.1.28] VOTES

Remy Maucherat a écrit : Mladen Turk wrote: One question. Why do we need to vote on that? AFAICT the 4.1.27 was stable. and the 5.0.12 was Beta. IMHO we should vote on Release/DoNotRelease. If for example the 5.0.13 is a less quality code then 5.0.12 do not release at all, or vote for a Stable,

Re: Committing binaries in CVS [Was] RE: cvs commit: jakarta-tomcat-connectors/procrun/bin tomcat.exe tomcatw.exe

Mladen Turk a écrit : -Original Message- From: jean-frederic clere Remy Maucherat wrote: Ignacio J. Ortega wrote: Sorry to disagree, but it's impossible to build the said binaries without expensive compilers. (please do not suggest Cygwin) Why? Is the Makefile broken? Doesn't matter.

TC 3.3.2-dev and endorsed lib

In TC 4.1.x and 5.0.x there is support for endorsed lib but nothing like this in tc 3.3.2-dev. Since we may have people (including myself), who will have to use SDK 1.4.x with Tomcat 3.3.2, I like to add such feature to Tomcat 3.3.2-dev. I was thinking put the endorsed in lib/endorsed, ie next to l

Re: Important requirement : Re: [next] What's next ?

Henri Gomez a écrit : Remy Maucherat a écrit : Henri Gomez wrote: Henri Gomez a écrit : Note: I really love Xerces' error messages. Great it seems to works with : http://java.sun.com/dtd/web-app_2_3.dtd"; [ %appconf; ] > Servlet 2.4 Examples Servlet

Re: TC 3.3.2-dev and endorsed lib

Bill Barker a écrit : - Original Message - From: "Henri Gomez" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Monday, October 13, 2003 1:28 AM Subject: TC 3.3.2-dev and endorsed lib In TC 4.1.x and 5.0.x there is support f

Re: TC 3.3.2-dev and endorsed lib

Bill Barker a écrit : - Original Message - From: "Henri Gomez" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Monday, October 13, 2003 2:09 AM Subject: Re: TC 3.3.2-dev and endorsed lib Bill Barker a écrit : - Orig

Re: Important requirement : Re: [next] What's next ?

Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a lot more. Well it will be problematic for all

Re: Important requirement : Re: [next] What's next ?

Remy Maucherat a écrit : Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution on the host appBase a

Re: Important requirement : Re: [next] What's next ?

Remy Maucherat a écrit : Glenn Nielsen wrote: Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: No reply for this request ? Should I assume I could start to work on settings the currentWorking dir at web.xml dir location at web.xml parsing time ? I like basing the resolution

Re: Important requirement : Re: [next] What's next ?

CF w3c.org ... relative URIs are relative to the location of the resource within which the entity declaration occurs. http://www.w3.org/TR/REC-xml#sec-external-ent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional co

<    1   2   3   4   5   6   7   8   9   10   >