Re: JkRequestLogFormat for JK 1.2.x on Apache 2.0 ?
Henri Gomez wrote: Did someone try to port 'JkRequestLogFormat' to Apache 2.0 ? For instance I wonder about : ap_bgetopt(r-connection-client, BO_BYTECT, bs); I added 'JkRequestLogFormat' for Apache 2.0. Glenn could you take a look ? Regards BTW : I think I will make a JK 1.2.1 release to include this fix. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: TOMCAT memory usage : how to manage and benchmark ?
Pier Fumagalli wrote: Henri Gomez [EMAIL PROTECTED] wrote: On Linux threads are +/- process and are really cheap to create, so it's should be a problem. Read, it shouldn't be a problem It is a problem because every time someone does a PS goes _nuts_ about the number of JVM processes... While at the end they are just threads... I believe I replied to this question at least 200 times in the past 5 years, and _still_ I see people asking... Yes, I agree that seeing many entries with ps isn't correct but only Linux newbie have problem with it ;) And try to do a little piece of code creating 1000 threads on Linux and on Windows 2k... Just to see which one is faster (and I believe we _all_ agree that Windows sucks!) It's a known case, even without doing the test I know that W2K will be faster to create thread. There is excellent documentation on Linux kernel on IBM alphaworks site and they show cases where Linux or W2K implementations are better. :-) Anyhow, the old battle on why Linux sucks is over... Works for you, well, use it! :-) Thanks, it works great for me on ia32 boxes and even on iSeries LPAR (PPC) ;) Pier (MacOS/X rocks!) Pier you know I'm allready convinced that MacOS/X rocks ! The question is why Apple didn't help OpenSource developpers to switch their primary devel box from Linux ia32 to MacOS/X by making affordable hardware . -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Réf. : Re: TOMCAT memory usage : how to manage and benchmark ?
[EMAIL PROTECTED] wrote: G... Always the same problem! I tried in the tomcat.conf script : JAVACMD=$JAVA_HOME/bin/java -Xms128m -Xmx256m or in the dtomcat4 : JAVA_OPTS= -server -Xms128m -Xmx256m -- The memory used by my tomcat reach 300 MO or more with 0 user connected... Why ? It may be : - your application init stage - admin/manager (remove them if you don't need them) what is the goog hard config for 500 concurrent users on the same tomcat server ? It depend on your application, but I'll recommand a least 3 fast Intel based linux boxes, with about 512Mo of RAM, and in front an Apache 1.3/2.0 box + mod_jk. But it depend really on what your application is doing... -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JkRequestLogFormat for JK 1.2.x on Apache 2.0 ?
Mladen Turk wrote: -Original Message- From: news [mailto:news;main.gmane.org] On Behalf Of Costin Manolache Sent: Monday, October 28, 2002 6:40 PM To: [EMAIL PROTECTED] Subject: Re: JkRequestLogFormat for JK 1.2.x on Apache 2.0 ? Henri Gomez wrote: I added 'JkRequestLogFormat' for Apache 2.0. Henri - any chance you'll add this to jk2 as well :-) ? And to the logger_file too :-) I'll take a look at this of course ;) I just wonder if with the sofisticated chaining in Apache 2.0, we couldn't just use mod_log_config ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [4.1.14] New test milestone released
Pier Fumagalli wrote: On 29/10/02 22:46, Costin Manolache [EMAIL PROTECTED] wrote: Remy Maucherat wrote: A new test milestone of Tomcat 4.1 has just been released. Please help test this upcoming Tomcat release for compliance issues and other problems. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.14/ Significant changes over 4.1.13 include a security manager bugfix. Over 4.1.12, Tomcat 4.1.14 includes bugfixes as well as performance improvements. The full list of changes is available in the release notes. http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.14/RELEASE-NOTES One small issue: the .zip file doesn't have +x on the bin/ files. Ehemm... Actually, the whole thing is completely wrong (I mean how the files are on daedalus, not only what you said, Costin)... _MAKE_SURE_ (this is _very_ important for mirrors, and I'm trying to enforce it now that we're not _yet_ mirrored heavily) that your UMASK is set to 002 ZARRO ZARRO TO when putting stuff in /www, that _ALL_ the files you create have a 664 mode (therefore when listing them, it needs to come out with -rw-rw-r-- ...) ALL directories need to be 755 (therefore only THOSE and NOT THE FILES need to have the +x bit set) they need to look like drwxrwxr-x Why 755 on directory ? Shouldn't they be 775 to allow group member to update them ? If you don't have a clue of what I'm talking about, make sure you do man chmod and man umask from your favorite Linux (HAHA!) box... Better documentation via 'info chmod' on Linux ;-) Seriously speaking, now, with the way in which the files for 4.1.14 are laid out, they can't be moved, deleted, removed, updated, mirrored by anyone but Remy (nah, probably right now with my config I can get them mirrored, but anyhow, DON¹T DO IT) That's why the dirs and files should be make writeable by group to help jakarta members update the rights ;) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: JkRequestLogFormat for JK 1.2.x on Apache 2.0 ?
Glenn Nielsen wrote: Henri Gomez wrote: Mladen Turk wrote: -Original Message- From: news [mailto:news;main.gmane.org] On Behalf Of Costin Manolache Sent: Monday, October 28, 2002 6:40 PM To: [EMAIL PROTECTED] Subject: Re: JkRequestLogFormat for JK 1.2.x on Apache 2.0 ? Henri Gomez wrote: I added 'JkRequestLogFormat' for Apache 2.0. Henri - any chance you'll add this to jk2 as well :-) ? And to the logger_file too :-) I'll take a look at this of course ;) I just wonder if with the sofisticated chaining in Apache 2.0, we couldn't just use mod_log_config ? One note: mod_jk 1.2 JkRequestLogFormat for Apache 1.3 can log every request that gets forwarded to Tomcat. Even if an HTTP request for a single page results in multiple requests to Tomcat due to SSI. I have found the reqeust data in the mod_jk logs to come in very handy for tracking Tomcat performance. I wrote some perl scripts which analyze the logs to generate statistical data which can then be used to generate reports and trend graphs. Is this something we might want to include with the mod_jk distribution? +1, you should create a tools subdir in jtc/jk. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Updated JK 1.2.0 mod_jk for NOEAPI uploaded
I just uploaded mod_jk 1.2.0 for Apache 1.3 without EAPI. Built on Redhat 7.2 against Apache 1.3.26 Regards -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: mod_jk log analysis/report perl scripts imported to CVS
Glenn Nielsen wrote: I have imported the mod_jk log analysis scripts into CVS. The scripts for analyzing the logs generates alot of data. The scripts for graphing/reporting this data only generates five long term graphs. More graphs and reports could be generated from the raw data. For an example of these graphs look at: http://kinetic.more.net/ar/kinetic/lottery.shtml Only the long term graphs referring to tomcat in this page were generated by the new perl scripts. The server load graph was not. Great ;) BTW, for a 100% pure Java version, you should take a look at a great and free Java Graph library, jfreechart, which is LGPL. http://www.object-refinery.com/jfreechart/ Regards -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resourcesLocalStrings_fr.properties
jean-frederic clere wrote: Jean-Francois Arcand wrote: Hi Henry, a couple of comment about your translation :-) Ok, what make me think that we may have to team up to manage all the translation to french. Who's candidate ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resourcesLocalStrings_fr.properties
fileResources.base=Le document base {0} n''existe pas ou n''est pas
un répertoire lisible
Le document base
ok
warResources.notWar=Doc base doit pointé vers un fichier WAR
warResources.invalidWar=Fichier WAR invalide ou illisible : {0}
jarResources.syntax=Le document base {0} doit commencé par 'jar:' et
finir avec '!/'
commencer
Exact ']
resources.alreadyStarted=Les Ressources ont déjà été démarrées
resources.connect=Impossible de se connecter au document base {0}
resources.input=Impossible de créer l'input stream pour la ressource {0}
Instead, I suggest: Impossible de créer le l'input stream pour la
ressource
le flux d''entrée (input stream)
resources.notStarted=Les ressources n''ont pas encore été démarrées
resources.null=Le document base ne peut être nul
resources.notFound=La ressource {0} est introuvable
resources.path=Le chemin relatif de context {0} doit commencé par '/'
Le chemin relatif du contexte
resources.alreadyBound=Le nom {0} est déjà référencé par ce contexte
Le nom {0} a deja ete reference par ce contexte
OK
resources.bindFailed=Le liage a échoué: {0}
resources.unbindFailed=Le déliage a échoué: {0}
standardResources.alreadyStarted=Les ressources ont déja été démarrées
standardResources.directory=Le file base {0} n''est pas un répertoire
standardResources.exists=Le file base {0} n''existe pas
Le file base (entre guillemets)
standardResources.notStarted=Les ressources n''ont pas encore été
démarrées
standardResources.null=Le document base ne peut être nul
standardResources.slash=Le document base {0} ne doit pas se terminer
par un '/'
De toute petite corrections ;-) ... ah ces Quebbecois!
Yes, but you're the guardian de la belle langue ;)
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: mod_jk patch to honor Apache UseCanonicalName
Thomas Morin wrote: Hi, Here is a short patch to mod_jk giving people the opportunity to make mod_jk honor Apache UseCanonicalName option. Eg.: ServerName www.foo.org UseCanonicalName on JkOption HonorUseCanonicalName It's allready included in latest mod_jk (1.2.1-dev) in CVS ;) ... /* get server name */ /* s-server_name = (char *)(r-hostname ? r-hostname : r-server-server_hostname); */ /* XXX : à la jk2 */ s-server_name = ap_get_server_name(r); /* get the real port (otherwise redirect failed) */ /* s-server_port = htons( r-connection-local_addr.sin_port ); */ /* XXX : à la jk2 */ s-server_port = ap_get_server_port(r); ... Thanks... -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt
[EMAIL PROTECTED] wrote: hgomez 2002/11/04 04:50:24 Modified:jk/native CHANGES.txt Log: Add comments about reports add-ons If nobody object, I'll tag jk 1.2.1 and make a release this week. Regards -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt
Glenn Nielsen wrote: Henri Gomez wrote: [EMAIL PROTECTED] wrote: hgomez 2002/11/04 04:50:24 Modified:jk/native CHANGES.txt Log: Add comments about reports add-ons If nobody object, I'll tag jk 1.2.1 and make a release this week. Does this version have support for JkRequestLogFormat for Apache 2? yes Will those perl scripts I committed be included? also ;) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt
jean-frederic clere wrote: Henri Gomez wrote: [EMAIL PROTECTED] wrote: hgomez 2002/11/04 04:50:24 Modified:jk/native CHANGES.txt Log: Add comments about reports add-ons If nobody object, I'll tag jk 1.2.1 and make a release this week. I would like to see 14086 fixed before the release. (The QA testers are complaining and I have no time for the moment). Did the problem is related to jk or jk + TC 4.1.12 ? What about when using jk + 3.3.1 ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
French translations for servletapi4
Since I didn't have commit access to servletapi4, here are the files
to be added.
# Default localized string information
# Localized for Locale fr_FR
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
http.method_not_implemented=Le méthode {0} n''est pas définie dans la RFC 2068 et
n''est pas supportée par l''API Servlet
http.method_get_not_supported=La méthode HTTP GET n''est pas supportée par cette URL
http.method_post_not_supported=La méthode HTTP POST n''est pas supportée par cette URL
http.method_put_not_supported=La méthode HTTP PUT n''est pas supportée par cette URL
http.method_delete_not_supported=La méthode HTTP DELETE n''est pas supportée par cette
URL
# 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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 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
http.method_not_implemented=Le méthode {0} n''est pas définie dans la RFC 2068 et
n''est pas supportée par l''API Servlet
http.method_get_not_supported=La méthode HTTP GET n''est pas supportée par cette URL
http.method_post_not_supported=La méthode HTTP POST n''est pas supportée par cette URL
http.method_put_not_supported=La méthode HTTP PUT n''est pas supportée par cette URL
http.method_delete_not_supported=La méthode HTTP DELETE n''est pas supportée par cette
URL
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 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
http.method_not_implemented=Le méthode {0} n''est pas définie dans la RFC 2068 et
n''est pas supportée par l''API Servlet
http.method_get_not_supported=La méthode HTTP GET n''est pas supportée par cette URL
http.method_post_not_supported=La méthode HTTP POST n''est pas supportée par cette URL
http.method_put_not_supported=La méthode HTTP PUT n''est pas supportée par cette URL
http.method_delete_not_supported=La méthode HTTP DELETE n''est pas supportée par cette
URL
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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éduite
by
err.io.short_read=Lecture partielle
Should be done for 2.2/2.3 and 2.4 apis...
Who ?
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 unix it means that the connection was closed by remote side... -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 the JVM javadocs (we are using InputStream.read(byte[], int, int)). Under unix it means that the connection was closed by remote side... You're not getting an IOE in that case ? That would have caused a loop. The javadocs are very explicit on this, and 0 shouldn't even happen (I've never seen it on Windows, BTW) :-( From my experience under Unix, I could say that it happends I got a 0 from a read in a socket connection because the remote closed the connection. I don't know JVM implementators handle the case since man pages say that many 'others error could occurs depending on the object which is read' What I do usually when I read from a socket is to loop until I got a -1 (native/java) or IOE (java). So a Java read() should be valid until you got -1 or IOE. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 an install guide similar to the format John Turner has created? Perhaps, you could pass on this request! Do you take a look at site documentation ? for jk http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/doc/ the same included in TC 4.1.12 doc at : http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/index.html Also Redhat RPM are allready available : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.0/rpms/ Thanks to study docs and prebuilt rpms ;) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 and make necessary changes. BTW, did there is some tools which could be add in build script to check in translation are correct, ie don't miss some late keywords... -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 going by and another developer creates another class called
A in the bar package. The code above will not recompile because of the
abiguous class name.
I think costin is speaking about importing java.io.*
or org.apache.*.
BTW, there is ant task, for example CheckStyle
(http://checkstyle.sourceforge.net/) which could be used
and which may be integrated in build/gump to clean code
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 webapp mode (with its relevant options). This webapp mode would generate code and classes which should be deployed in the work directory, exactly the same as if they were dynamically compiled by Jasper (which has the big advantage of using only one big operation mode for everything). Single file mode is IMO useless (dynamic compilation works fine). - In Tomcat 4.1, the options will stay in for compatibility, but the usage help will be modified to be the same as Tomcat 5. I would say that we're extensively JSPC in ant tasks to generate servlet (.java), compile via javac and then put all the classes in a .jar which will be included in the final .war (in lib) which include the jsp mapping generated by JSPC. With this methodology, we're sure that what we deploy on our production will works (no jsp compilation error on users browser), no time spent in compilation at runtime, easy deployement since the WAR alleady included everything. So what did you means by classes which should be deployed in work directory ? - I am -1 to returning to the old webapp option behavior (ie, the generated files should by default be deployed in the work directory, not /WEB-INF/classes). It's not my opinion, JSP are nothing more than servlet after all and why prevent users to have then in WEB-INF/classes or WEB-INF/lib ? Also consider massive web hosting situation with many tomcats running the same WebApps (with differents settings and JVM owner). Having everything in a .war (ie data + precompiled jsp in .class or .jar) make life easier for web admins since upgrading a version is just to replace a .war by a new one. With your proposed solution, they will have update the war, clean the work directory (by hand ?) and move the new classes in the work directory. Also did Manager/Admin will be updated for such task ? ballot +1 [ ] Remove the options -1 [ ] Do not remove the options /ballot Note: Users may vote, but only committers have binding votes. So I'm -1 on removing the options -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 should be used, from alpha0 to alpha7, they're all tagged from the same day -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 (zlib). Includes portions derived from bzip2 (see documentation for details). Contributors: [EMAIL PROTECTED], Ryan Geiss, Andras Varga, Drew Davidson, Peter Windridge, Dave Laundon, Robert Rainwater, Yaroslav Faybishenko, Jeff Doozan, Amir Szekely, et al. Processing plugin dlls: C:\Program Files\NSIS\plugins\*.dll - InstallOptions.dll::dialog - LangDLL.dll::LangDialog - nsisdl.dll::download - nsisdl.dll::download_quiet SetCompressor: bzip2 Processing config: Changing directory to: D: Processing script file: D:\ntomcat.nsi !define: MUI_PRODUCT=Apache Tomcat !define: MUI_VERSION=4.1.14 !define: MUI_NAME=Apache Tomcat Install System 4.1.14 !define: VER_MAJOR=4.1 !define: VER_MINOR=14 OutFile: jakarta-tomcat-4.1.14-LE-jdk14.exe SetCompressor: bzip2 !include: C:\Program Files\NSIS\Contrib\Modern UI\System.nsh !include: could not open file: C:\Program Files\NSIS\Contrib\Modern UI\System.nsh Error in script D:\ntomcat.nsi on line 17 -- aborting creation process -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 find a way to add it to jkant for those who want to
use ant to build native code ;{
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
fileset dir=${tomcat.home}/server/lib
include name=*.jar/
/fileset
fileset dir=${tomcat.home}/common/lib
include name=*.jar/
/fileset
pathelement location=${build.dir}/classes/
path refid=all_other_jars/
/classpath
/taskdef
jasper2 verbose=0
package=my.package
compile=true
validateXml=false
uriroot=${webapp.dir}
webXmlFragment=${build.dir}/generated_web.xml
outputDir=${build.dir}/src/my/package /
loadfile property=generated_web.xml
srcFile=${build.dir}/generated_web.xml /
replace file=${jspui.webapp.dir}/WEB-INF/web.xml
token=lt;!--GENERATED_JSPS--gt;
value=${generated_web.xml} /
javac destdir=${build.dir}/classes
optimize=off
debug=on
srcdir=${build.dir}/src
classpath refid='...' /
include name=my/package/** /
/javac
I'm using a similar way with jspc from Tomcat 3.3.2-dev :
java classname=org.apache.jasper.JspC
classpath refid=jspc.classpath/
arg line=
-d ${build.dir}/src
-uriroot ${build.dir}/dst
-webinc ${build.dir}/dst/WEB-INF/jsp.xml
-webapp ${build.dir}/dst /
/java
javac srcdir=${build.dir}/src
destdir=${build.dir}/classes
debug=${compile.debug}
deprecation=${compile.deprecation}
optimize=${compile.optimize}
excludes=bas*,status*
classpath refid=jsp.compile.classpath/
/javac
mkdir dir=${build.dir}/dst/WEB-INF/lib/
jar jarfile=${build.dir}/dst/WEB-INF/lib/${wname}-jsps-${jarext}.jar
basedir=${build.dir}/classes/
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 jkant for those
who want to
use ant to build native code ;{
Agreed, but the entire purpose of the ioctl is to disable the
nonblocking socket.
We can use the fcntl for that.
int fd_flags;
fd_flags = fcntl(sd, F_GETFL, 0);
#if defined(O_NONBLOCK)
fd_flags = ~O_NONBLOCK;
#elif defined(O_NDELAY)
fd_flags = ~O_NDELAY;
#elif defined(FNDELAY)
fd_flags = ~O_FNDELAY;
#else
/* : this breaks things, but an alternative isn't obvious...*/
return -1;
#endif
if (fcntl(sd, F_SETFL, fd_flags) == -1) {
return errno;
}
That's how its done in apr.
So let use it that way, APR is a reference in native code implementation ;)
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 ;) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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();
} catch (IOException e) {
// Ignore
}
return realFile.toURI().toURL();
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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.EncodingMap; import org.apache.xerces.util.SymbolTable; import org.apache.xerces.util.XMLChar; import org.apache.xerces.util.XMLStringBuffer; import org.apache.xerces.xni.XMLString; -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14405. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14405 Tomcat uses 90% of CPU --- Additional Comments From [EMAIL PROTECTED] 2002-11-11 09:53 --- Please have a look at the following link to know more about the mod_jk bug. http://marc.theaimsgroup.com/?l=tomcat-userm=99112351628144w=2 -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org ajp12 is deprecated and you should consider switching to ajp13 -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
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 !ELEMENT line longer that 80 characters in a DTD, Xerces 2.2.x thrown the misleading exception everybody have seen. 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 included in jakarta-servletapi). Struts 1.1 have a 80 characters format. We have 3 solutions: (1) Bundles Struts 1.1 latest build with Tomcat 4.1.x (2) Compile Struts 1.0.2 with our version of web-app_2_3.xml and commit the jar file in the webapp WEB-INF/lib folder. (3) Wait for a new release of Xerces (or when the fix will be available). The pragmatic way should be to ask for a struts 1.0.2a release including the correct web-app_2_3.xml ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 commit it, It will be included in jk 1.2.1 release -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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, closing connection java.io.InterruptedIOException: Read timed out at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:113) at java.io.BufferedInputStream.fill(BufferedInputStream.java:202) at java.io.BufferedInputStream.read1(BufferedInputStream.java:241) at java.io.BufferedInputStream.read(BufferedInputStream.java:296) at org.apache.jk.common.ChannelSocket.read(ChannelSocket.java:487) at org.apache.jk.common.ChannelSocket.receive(ChannelSocket.java:425) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:540) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:654) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:533) at java.lang.Thread.run(Thread.java:512) The problem is that the socket is NOT close at that time and even if TC free the thread, the socket still exists and make webserver think that it could send request (and sus wait forever replies ) I'll commit a patch to make the socket close in a finally area. 2) The second problem is related to the socket timeout settings. In Ajp13 protocol, the webserver decide when it had to close the socket since it's the client (initiator) of the connection. if tomcat close the socket, the webserver won't detect before it will try to read replies. It's a known problem with Sockets implementation which make that write() calls on a half-closed connection DIDN'T return error CODE, only read() calls with report the error that the remote decided to close the connection. As such I strongly recommand to disable the connectionTime by removing the connectionTimeout in server.xml : !-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 -- Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=0 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ You should know that mod_jk 1.2.0 (don't know for latest 2.0.x), have settings now which make webserver close unused sockets after some time, just to be sure that the tomcat didn't have TOO many unused threads. 3) I saw that linger are set to 100, which is not recommanded in Regards. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] What's the error ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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/catalina/src/conf/server.xml Index: server.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/server.xml,v retrieving revision 1.64 retrieving revision 1.65 diff -u -r1.64 -r1.65 --- server.xml 5 Nov 2002 11:41:49 - 1.64 +++ server.xml 21 Nov 2002 09:42:36 - 1.65 @@ -107,7 +107,7 @@ Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 - acceptCount=10 debug=0 connectionTimeout=2 + acceptCount=10 debug=0 connectionTimeout=0 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ We shouldn't close the connection on the java side to avoid webserver to be puzzled with half-closed sockets. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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.
( this is just an initial fix - I still need to test various
cases )
Revision ChangesPath
1.33 +10 -3 jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
Index: jk_ajp_common.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- jk_ajp_common.c 30 Oct 2002 22:12:20 - 1.32
+++ jk_ajp_common.c 21 Nov 2002 17:53:48 - 1.33
@@ -808,7 +808,7 @@
}
if (!r-is_chunked) {
-ae-left_bytes_to_send -= len;
+ ae-left_bytes_to_send -= len;
}
if (len 0) {
@@ -905,7 +905,14 @@
* for resend if the remote Tomcat is down, a fact we will learn only
* doing a read (not yet)
*/
-if (s-is_chunked || ae-left_bytes_to_send 0) {
+ /* || s-is_chunked - this can't be done here. The original protocol sends the first
+ chunk of post data ( based on Content-Length ), and that's what the java side expects.
+ Sending this data for chunked would break other ajp13 serers.
+
+ Note that chunking will continue to work - using the normal read.
+ */
+
+if (ae-left_bytes_to_send 0) {
int len = ae-left_bytes_to_send;
if (len AJP13_MAX_SEND_BODY_SZ)
len = AJP13_MAX_SEND_BODY_SZ;
Costin was faster than me ;)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 PROTECTED] For info the watchdog (4.0.0) gives the following with Apache-2.0 (head) and TC 4.1.12: +++ [java] [watchdog] FAILED GetRemoteHostTest [java] [watchdog] FAILED ServletRequestWrapperGetRemoteHostTest [java] [watchdog] FAILED GetHeadersTest [java] [watchdog] FAILED HttpServletRequestWrapperGetHeadersTest [java] [watchdog] FAILED HttpServletResponseWrapperSetStatusMsgTest +++ The 2 GetHeaders are due to a not up to date watchdog. (So forget them that is my fault) GetRemoteHost() returns null may this one needs fixing. I take this one :) The chuncking tests are acceptable. Are you sure ? I still have problem while using the perl example code received in bugzilla #14282, but no problem with httpclient you provided. Of course the perl program didn't honor the Connection: close header returned ! And I have committed the patches I had pending... Ok, I closed bug #14293 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 {
static {
}
public _0002fjsp_0002fsnp_0002fsnoop_0002ejspsnoop_jsp_0( ) {
}
private boolean _jspx_inited = false;
.
What's the problem ?
I'm using TC 4.1.x HEAD into my Eclipse IDE, and all the class / source
are on the workspace
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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/apache/jk/common HandlerRequest.java jk/java/org/apache/jk/server JkCoyoteHandler.java Log: Fix null getRemoteHost. Lasy extraction of ssl certs to speed up jk/ajp13 when under SSL Revision ChangesPath 1.18 +6 -24 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java Index: HandlerRequest.java + // SSL certificate extraction is costy, moved to JkCoyoteHandler +req.setAttribute(SSLSupport.CERTIFICATE_KEY, certString); break; As much as I very much like the switch to constants, this is still wrong. As far back as the Servlet 2.2 spec (aka Tomat 3.3) this is required to be a java.security.cert.X509Certificate []. I'll have to -1 this section of the patch because of this, but the rest looks really good! I just move some code from ajp to JKHandler to speed up the processing under SSL. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 week for JK1.21, and JK2 2.0.2 is planned to be tagged on Monday, so we could have those and TC in sync... amazing ;). JK 1.2.1 will be tagged tomorrow -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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) {
// Ignore
}
return realFile.toURI().toURL();
}
Did someone has an idea to make this part of code JDK 1.2 compatible ?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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.properties
Index: LocalStrings_fr.properties
===
# 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
Thanks, better now than never ;)
BTW, who will make the new jar and release for 2.2 and 2.3 with french
localization?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat-committers mailing list
Martin Algesten wrote: Just for our non-committers peace of mind, what is the purpose of this list? What kind of information is it that we are to be denied or have delayed? Discussing for example possible security issues and resolve them before making a public announce ! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat-committers mailing list
Laxmikanth M.S. wrote: sound good What's sounding good ? Reporting and Fixing security problems before making them public or Coming together is the beginning, staying together is progress and working together is Success ? Regards Laxmikanth M S Off* : 6610330 extn 1256 Res* : 5267150 http://www.sonata-software.com Coming together is the beginning, staying together is progress and working together is Success What lies behind us and what lies before us are tiny matters compared to what lies within us - Emerson -Original Message- From: Henri Gomez [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 7:00 PM To: Tomcat Developers List Subject: Re: tomcat-committers mailing list Martin Algesten wrote: Just for our non-committers peace of mind, what is the purpose of this list? What kind of information is it that we are to be denied or have delayed? Discussing for example possible security issues and resolve them before making a public announce ! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JTC will be tagged JK_1_2_1 within minutes ....
And just after being tagger, jk 1.2 will be moved to jk 1.2.2-dev (to follow the httpd way) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JTC release 1.2.1 just tagged JK_1_2_1
Henri Gomez wrote: And just after being tagger, jk 1.2 will be moved to mod_jk 1.2.2-dev (to follow the httpd way) BTW, do you agree to change the version from jk-1.2.2-beta-1 to mod_jk-1.2.2-dev, to follow the way Apache 1.3/2.0 numbering ? I don't think will make ever beta-1, beta-2.. A+ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Announce] JK 1.2.1 released
Hi to all, mod_jk 1.2.1 has been released and is available at : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1/ For now binaries are available for : - Linux i386 (Apache 1.3 with/without SSL, Apache 2.0 with SSL) - iSeries (Apache 2.0.39 for OS/400 V5R1/V5R2) Other platforms ports should follow shortly. Changes between JK 1.2.1 and JK 1.2.0 : * Don't send initial chunk for chunked encoding, fix bugzilla report #14282 [costin] * Add perl scripts for analyzing mod_jk logs and generating graphs/reports [glenn] * Make JK honor the CanonicalHost directive. [hgomez] * Log cleanup [costin] * Fix typos in jk xdocs/docs [hgomez] * Add JkRequestLogFormat to Apache 2.0 [hgomez] * Final patches to make JK iSeries compliant [hgomez] Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
Mladen Turk wrote: Hi to all, JK2 2.0.2 has been released and is available at : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v 2.0.2/ For now binaries are available for WIN32 only: linux binaries and rpms to be released tomorrow ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_global.h
[EMAIL PROTECTED] wrote: mturk 2002/11/27 09:12:05 Modified:jk/native2/include jk_global.h Log: Change the version number to the 2.0.3 and mark as not nonreleased. The exposed version will be mod_jk2/2.0.3-beta-1. Perhaps we should change the beta to dev? +1 to switch jk/jk2 to -dev, it's the Apache HTTPD numbering schema -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
Henri Gomez wrote: Mladen Turk wrote: Hi to all, JK2 2.0.2 has been released and is available at : http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/release/v 2.0.2/ For now binaries are available for WIN32 only: linux binaries and rpms to be released tomorrow ;) While making the linux binaries, for Apache 2.0.43, I see that jkjni.so are not generated, only jkjni.a and jkjni.la ? What's the problem ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
Probably libtool. The one of the Apache 2.0.43 you are using. What's the heck with libtool again ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
Pedro Igor Craveiro e Silva wrote: I trying to configure the Apache + JServ, but a have a problem. When the apache is started it return a error message like this: Cannot load /usr/local/www/apache/libexec/mod_jk-2.0.42.so into server: /usr/local/www/apache/libexec/mod_jk-2.0.42.so: Undefined symbol ap_hook_post_config ./apachectl startssl: httpd could not be started My apache is a 1.3.27 and i using the AJP13 connector and tomcat 4.1.12. Tanks, mod_jk-2.0.42.so is for Apache 2.0.42 and later. For Apache 1.3.27 use instead mod_jk-1.3-eapi.so (since you've got apache+mod_ssl) Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
jean-frederic clere wrote: Henri Gomez wrote: Probably libtool. The one of the Apache 2.0.43 you are using. What's the heck with libtool again ? Look in the build/jk2/apache2/jkjni.la Probably there is a jkjni.a instead jkjni.so there. Yes jkjni.la and jkjni.a May be you only have a libapr-0.a in your Apache 2.0.43. No, I've got libapr.so And I've got mod_jk2.so -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
Pedro Igor Craveiro e Silva wrote: Thakns. ... but just one more, i don´t find this mod, do you have a clue ?? It's next to the other one ! http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.1/bin/linux/i386/mod_jk-1.3-eapi.so -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
jean-frederic clere wrote: Clere, Jean-Frederic wrote: While building with Apache-1.3 I have the problem that it only builds with apxs: cd jk/native2/server/apache13; gmake -f Makefile.apxs The next problem is that this mod_jk2.so is not ok: +++ bash-2.03$ bin/apachectl start Syntax error on line 224 of /export/home2/apache20/apache26/conf/httpd.conf: Cannot load /export/home2/apache20/apache26/libexec/mod_jk2.so into server: ld.so.1: /export/home2/apache20/apache26/bin/httpd: fatal: relocation error: file /export/home2/apache20/apache26/libexec/mod_jk2.so: symbol jk2_service_apache13_init: referenced symbol not found bin/apachectl start: httpd could not be started +++ apache13_init called in jk2 for Apache 2.0 ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ANNOUNCEMENT] JK2-2.0.2 released
Very weird. Send me the complete output of make. here it is : httpd2/lib -lcrypt -lapr-0 -lpcre -lpcreposix ../../../build/jk2/apache2/jk_jni_aprImpl.lo ../../../build/jk2/apache2/jk_channel_apr_socket.lo ../../../build/jk2/apache2/jk_channel.lo ../../../build/jk2/apache2/jk_channel_jni.lo ../../../build/jk2/apache2/jk_channel_socket.lo ../../../build/jk2/apache2/jk_channel_un.lo ../../../build/jk2/apache2/jk_config.lo ../../../build/jk2/apache2/jk_config_file.lo ../../../build/jk2/apache2/jk_endpoint.lo ../../../build/jk2/apache2/jk_env.lo ../../../build/jk2/apache2/jk_handler_logon.lo ../../../build/jk2/apache2/jk_handler_response.lo ../../../build/jk2/apache2/jk_logger_file.lo ../../../build/jk2/apache2/jk_logger_win32.lo ../../../build/jk2/apache2/jk_map.lo ../../../build/jk2/apache2/jk_md5.lo ../../../build/jk2/apache2/jk_msg_ajp.lo ../../../build/jk2/apache2/jk_mutex.lo ../../../build/jk2/apache2/jk_mutex_proc.lo ../../../build/jk2/apache2/jk_mutex_thread.lo ../../../build/jk2/apache2/jk_nwmain.lo ../../../build/jk2/apache2/jk_objCache.lo ../../../build/jk2/apache2/jk_pool_apr.lo ../../../build/jk2/apache2/jk_pool.lo ../../../build/jk2/apache2/jk_registry.lo ../../../build/jk2/apache2/jk_requtil.lo ../../../build/jk2/apache2/jk_shm.lo ../../../build/jk2/apache2/jk_signal.lo ../../../build/jk2/apache2/jk_uriEnv.lo ../../../build/jk2/apache2/jk_uriMap.lo ../../../build/jk2/apache2/jk_user.lo ../../../build/jk2/apache2/jk_vm_default.lo ../../../build/jk2/apache2/jk_worker_ajp13.lo ../../../build/jk2/apache2/jk_workerEnv.lo ../../../build/jk2/apache2/jk_worker_jni.lo ../../../build/jk2/apache2/jk_worker_lb.lo ../../../build/jk2/apache2/jk_worker_run.lo ../../../build/jk2/apache2/jk_worker_status.lo rm -fr ../../../build/jk2/apache2/.libs/jkjni.la ../../../build/jk2/apache2/.libs/jkjni.* ../../../build/jk2/apache2/.libs/jkjni.* *** Warning: This library needs some functionality provided by -lapr-0. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module jkjni. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. ar cru ../../../build/jk2/apache2/.libs/jkjni.a ../../../build/jk2/apache2/jk_jni_aprImpl.lo ../../../build/jk2/apache2/jk_channel_apr_socket.lo ../../../build/jk2/apache2/jk_channel.lo ../../../build/jk2/apache2/jk_channel_jni.lo ../../../build/jk2/apache2/jk_channel_socket.lo ../../../build/jk2/apache2/jk_channel_un.lo ../../../build/jk2/apache2/jk_config.lo ../../../build/jk2/apache2/jk_config_file.lo ../../../build/jk2/apache2/jk_endpoint.lo ../../../build/jk2/apache2/jk_env.lo ../../../build/jk2/apache2/jk_handler_logon.lo ../../../build/jk2/apache2/jk_handler_response.lo ../../../build/jk2/apache2/jk_logger_file.lo ../../../build/jk2/apache2/jk_logger_win32.lo ../../../build/jk2/apache2/jk_map.lo ../../../build/jk2/apache2/jk_md5.lo ../../../build/jk2/apache2/jk_msg_ajp.lo ../../../build/jk2/apache2/jk_mutex.lo ../../../build/jk2/apache2/jk_mutex_proc.lo ../../../build/jk2/apache2/jk_mutex_thread.lo ../../../build/jk2/apache2/jk_nwmain.lo ../../../build/jk2/apache2/jk_objCache.lo ../../../build/jk2/apache2/jk_pool_apr.lo ../../../build/jk2/apache2/jk_pool.lo ../../../build/jk2/apache2/jk_registry.lo ../../../build/jk2/apache2/jk_requtil.lo ../../../build/jk2/apache2/jk_shm.lo ../../../build/jk2/apache2/jk_signal.lo ../../../build/jk2/apache2/jk_uriEnv.lo ../../../build/jk2/apache2/jk_uriMap.lo ../../../build/jk2/apache2/jk_user.lo ../../../build/jk2/apache2/jk_vm_default.lo ../../../build/jk2/apache2/jk_worker_ajp13.lo ../../../build/jk2/apache2/jk_workerEnv.lo ../../../build/jk2/apache2/jk_worker_jni.lo ../../../build/jk2/apache2/jk_worker_lb.lo ../../../build/jk2/apache2/jk_worker_run.lo ../../../build/jk2/apache2/jk_worker_status.lo ranlib ../../../build/jk2/apache2/.libs/jkjni.a creating ../../../build/jk2/apache2/jkjni.la (cd ../../../build/jk2/apache2/.libs rm -f jkjni.la ln -s ../jkjni.la jkjni.la) /etc/httpd2/build/libtool --mode=install cp ../../../build/jk2/apache2/jkjni.la `pwd`/../../../build/jk2/apache2 cp ../../../build/jk2/apache2/.libs/jkjni.lai /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.la cp ../../../build/jk2/apache2/.libs/jkjni.a /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a ranlib /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a chmod 644 /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a
Re: [ANNOUNCEMENT] JK2-2.0.2 released
jean-frederic clere wrote: Henri Gomez wrote: Very weird. Send me the complete output of make. here it is : httpd2/lib -lcrypt -lapr-0 -lpcre -lpcreposix ../../../build/jk2/apache2/jk_jni_aprImpl.lo ../../../build/jk2/apache2/jk_channel_apr_socket.lo ../../../build/jk2/apache2/jk_channel.lo ../../../build/jk2/apache2/jk_channel_jni.lo ../../../build/jk2/apache2/jk_channel_socket.lo ../../../build/jk2/apache2/jk_channel_un.lo ../../../build/jk2/apache2/jk_config.lo ../../../build/jk2/apache2/jk_config_file.lo ../../../build/jk2/apache2/jk_endpoint.lo ../../../build/jk2/apache2/jk_env.lo ../../../build/jk2/apache2/jk_handler_logon.lo ../../../build/jk2/apache2/jk_handler_response.lo ../../../build/jk2/apache2/jk_logger_file.lo ../../../build/jk2/apache2/jk_logger_win32.lo ../../../build/jk2/apache2/jk_map.lo ../../../build/jk2/apache2/jk_md5.lo ../../../build/jk2/apache2/jk_msg_ajp.lo ../../../build/jk2/apache2/jk_mutex.lo ../../../build/jk2/apache2/jk_mutex_proc.lo ../../../build/jk2/apache2/jk_mutex_thread.lo ../../../build/jk2/apache2/jk_nwmain.lo ../../../build/jk2/apache2/jk_objCache.lo ../../../build/jk2/apache2/jk_pool_apr.lo ../../../build/jk2/apache2/jk_pool.lo ../../../build/jk2/apache2/jk_registry.lo ../../../build/jk2/apache2/jk_requtil.lo ../../../build/jk2/apache2/jk_shm.lo ../../../build/jk2/apache2/jk_signal.lo ../../../build/jk2/apache2/jk_uriEnv.lo ../../../build/jk2/apache2/jk_uriMap.lo ../../../build/jk2/apache2/jk_user.lo ../../../build/jk2/apache2/jk_vm_default.lo ../../../build/jk2/apache2/jk_worker_ajp13.lo ../../../build/jk2/apache2/jk_workerEnv.lo ../../../build/jk2/apache2/jk_worker_jni.lo ../../../build/jk2/apache2/jk_worker_lb.lo ../../../build/jk2/apache2/jk_worker_run.lo ../../../build/jk2/apache2/jk_worker_status.lo rm -fr ../../../build/jk2/apache2/.libs/jkjni.la ../../../build/jk2/apache2/.libs/jkjni.* ../../../build/jk2/apache2/.libs/jkjni.* *** Warning: This library needs some functionality provided by -lapr-0. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module jkjni. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. ar cru ../../../build/jk2/apache2/.libs/jkjni.a ../../../build/jk2/apache2/jk_jni_aprImpl.lo ../../../build/jk2/apache2/jk_channel_apr_socket.lo ../../../build/jk2/apache2/jk_channel.lo ../../../build/jk2/apache2/jk_channel_jni.lo ../../../build/jk2/apache2/jk_channel_socket.lo ../../../build/jk2/apache2/jk_channel_un.lo ../../../build/jk2/apache2/jk_config.lo ../../../build/jk2/apache2/jk_config_file.lo ../../../build/jk2/apache2/jk_endpoint.lo ../../../build/jk2/apache2/jk_env.lo ../../../build/jk2/apache2/jk_handler_logon.lo ../../../build/jk2/apache2/jk_handler_response.lo ../../../build/jk2/apache2/jk_logger_file.lo ../../../build/jk2/apache2/jk_logger_win32.lo ../../../build/jk2/apache2/jk_map.lo ../../../build/jk2/apache2/jk_md5.lo ../../../build/jk2/apache2/jk_msg_ajp.lo ../../../build/jk2/apache2/jk_mutex.lo ../../../build/jk2/apache2/jk_mutex_proc.lo ../../../build/jk2/apache2/jk_mutex_thread.lo ../../../build/jk2/apache2/jk_nwmain.lo ../../../build/jk2/apache2/jk_objCache.lo ../../../build/jk2/apache2/jk_pool_apr.lo ../../../build/jk2/apache2/jk_pool.lo ../../../build/jk2/apache2/jk_registry.lo ../../../build/jk2/apache2/jk_requtil.lo ../../../build/jk2/apache2/jk_shm.lo ../../../build/jk2/apache2/jk_signal.lo ../../../build/jk2/apache2/jk_uriEnv.lo ../../../build/jk2/apache2/jk_uriMap.lo ../../../build/jk2/apache2/jk_user.lo ../../../build/jk2/apache2/jk_vm_default.lo ../../../build/jk2/apache2/jk_worker_ajp13.lo ../../../build/jk2/apache2/jk_workerEnv.lo ../../../build/jk2/apache2/jk_worker_jni.lo ../../../build/jk2/apache2/jk_worker_lb.lo ../../../build/jk2/apache2/jk_worker_run.lo ../../../build/jk2/apache2/jk_worker_status.lo ranlib ../../../build/jk2/apache2/.libs/jkjni.a creating ../../../build/jk2/apache2/jkjni.la (cd ../../../build/jk2/apache2/.libs rm -f jkjni.la ln -s ../jkjni.la jkjni.la) /etc/httpd2/build/libtool --mode=install cp ../../../build/jk2/apache2/jkjni.la `pwd`/../../../build/jk2/apache2 cp ../../../build/jk2/apache2/.libs/jkjni.lai /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.la cp ../../../build/jk2/apache2/.libs/jkjni.a /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a ranlib /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/server/apache2/../../../build/jk2/apache2/jkjni.a chmod 644 /home/root/jakarta-tomcat-connectors-jk2-2.0.2-src/jk
Re: [ANNOUNCEMENT] JK2-2.0.2 released
BTW: How did you build the mod_jk2.so for Apache-2.0? mod_jk2.so didn't link against libapr, since apache2 allready provideit, but jkjni need it, that's why the build work for mod_jk2. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
Pedro Igor Craveiro e Silva wrote: Thanks, Henri ... You came from the sky heuu, no from Lyon, France ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
Pedro Igor Craveiro e Silva wrote: I´m not using Linux, but FreeBSD. Hum, that's why !!! BTW, the is no Apache 1.3 binary for FreeBSD, I only built one for Apache 2.0 ;( -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_jk-2.0.42.so
Pier Fumagalli wrote: On 28/11/02 7:37 pm, in article 000701c2970d$2d408f90$[EMAIL PROTECTED], Pedro Igor Craveiro e Silva [EMAIL PROTECTED] wrote: Ok. But, with that first module(mod_jk2.(etc)) the i was using i can put the apache e tomcat together? FreeBSD contains a Linux emulator, but AFAICR, it ships currently with GLIBC-5 ... You'd better off recompiling the module (Apache part) native for FreeBSD and the JNI lib for Linux GLIBC-5... +1 Prefer a native port or install Apache 2.0.43 for FreeBSD... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Double Version
Laxmikanth M.S. wrote: Hi , A question for tomcat-user list please. I have installed two versions of Tomcat and apache running together on the same Machine Apache1.3.27 - Tomcat3.3.1 Apache1.3.27 - Tomcat4.1.12 Make Apaches and Tomcats listens on differents ports: Apache1.3.27 (80) - Tomcat3.3.1 (8080, 8007, 8009) Apache1.3.27 (8092) - Tomcat4.1.12 (8180, 8109) is it possible to run the servers in the same macine. I am not able to start apache servers. Is there any way to resolve this. thanks Regards Laxmikanth M S Off* : 91-80-6610330 extn 1256 Res* : 91-80-5267150 http://www.sonata-software.com Coming together is the beginning, staying together is progress and working together is Success What lies behind us and what lies before us are tiny matters compared to what lies within us - Emerson * Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. * -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Apache Tomcat 4.1.16 AJP not working
M wrote: Looking at the netstat on the machine I can see tomcat is bound to the port 8009 and can connect to it with telnet, apache works if I go back to tomcat 4.1.14. From the apache logs: [Tue Dec 03 16:04:22 2002] [jk_connect.c (143)]: jk_open_socket, connect() failed errno = 111 [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (196)]: In jk_endpoint_t::connect_to_tomcat, failed errno = 111 [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (635)]: Error connecting to the Tomcat process. [Tue Dec 03 16:04:22 2002] [jk_ajp13_worker.c (848)]: In jk_endpoint_t::service, send_request failed in send loop 0 As we're using apache 1.3 and can't use warp it's fairly critical to us... should I raise a bug report? Which release of mod_jk ? You should try the 1.2.1 release -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Cluster features
Remy Maucherat wrote: Hi, I think the clustering features in Tomcat 5 should get an overhaul. Despite some licensing dicrepancies, I plan to use JavaGroups for the task (LGPL license), as well as some code which was donated a while ago by Filip Hanik. Based on what is already done, the amount of work that will have to be done to have quality clustering features seems small. Most of the current clustering API will be removed in the process, since it doesn't seem to be maintained anymore, and didn't evolve past experimental stage (if I am wrong on that, let me know). I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB standalone JAR. Configuring Tomcat for clustering will be quite easy once all the code is in place. I don't know if that plan is acceptable for everyone. Originally, I -1ed the code submission because of licensing and absence of integration with the existing Cluster API. The licensing issue is still there, but since the Cluster API now seems sort of dead, another solution has to be found (IMO, of course there's JK available). Comments ? I could be a full +1, if we could convince them to make JavaGroups BSD/Apache licence. Or use something related with BSD license (see mod_backend) Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Tomcat modules
Remy Maucherat wrote: Hi, I plan to reorganize the jakarta-tomcat-catalina repository as follows: - catalina folder: Catalina core; this depends on the servlet API - modules folders: Optional functionality and modules (one example is clustering), but which depends on the Catalina API; this does not directly depend on the servlet API Alternately, using another repository (j-t-modules) is possible, but just using a folder looks simpler, as there is an API dependency. I propose putting independent modules in j-t-connectors (like eventually some of the naming features). ballot +1 [ ] -1 [ ] /ballot +0 I'm pretty busy these days so I can't help even if this and the clustering are of very interest for me. Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/7 9:37 AM, Glenn Nielsen [EMAIL PROTECTED] wrote: I will consider voting +1 if any of the other tomcat devs who want this will volunteer to be the release manager for the servlet only distribution. I would find this handy when using Tomcat as a SOAP server where JSP is not needed. Glenn Well this thread make some noise. I will volunteer to be the release manager. How will you synchronise with main branch ? Will you wait TC 5 release to make the SMALL TC5 distro or will you follow another cycle of release ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Pier Fumagalli wrote: On 8/12/02 0:43 Jon Scott Stevens [EMAIL PROTECTED] wrote: on 2002/12/7 4:25 PM, Pier Fumagalli [EMAIL PROTECTED] wrote: Jon, I'm very sorry mate, you're 4 months too late :-( I lost my fight about this very same topic back then... Maybe to late for your opinion, but honestly, I haven't been that impressed with Jetty. In my case it speeds up my stuff around 3/4 times faster. And the footprint is considerably slower... Depends on the app... I make benchs between TC 4.1.16 and latest jetty, and TC 4.1 was about 30% faster on servlet (didn't test JSP). I saw very little if any speed increase with Jetty and Scarab and I actually consider Jetty's distribution to be packed with more crud than Tomcat's...but maybe I'm just biased by Tomcat. At this point, I don't think that with JSR 154 and JSR 152 being separate, there is much that anyone here can say negative about distributing JSR 154 only engine. Clearly there is a demand. Clearly it is a good thing to have options. What think JCP about a JSR 154 only engine ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
adding content-type for Apache 2.0 jk/jk2
Hi, I'm playing currently with mod_jk + mod_deflate on Apache 2.0, and it seems it will be needed to set the content-type in response in Apache 2.0 to allow mod_deflate to compress only text/html, text/xml contents. It seems in that case will need to parse the tomcat response to set content-type accordingly with ap_set_content_type. What do you think about ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Ignacio J. Ortega wrote: Jon, Create a separate minimal JSR 154 only distribution of Tomcat 4.x: +0, i could be +1 but i'm out of time to offer any help in tomcat as a whole, and of course for this particular proposal, but i dont see anything wrong in it, more i do see it as another step, in the GTU Path ( GTU stand for Great Tomcat Unification :).. Nota that adopting modules for Tomcat could be a way to satisfy everybody needs. In such case I'm +1 to have a minimal Tomcat which will load modules to have JSP, JMX, admin supports. If anything could be set in server.xml, it will help have an uniq distribution, that everybody will be able to tune for its own use. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Costin Manolache wrote: Since things may get confusing around here, I would like to have an official vote on my prior proposal. This is the list of included features: Libs: - JMX - JAAS - JNDI - digester ( and beanutils, collections it needs ). - modeler - ant ( used for startup and automation of some tasks ) - commons-logging When/if the JNDI-based abstraction of config files is ready we'll not need digester - but most likely it'll still be required by modeler, and also by jasper, so I don't think we can remove it. Tomcat: - subset of catalina ( non-deprecated interfaces and base impl that is required for tomcat to work ). - coyote - tomcat-util - http11/jk2 - all valves/etc that are required for tomcat to operate. - naming - jasper ( at least jasper runtime - but probably the whole thing ). Votes: [ ] +1 I like the idea, I might help [ ] -1 I don't like the idea, I won't help. +0,5 : I like the idea, but have little time to help these days. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: If the vote actually passes, I'd like to have only one minimal Tomcat distribution, which would mean no admin and no Jasper (with separate optional Jasper binaries available). JMX can be used directly (using a MX4J connector + MC4J, assuming MC4J updates to MX4J 1.1.1 as we did) to administer the server, without the need to use the admin webapp. Now - this is not nice ! I don't know why my proposal for a minimal tomcat that includes jsr152 and jsr154 shouldn't be allowed. Ok, I'll make a VOTE and try to gather the votes - hopefully I'll get at least 3 +1 votes ( and you'll at least -0 it :-). I'd really like to avoid the proliferation of too many distributions. The light distribution confused a lot of users who didn't know what they needed, from what I've seen (from what I've read on tc-user). To restate it: if we do a minimal version and it is voted to be Jasper less, then I think we shouldn't have a third minimal-but-with-Jasper distribution. Rather, I'd have a separate binary holding the Jasper JARs. That's just my preference anyway. BTW, in such vote, it should be Yes or No. If you don't care, then you shouldn't vote. What about using a minimal tomcat core with plugged modules to give access to jsp/jmx ? Will make both Costin, and Jon happy and let us have only one distribution with clear indication in server.xml on how to activate/desactive such module. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/9 7:27 AM, Remy Maucherat [EMAIL PROTECTED] wrote: I'd really like to avoid the proliferation of too many distributions. I don't agree with that. There is nothing wrong with giving users choices. There is many things something wrong with many distributions : - Users may be puzzled by seeing too many tomcat distributions. - Who will be the release managers for the 'alternative distributions', may be Jon is candidate ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/9 7:32 AM, Henri Gomez [EMAIL PROTECTED] wrote: What about using a minimal tomcat core with plugged modules to give access to jsp/jmx ? Will make both Costin, and Jon happy and let us have only one distribution with clear indication in server.xml on how to activate/desactive such module. That does not make me happy. You are missing my point. Read the subject line of this message. I read YOUR SUBJECT LINE, and that's why I feel that a common distribution with modules could be the solution. The idea being to provide a minimal tomcat binary and many external modules which will be linked at runtime if present, Apache 2.0 does it that way, why could we do the same. All we need is a more modular approach of TC 5, which should be able to load modules (JMX/JASPER) if available in classpath. If you take a look at how decent packaging tools like rpm/debian works, they are able to install a PRIMARY PACKAGE and OPTIONAL PACKAGES. For your purpose, scarab for example, you could only stay with the bare minimum TC 5, without installing the rest of TC 5. What about ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Pier Fumagalli wrote: On 9/12/02 17:14 Jeanfrancois Arcand [EMAIL PROTECTED] wrote: Youy don't need to learn JSP/Admin Tool if you don't use it. The actual Tomcat installation doesn't require you to learn the Admin Tool or JSP As I said 6 or so months ago... That thing is a security hole as big as the Empire State Building... As most of the stuff that make up tomcat... We have some bugs in JSR-154, few in Jasper, few in JSSI, few in CGI... All together it makes a load of em... I didn't understand the problem with the admin/manager tools, since they aren't mandatory and very easy to desactivate. If someone can come up with a Servlet-only distribution, at least I won't get holes from all the other (totally useless) components... JSP ? Pier (a _user_ now) And that's sad. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Minimal or Modular it's up to you
There was many noise these days about making another release of tomcat (the minimal one covering only JSR154), and another proposal to make a modular Tomcat. It may be because my mother language is french, but I still didn't understand why Tomcat commiters didn't find an arrangement on these 2 proposals which GOES in the same direction. What Jon and Pier want is a minimal distribution of Tomcat 5. What Costin proposed is to make Tomcat 5 more modular, which is very similar to what make Apache HTTP server so successfull. Why didn't merge the both proposal ? - Make a Tomcat distribution which is composed of : - a minimal tomcat core - extension modules. People will be free to install the core, and the modules they want to use (JMX/JASPER/JNDI/JK2). Java is not so bad in introspection and class discovery and should be able to detect what is present and what could be activated. To mimic the HTTPD way, the server.xml could have entries likes these : IfModule JMX Listener className=org.apache.catalina.mbeans.ServerLifecycleListener debug=0/ Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener debug=0/ /IfModule IfModule JK2 Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=2 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ /IfModule The goal will be : - make happy people who need a minimal distribution, for example those who want to embed it on low memory device. - make happy people who want to get the full artillery to play and experiment with. - and in fine attract 'modules' writers, à la HTTPD way, developpers which make Apache 1.x/2.x servers so widely used today. And of course, restore the consensus which was present till the TC 5.0 project was initiated by the commiters who previously spent many times developping each one THEIR OWN vision of servlet container (3.3/4.0). But we're in a real world and since commiters are after all humans, I politely recommand to people who do NOT REALLY WANT TO BE CONSTRUCTIVE and may restart a new Tomcat War, to try to convince others teams making others servlet implementation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Minimal or Modular it's up to you
Jon Scott Stevens wrote: on 2002/12/10 1:19 AM, Henri Gomez [EMAIL PROTECTED] wrote: What Jon and Pier want is a minimal distribution of Tomcat 5. No. What I want is a distribution of a JSR 154 container with nothing more than the RI of JSR 154. Period. Ok, so just take the tomcat core and don't install/activate the jasper module. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
Pier Fumagalli wrote: On 10/12/02 8:40 am, in article [EMAIL PROTECTED], Remy Maucherat [EMAIL PROTECTED] wrote: Like the httpd, I'd prefer having a full distribution of all safe (yes, Jasper is safe) and generally useful modules. Experienced users can tweak the configuration to their liking, and it is easy to do, but the beginners get an easy to run environment which does what they need (and obviously a lot more, since you'd want the distribution to fill the needs of 95% of users). There is one big huge difference... Modules are DSOs, if you don't enable them in your httpd.conf, they don't get loaded, they don't get used Disabling all of them can be done by sed 's/^LoadModule/#LoadModule/g'. If you get a binary distribution... (which, btw, doesn't enable most of them, it just _ships_ them in the same bundle...) If you don't get a binary distribution, when I build, I have a lot of tiny --enable and --disable flags... I can _choose_ what to build, what to install, what goes on my machine... This doesn't happen with Tomcat and it SUCKS ASS. :-) It's exactly what SHOULD BE DONE in a modular approach of TC 5. A small core with essential functionalities, and a bunch of modules, which will live in modules dir or activated if module-xxx.xml found in conf directory of tomcat. Don't compare yourself to HTTPD, learn from them, that's the only thing you can do... :-) (suggestion from someone who has been around long enough). I learn HTTPD everyday, and yesterday I even correct mod_webapp for Apache 2.0 ! New signature! :-) Pier nananere -- [...] mod_webapp, which was *the* main reason for many people not to adopt Tomcat 4.x - Remy MaucheratWorks for me - Pier Fumagalli -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/10 12:53 AM, Henri Gomez [EMAIL PROTECTED] wrote: The idea being to provide a minimal tomcat binary and many external modules which will be linked at runtime if present, Apache 2.0 does it that way, why could we do the same. You are repeating my ideas that I have already said on the list. Yes but add the ability to activate/include modules, which is the Costin idea ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Jon Scott Stevens wrote: on 2002/12/10 12:49 AM, Henri Gomez [EMAIL PROTECTED] wrote: - Who will be the release managers for the 'alternative distributions', may be Jon is candidate ? I already volunteered to manage the distribution that I propose. I have been doing distributions of servlet containers since you guys were in diapers. Jon, you're a little younger than me so, 'du respect'. BTW, we're not discussing here what has be done in the past but what should be done in the future. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Filip Hanik
Remy Maucherat wrote: I'd like to nominate Filip Hanik filip at filip.net as a committer on the Tomcat project. Filip has written the clustering code that was committed recently in the Tomcat 5 CVS, and is willing to maintain it, as well as continuing to improve it (including supporting large clusters). Filip is one of the authors of JavaGroups, the Java based clustering framework used in the new Tomcat clustering code. +1 and +100 to have javagroups as a Jakarta project. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] mod_jk - chroot and user issues
Kurt Miller wrote:
I recently created a port of mod_jk-1.2.1 for OpenBSD and needed to make
some minor patches to mod_jk. OpenBSD 3.2 has Apache 1.3.26 configured as
ServerType standalone, to chroot to /var/www and run as user www by default.
This combination requires a few minor patches so that mod_jk will continue
to work after an Apache restart.
I'm fine with the makefile updates but there is a problem with change in
apache-1.3/mod_jk.c since there is no ap_server_strip_chroot call
available on my Linux box.
Is it an OpenBSD specific call ?
If so we'll have to add some #ifdef OPEN_BSD and I'd like to
have others jk commiters opinion. (I allready put too much
#ifdef AS400 ;)
I'll be to use a #ifdef CHROOTED_APACHE :
--- apache-1.3/mod_jk.c.orig Tue Nov 26 12:26:25 2002
+++ apache-1.3/mod_jk.c Mon Dec 9 01:59:18 2002
...
/* we need an absolut path */
conf-worker_file = ap_server_root_relative(cmd-pool,worker_file);
#ifdef CHROOTED_APACHE
ap_server_strip_chroot(conf-worker_file,0);
#endif
if (conf-worker_file == worker_file)
conf-worker_file = ap_pstrdup(cmd-pool,worker_file);
/* we need an absolut path */
conf-log_file = ap_server_root_relative(cmd-pool,log_file);
#ifdef CHROOTED_APACHE
ap_server_strip_chroot(conf-log_file,0);
#endif
if ( conf-log_file == log_file)
conf-log_file = ap_pstrdup(cmd-pool,log_file);
@@ -1742,7 +1746,7 @@ static void jk_init(server_rec *s, ap_po
/* Open up log file */
if(conf-log_file conf-log_level = 0) {
if(!jk_open_file_logger((conf-log), conf-log_file,
conf-log_level)) {
#ifdef CHROOTED_APACHE
conf-log = main_log;
#else
conf-log = NULL;
#endif
} else {
main_log = conf-log;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c
[EMAIL PROTECTED] wrote: hgomez 2002/12/11 02:40:38 Modified:jk/native/apache-1.3 mod_jk.c Log: Allow log file use in chrooted (for now only OpenBSD) environement. You'll have to define CHROOTED_APACHE (or later will use the define added by OpenBSD if any) provided by Kurt Miller. if OpenBSD (and other chrooted Apache) have a specific define, I'll use it instead of CHROOTED_APACHE. Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Costin Manolache wrote: Bill Barker wrote: Urm, err, the users that can't read may include you ;-). Jon withdrew the vote above. This means that this is officially 'not getting anywhere', at least until Jon re-submits his re-worked proposal. The fact that Jon withdrew the vote doesn't change any of the arguments and opinions that were expressed about profiles and minimal. IMO we are very close to consensus on profiles, and I think we can rich a consensus on an embeded. I think we should just change the subject line - and have another vote to make sure we're all on the same page. Agreed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] mod_jk - chroot and user issues
FWIW, I like the feature based define. If other OS's or Apache incorporate OpenBSD's chroot option, then it wouldn't need to be changed. On the other hand, if the consensus is not to commit the patch into mod_jk to keep the cruft down, the OpenBSD port can apply the patch (assuming my port is committed). Ok, it's in jk CVS and you'll just have to add -DCHROOTED_APACHE to check it. Thanks to give some feedback. Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
