Re: Translations update
0074060468940215 El mié., 28 de nov. de 2018 11:04 PM, Esther Montes < esthermontes...@gmail.com> escribió: > Ola buenas noches nomás para darle mi número de cuenta ok gracias > > El mié., 28 de nov. de 2018 10:58 AM, Christopher Schultz < > ch...@christopherschultz.net> escribió: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> André, >> >> On 11/27/18 06:01, André Warnier (tomcat) wrote: >> > I must say that, although I tried to participate as much I could, I >> > have some reservations about this whole translation project. And >> > that is because most of the original messages which I have seen, >> > are really "technical" and not at all oriented to a general public >> > which may be using applications built on tomcat, but rather to a >> > public having to deal specifically with tomcat Java code and tomcat >> > configuration files. This public is going to need messages which >> > they can later connect to that code and/or to the configuration >> > files language and/or to the available documentation. And let's >> > face it : in terms of anything computer-related, >> > non-native-English-speakers (such as myself) lost out a long time >> > ago, and have had, and will have, to learn a modicum of English >> > technical computer language anyway, just to understand the basics >> > of their field of expertise. That is not what most of us would >> > culturally prefer, but it is a fact of life. >> >> I would argue that is an exercise in democratization: Tomcat can be a >> project that is actually accommodating to its users (administrators, >> programmers, etc.) instead of being hostile by using log messages that >> are unreadable. >> >> Note that Java itself has error messages translated into non-English >> languages for this very reason. Is there a huge between "io error" and >> "erreur d'entrée / sortie"? Not really. But I know that if I saw an >> error message in French, it would be a lot more difficult for me to do >> my job. >> >> > Now I really apologise to anyone who has already spent a great >> > amount of donated time to achieve the current levels of >> > translations. >> > >> > But, not to mince words, isn't this all in all and ultimately, a >> > big waste of time ? >> > >> > And shouldn't we be looking at more efficient ways of achieving the >> > real main goal of all this, which is basically to make sure that, >> > when something bad happens as a result of using tomcat, the people >> > in charge would get precise and understandable information about >> > what happened, and about where they can find more information >> > helping them correcting the issue ? >> > >> > I'll use an example : Suppose I'm one of these >> > non-native-English-speakers sysadmins or developers, and I find a >> > message in the tomcat logs, such as : "Could not find the main >> > class: org.apache.catalina.startup.Bootstrap. Program will exit." >> > and I do not really understand what it says. >> > >> > I would go to https://translate.google.com, paste in the above >> > message, and instantly get : French : "Impossible de trouver la >> > classe principale: org.apache.catalina.startup.Bootstrap. Le >> > programme va sortir." >> > >> > German : "Die Hauptklasse konnte nicht gefunden werden: >> > org.apache.catalina.startup.Bootstrap. Das Programm wird >> > geschlossen." >> > >> > Spanish : "No se pudo encontrar la clase principal: >> > org.apache.catalina.startup.Bootstrap. Programa saldrá." >> > >> > Polish : "Nie można znaleźć głównej klasy: >> > org.apache.catalina.startup.Bootstrap. Program zostanie >> > zamknięty." (Note : I don't know anything about the Polish >> > language, just adding it for the fun; but also to ilustrate that >> > the same website provides dozens of target languages.) >> > >> > The point is : are any of the above worse/better than what we get >> > by this current quite time-consuming one-off (but to remain >> > relevant, regularly repeated and maintained) translation effort, in >> > the perpective of the potential users of these messages ? >> > >> > And if nowadays Google can do that, not only for tomcat but for a >> > host of fields and languages, should it not be possible to >> > integrate some of this logic directly into tomcat, which after all >> > needs a very limited subset of vocabulary to achieve something >> > equivalent ? Or, considering the above examples, should we even >> > bother ? >> > >> > Voilà. I do not particularly like to shock for the sake of it. But >> > I feel that sometimes, someone has to shake the tree to bring back >> > a sense of reality (or, in this case, gravity ?) in this geek >> > world. >> >> The worst part of the above is that, in order to find the code that >> contains the error (if you were able to competently read the code), >> you have to do this: >> >> $ find . -type f -print0 | xargs -0 grep 'Could not find the main >> class: org.apache.catalina.startup.Bootstrap. Program will exit.' >> >> Then, finding that no files are found, I have to search
Re: Translations update
Ola buenas noches nomás para darle mi número de cuenta ok gracias El mié., 28 de nov. de 2018 10:58 AM, Christopher Schultz < ch...@christopherschultz.net> escribió: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > André, > > On 11/27/18 06:01, André Warnier (tomcat) wrote: > > I must say that, although I tried to participate as much I could, I > > have some reservations about this whole translation project. And > > that is because most of the original messages which I have seen, > > are really "technical" and not at all oriented to a general public > > which may be using applications built on tomcat, but rather to a > > public having to deal specifically with tomcat Java code and tomcat > > configuration files. This public is going to need messages which > > they can later connect to that code and/or to the configuration > > files language and/or to the available documentation. And let's > > face it : in terms of anything computer-related, > > non-native-English-speakers (such as myself) lost out a long time > > ago, and have had, and will have, to learn a modicum of English > > technical computer language anyway, just to understand the basics > > of their field of expertise. That is not what most of us would > > culturally prefer, but it is a fact of life. > > I would argue that is an exercise in democratization: Tomcat can be a > project that is actually accommodating to its users (administrators, > programmers, etc.) instead of being hostile by using log messages that > are unreadable. > > Note that Java itself has error messages translated into non-English > languages for this very reason. Is there a huge between "io error" and > "erreur d'entrée / sortie"? Not really. But I know that if I saw an > error message in French, it would be a lot more difficult for me to do > my job. > > > Now I really apologise to anyone who has already spent a great > > amount of donated time to achieve the current levels of > > translations. > > > > But, not to mince words, isn't this all in all and ultimately, a > > big waste of time ? > > > > And shouldn't we be looking at more efficient ways of achieving the > > real main goal of all this, which is basically to make sure that, > > when something bad happens as a result of using tomcat, the people > > in charge would get precise and understandable information about > > what happened, and about where they can find more information > > helping them correcting the issue ? > > > > I'll use an example : Suppose I'm one of these > > non-native-English-speakers sysadmins or developers, and I find a > > message in the tomcat logs, such as : "Could not find the main > > class: org.apache.catalina.startup.Bootstrap. Program will exit." > > and I do not really understand what it says. > > > > I would go to https://translate.google.com, paste in the above > > message, and instantly get : French : "Impossible de trouver la > > classe principale: org.apache.catalina.startup.Bootstrap. Le > > programme va sortir." > > > > German : "Die Hauptklasse konnte nicht gefunden werden: > > org.apache.catalina.startup.Bootstrap. Das Programm wird > > geschlossen." > > > > Spanish : "No se pudo encontrar la clase principal: > > org.apache.catalina.startup.Bootstrap. Programa saldrá." > > > > Polish : "Nie można znaleźć głównej klasy: > > org.apache.catalina.startup.Bootstrap. Program zostanie > > zamknięty." (Note : I don't know anything about the Polish > > language, just adding it for the fun; but also to ilustrate that > > the same website provides dozens of target languages.) > > > > The point is : are any of the above worse/better than what we get > > by this current quite time-consuming one-off (but to remain > > relevant, regularly repeated and maintained) translation effort, in > > the perpective of the potential users of these messages ? > > > > And if nowadays Google can do that, not only for tomcat but for a > > host of fields and languages, should it not be possible to > > integrate some of this logic directly into tomcat, which after all > > needs a very limited subset of vocabulary to achieve something > > equivalent ? Or, considering the above examples, should we even > > bother ? > > > > Voilà. I do not particularly like to shock for the sake of it. But > > I feel that sometimes, someone has to shake the tree to bring back > > a sense of reality (or, in this case, gravity ?) in this geek > > world. > > The worst part of the above is that, in order to find the code that > contains the error (if you were able to competently read the code), > you have to do this: > > $ find . -type f -print0 | xargs -0 grep 'Could not find the main > class: org.apache.catalina.startup.Bootstrap. Program will exit.' > > Then, finding that no files are found, I have to search for a part of it > : > > $ find . -type f -print0 | xargs -0 grep 'Could not find the main class: > ' > > Again, no results. > > Maybe a bad example. How about this one? > > $ find . -type f -print0 | xargs -0 grep
Re: Translations update
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
André,
On 11/27/18 06:01, André Warnier (tomcat) wrote:
> I must say that, although I tried to participate as much I could, I
> have some reservations about this whole translation project. And
> that is because most of the original messages which I have seen,
> are really "technical" and not at all oriented to a general public
> which may be using applications built on tomcat, but rather to a
> public having to deal specifically with tomcat Java code and tomcat
> configuration files. This public is going to need messages which
> they can later connect to that code and/or to the configuration
> files language and/or to the available documentation. And let's
> face it : in terms of anything computer-related,
> non-native-English-speakers (such as myself) lost out a long time
> ago, and have had, and will have, to learn a modicum of English
> technical computer language anyway, just to understand the basics
> of their field of expertise. That is not what most of us would
> culturally prefer, but it is a fact of life.
I would argue that is an exercise in democratization: Tomcat can be a
project that is actually accommodating to its users (administrators,
programmers, etc.) instead of being hostile by using log messages that
are unreadable.
Note that Java itself has error messages translated into non-English
languages for this very reason. Is there a huge between "io error" and
"erreur d'entrée / sortie"? Not really. But I know that if I saw an
error message in French, it would be a lot more difficult for me to do
my job.
> Now I really apologise to anyone who has already spent a great
> amount of donated time to achieve the current levels of
> translations.
>
> But, not to mince words, isn't this all in all and ultimately, a
> big waste of time ?
>
> And shouldn't we be looking at more efficient ways of achieving the
> real main goal of all this, which is basically to make sure that,
> when something bad happens as a result of using tomcat, the people
> in charge would get precise and understandable information about
> what happened, and about where they can find more information
> helping them correcting the issue ?
>
> I'll use an example : Suppose I'm one of these
> non-native-English-speakers sysadmins or developers, and I find a
> message in the tomcat logs, such as : "Could not find the main
> class: org.apache.catalina.startup.Bootstrap. Program will exit."
> and I do not really understand what it says.
>
> I would go to https://translate.google.com, paste in the above
> message, and instantly get : French : "Impossible de trouver la
> classe principale: org.apache.catalina.startup.Bootstrap. Le
> programme va sortir."
>
> German : "Die Hauptklasse konnte nicht gefunden werden:
> org.apache.catalina.startup.Bootstrap. Das Programm wird
> geschlossen."
>
> Spanish : "No se pudo encontrar la clase principal:
> org.apache.catalina.startup.Bootstrap. Programa saldrá."
>
> Polish : "Nie można znaleźć głównej klasy:
> org.apache.catalina.startup.Bootstrap. Program zostanie
> zamknięty." (Note : I don't know anything about the Polish
> language, just adding it for the fun; but also to ilustrate that
> the same website provides dozens of target languages.)
>
> The point is : are any of the above worse/better than what we get
> by this current quite time-consuming one-off (but to remain
> relevant, regularly repeated and maintained) translation effort, in
> the perpective of the potential users of these messages ?
>
> And if nowadays Google can do that, not only for tomcat but for a
> host of fields and languages, should it not be possible to
> integrate some of this logic directly into tomcat, which after all
> needs a very limited subset of vocabulary to achieve something
> equivalent ? Or, considering the above examples, should we even
> bother ?
>
> Voilà. I do not particularly like to shock for the sake of it. But
> I feel that sometimes, someone has to shake the tree to bring back
> a sense of reality (or, in this case, gravity ?) in this geek
> world.
The worst part of the above is that, in order to find the code that
contains the error (if you were able to competently read the code),
you have to do this:
$ find . -type f -print0 | xargs -0 grep 'Could not find the main
class: org.apache.catalina.startup.Bootstrap. Program will exit.'
Then, finding that no files are found, I have to search for a part of it
:
$ find . -type f -print0 | xargs -0 grep 'Could not find the main class:
'
Again, no results.
Maybe a bad example. How about this one?
$ find . -type f -print0 | xargs -0 grep 'Unexpected end of stream
while reading opening client preface byte sequence.'
./java/org/apache/coyote/http2/LocalStrings.properties:connectionPreface
Parser.eos=Unexpected
end of stream while reading opening client preface byte sequence. Only
[{0}] bytes read.
Hmm... okay, it's in a properties file. Maybe that gets used in a
source file? Let's
Re: [slightly OT] Re: Tomcat 9 does not work with Java 11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Andi, On 11/27/18 05:08, Andi Meister wrote: > What I did now: - removed Tomcat services by service.bat - > uninstalled all Tomcats (7 and 9) - uninstalled all Java (was only > Version 11) - server reboot - Installed Java 11 (File: > jdk-11.0.1_windows-x64_bin.exe) - reboot - Installed Tomcat 9 > (File: apache-tomcat-9.0.13.exe) 32-bit or 64-bit? If you try to launch a 64-bit JVM from a 32-bit service-running, I'm fairly sure you'll get this type of error message. The installer should be detecting all of that, but at this point you are grasping at straws, anyway. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlv+3HwACgkQHPApP6U8 pFjk8Q//U9dks12jh8bg/zQfCfLnyeEpCzegFAB6LywTXiwjJ2/6C1ATewVtId/7 H+rWXUG95n0KSXxCDqRmZzBCjUQP7i90d+zTKyWa0qkwDL+VryKHyABkSRSOk6eR dkg+WeR6queq/tvnE7XGs1lsjoWqmRT4Ybgnb4WHTsJ5FgIp40GVdTayoWOE/dzv SV5NaO77guGt6XUfQdqsJmm+Cb0bhMcSQOuyl3cKceaAUFHF6bhxrVTWpbVCDB0Q h+AkrTAc9SAWWfNHmpRzUg72wAbwza6U2KaZzDhOZjhZFel76Vb7fCkrSNritJvK oiWBDJGXFKdO1w8Wtds/4FHEqBqkU+rsNm/qkEdMZSDj+9eHasmDg/HHv68L64Tf PaSDV7POO4gdiggsbCtsqPH4KLpk8zRHli0uThGDf/73zYwGWqZwPnPc9p0vZh01 MeeIkZteyLFjh/PhU++vxUEJevbjCwGTI4hZn1Bs6gASwF/v5pY3Yjxx2m9Xd79G B3VGQ/Y3QL5WUZdEomnP0BLKn2q+sZ0hmHWjRCC0rr+xjiHtuMO+IRRRdhL4jOqv 5ZgeUZL8ShlGnhi5CQiMuTsCsqY122Yt7mQBOnE9yredlfre68z/tq1nFwIoyd+z 2VFk1coXosXjv8BHU/3rd+Uz0RnRSGK9Mfe67Wnz7Qu/iZnD1mU= =gTWT -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
mod_proxy_http and ports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I'm looking at moving from mod_jk to mod_proxy_http and I'm finding that a few things don't work "out of the box" like they did with mod_jk. Specifically, I'm talking about auto-setting values such as the server name and port that the application sees as the client's server name and port. With no specific configuration, this is what the server reports for various request values (in a JSP, not an access log file, so this is what the application can see): serverName localhost serverPort 8217 The above are accurate: the server is indeed listening on port 8217 and the reverse-proxy is on the same machine as Tomcat. I get these HTTP request headers added by the reverse-proxy: x-forwarded-for ::1 x-forwarded-hostlocalhost x-forwarded-server Christophers-MacBook-Pro-2.local I am indeed requesting http://localhost/appname/whatever, so these values are correct. When enabling the RemoteIpValve in my like this: Things change a bit. A few HTTP headers are removed from the application's view, probably because they have been consumed by the RemoteIpValve: x-forwarded-hostlocalhost x-forwarded-server Christophers-MacBook-Pro-2.local x-forwarded-for [missing/removed] But I still see the same values from the request: serverName localhost serverPort 8217 The first makes sense... localhost is still the name of the server, but the port number is wrong. I would expect that to be 80. But I can see that mod_proxy_http is not providing a port number to Tomcat. I can explicitly set the port number to e.g. 80 in the connector: ...and then I get the expected values. On the other hand, it looks like everything actually *works* without fixing-up the port issue. Is that because the "host" contains everything necessary to re-build URLs for redirects, etc.? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlv+zkYACgkQHPApP6U8 pFgZ6w//ejGz/ZVJJoVrSNbtHcjP/8DYjDRM4iHEaoU4p3i34IzaSfeK1kacvOCl mdE5RIJo+9y0zOmws33wKZCJelqi2gmhQZFnJeDp2G6BVAnO/ahtIe9cxl31sp3Y Dz2Hd/EIr/piWvBDsJ2MjZiw0CywQo/XgvjMgmHvUr9o8iKbCWj24NvPSPkNj+iB a13t1fZMaI/y+2R/EwqqQsjY4+kkJL9JKTNUPEmTNa+KyCurtRNgG+/cmSn/hWmv pmig7PWjoA3kbdMHDlPifJ0zJiE8KSo+wwLJDchiGC7lQPzVAUkh9yYG6rZCqGI7 46S+I0CydcEo9qqy+7tLyE1XTgM0YiE5FqhYHw9mlkI9MPxqzxi8wPZuKcjzoy5L Luaq1XgHdsQqzJqlUdREoBBDfXtpELEczb0sqTK+su6YqUl05qUnTo6rHDPgFvsn zeVP9ypGH5HE+6oRRDAGdw+j4Wv7m8NjpbxgcJorpMBTHUdkjezMEjpnzSNeZem+ 7cqqQIaPQEOf0QLlrtexHyENkJgoYg3XZ8I6Me7qUDvqbsrmGHY4N1DrVd1EkIrB iYKb66BkPRoGdDJ/TjhQe6RtqfH0uJ7rtjvDQljWlYTHp71CLbR6CYP4b4KshCcj 1siCqgtmASfs9xUqxP3oj6EgODYmdDkoPS9ep6iuxqBi+nrLVkQ= =fQTE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Translations update
On 2018-11-28 11:04, gustavo.avitab...@unina.it wrote: Quoting Christopher Schultz : André, On 11/26/18 08:35, André Warnier (tomcat) wrote: On 26.11.2018 13:29, Rémy Maucherat wrote: On Sat, Nov 24, 2018 at 9:48 AM Ludovic Pénet wrote: Le vendredi 23 novembre 2018 à 23:51 +0100, Rémy Maucherat a écrit : On Wed, Nov 21, 2018 at 10:58 AM Mark Thomas wrote: - French has increased from 18% to 64% coverage Done (well, close enough, a few tribes/ha remain) ! A single translation remains to be performed. Jump to https://poeditor.com/join/project/NUTIjDWzrl and be the one to complete the French translation. ;-) Ok, you could have finished it, I was busy. Now we can try to harmonize terms, fixes are then easy to do with the search feature Common ones we have right now: - "socket" (usually untranslated or cleverly omitted): ? - "endpoint" (for websockets, and for the Tomcat connectors, so possibly two different terms): "point d'entrée" ? That sounds like exactly the opposite of "endpoint" to me. Although I must say that even in English, the vocabulary used in some reference documents (in particular everything to do with XML-based protocols, such as SOAP, SAML, OASIS and the like) is sometimes mysterious and counter-intuitive. What about "cible" here ? Or more literally, "point final" ? I disagree. An "endpoint" is a thing to which clients connect... an "entry point", as Rémy suggests. For "socket", "soquet" (like the piece in which you insert a plug, or a lightbulb) sounds ok to me. This sounds okay to me, thought I don't know French at all. :) - "thread" (often it is untranslated elsewhere): "fil d'exécution" ? - "membership" (that's the clustering object): "gestionnaire de membres" ? "Membership" refers to "le fait d'être membre", no ? "adhésion" ? (like "cluster members" -> "adhérents au cluster" (with the appropriate French pronounciation for "cleustère") :-) What would you call a list of people who belong to a certain fancy club or society? That's the word that should be used, here. - "dispatch"/"dispatcher" (for the Servlet request dispatcher): ? dépêcher / dépêcheur ? And I just saw it is really "connexion" and not "connection". Oooops, I thought both were ok. I guess it's the same kind of mistake with English-UK vs English-US, where I usually hate the UK style (except in HarryP and Discworld, it's part of the charm I suppose). Maybe a note : the target audience of most of these messages is not the members of the Académie or the jury of the Prix Goncourt. Its is programmers, sysadmins and qualified tomcat/webservers users. The translations should be helpful to them, to get a first idea of the issue and be able to search later in the on-line documentation. Which happens to be only available/up-to-date/searchable in English, no ? So I believe that a translation such as "La requête PTHT recue sur le soquet du connecteur de toile a été dépêchée au conducteur du groupe d'adhérents" may be stylistically correct, but ultimately quite counter-productive. (Sorry for the missing c cédille, can't type it here) (PTHT = Protocol de Transport Hyper-Texte) HTTP should always be spelled HTTP and never PTHT, just like UTC is always spelled UTC, even in English (where the acronym makes no sense to Englist speakers). I think maybe you were kidding, but ... just in case :) - -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org I am Italian, not French, but the issues discussed here are relevant for Italian too. I suggest, as a general criterion, that terms that should be known to a typical reader (like socket, thread, ...) be left untranslated; otherwise, the reader will face the additional problem of identifying what the translated term really means. Gustavo I'm not Italian neither French but Spanish, and I agree with you guys. I'm trying to follow that philosophy on my translations Certainly there are some words that cannot/should not be translated -- Salu2, Ulinx "En un problema con n ecuaciones siempre habrá al menos n+1 incógnitas" Linux user 366775 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Translations update
Quoting Christopher Schultz : André, On 11/26/18 08:35, André Warnier (tomcat) wrote: On 26.11.2018 13:29, Rémy Maucherat wrote: On Sat, Nov 24, 2018 at 9:48 AM Ludovic Pénet wrote: Le vendredi 23 novembre 2018 à 23:51 +0100, Rémy Maucherat a écrit : On Wed, Nov 21, 2018 at 10:58 AM Mark Thomas wrote: - French has increased from 18% to 64% coverage Done (well, close enough, a few tribes/ha remain) ! A single translation remains to be performed. Jump to https://poeditor.com/join/project/NUTIjDWzrl and be the one to complete the French translation. ;-) Ok, you could have finished it, I was busy. Now we can try to harmonize terms, fixes are then easy to do with the search feature Common ones we have right now: - "socket" (usually untranslated or cleverly omitted): ? - "endpoint" (for websockets, and for the Tomcat connectors, so possibly two different terms): "point d'entrée" ? That sounds like exactly the opposite of "endpoint" to me. Although I must say that even in English, the vocabulary used in some reference documents (in particular everything to do with XML-based protocols, such as SOAP, SAML, OASIS and the like) is sometimes mysterious and counter-intuitive. What about "cible" here ? Or more literally, "point final" ? I disagree. An "endpoint" is a thing to which clients connect... an "entry point", as Rémy suggests. For "socket", "soquet" (like the piece in which you insert a plug, or a lightbulb) sounds ok to me. This sounds okay to me, thought I don't know French at all. :) - "thread" (often it is untranslated elsewhere): "fil d'exécution" ? - "membership" (that's the clustering object): "gestionnaire de membres" ? "Membership" refers to "le fait d'être membre", no ? "adhésion" ? (like "cluster members" -> "adhérents au cluster" (with the appropriate French pronounciation for "cleustère") :-) What would you call a list of people who belong to a certain fancy club or society? That's the word that should be used, here. - "dispatch"/"dispatcher" (for the Servlet request dispatcher): ? dépêcher / dépêcheur ? And I just saw it is really "connexion" and not "connection". Oooops, I thought both were ok. I guess it's the same kind of mistake with English-UK vs English-US, where I usually hate the UK style (except in HarryP and Discworld, it's part of the charm I suppose). Maybe a note : the target audience of most of these messages is not the members of the Académie or the jury of the Prix Goncourt. Its is programmers, sysadmins and qualified tomcat/webservers users. The translations should be helpful to them, to get a first idea of the issue and be able to search later in the on-line documentation. Which happens to be only available/up-to-date/searchable in English, no ? So I believe that a translation such as "La requête PTHT recue sur le soquet du connecteur de toile a été dépêchée au conducteur du groupe d'adhérents" may be stylistically correct, but ultimately quite counter-productive. (Sorry for the missing c cédille, can't type it here) (PTHT = Protocol de Transport Hyper-Texte) HTTP should always be spelled HTTP and never PTHT, just like UTC is always spelled UTC, even in English (where the acronym makes no sense to Englist speakers). I think maybe you were kidding, but ... just in case :) - -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org I am Italian, not French, but the issues discussed here are relevant for Italian too. I suggest, as a general criterion, that terms that should be known to a typical reader (like socket, thread, ...) be left untranslated; otherwise, the reader will face the additional problem of identifying what the translated term really means. Gustavo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: help installing mod_jk on Centos 7 on a Google Cloud server
hi.
1) I have removed the previous correspondence from this email, because by now it has
become pretty much unreadable anyway.
Also, there are 2 links at the bottom of your last email (to "avg"-something). I don't
know if these are supposed to provide some additional information, but they both lead to a
page asking me to install something on my laptop, which of course I am not going to do.
2) according to the paths which you show below, it does not look like there is an overlap
between the httpd DocumentRoot and the tomcat webapps directory.
(Of course that does not show if there are any symlinks anywhere which may provide such a
connection on the sly. But let's suppose there aren't, and let's for now forget about that
red warning in the documentation.)
3) I do not really remember what the stage of your problem is right now. Can you summarise
it again ?
(And remind us of the versions of Java and tomcat please, it will save us a search through
the archive.)
What I suppose is that you now have this configuration, on one host for httpd
and tomcat :
browser <- HTTP/S -> httpd + mod_jk <- AJP -> tomcat AJP Connector
|
webapps
|
your webapp
|- files (HTML, JSP)
|- WEB-INF
|- private files
(Note in the above, that the protocol between mod_jk and tomcat is AJP, not HTTP/S. In
summary, it is a binary and somewhat optimised version of HTTP, which only mod_jk and the
AJP Connector in tomcat understand. But that should be transparent as far as tomcat
webapps are concerned).
You have a "workers.properties" file somewhere which tells the mod_jk module "where" the
tomcat instance is ("name", host/IP, port), and the AJP Connector in tomcat matches that
IP and port.
You also have a mod_jk setup (in the Apache config) that tells httpd which URLs should be
forwarded to which tomcat instance. These are the "JkMount" directives.
There are also logfiles, for both httpd and tomcat, which are generally helpful to find
out what happens.
I also seem to remember that initially, you had a problem getting httpd to load the mod_jk
module, but that now this is resolved, and the command "apache2ctl -M" shows the list of
loaded modules, including mod_jk.
So wat is the remaining issue ?
Note also :
In the information below, there is mention of a
> TOMCATS_BASE="/var/lib/tomcats/"
variable and directory. This is not something that I know. It may be new in recent
versions of tomcat, or it may be something which the CentOS package managers do.
(I also do not find it in the "RUNNING.txt" file of the tomcat 9 distribution, so I guess
that it is CentOS-specific.)
There may be more things like that, which may complicate a bit our efforts to help you,
because we do not necessarily have a CentOS system like yours at hand.
On 27.11.2018 20:18, Lou Wallace wrote:
Hi André,
Here is some info on the setup, let me know what it tells you.
tomcat
etc/tomcat
drwxrwxr-x. 3 root tomcat 23 Nov 18 17:48 Catalina
-rw-r--r--. 1 root tomcat 13443 Oct 16 09:16 catalina.policy
-rw-r--r--. 1 root tomcat 6496 Oct 16 09:16 catalina.properties
drwxr-xr-x. 2 root tomcat 20 Nov 18 17:48 conf.d
-rw-r--r--. 1 root tomcat 1394 Oct 16 09:16 context.xml
-rw-r--r--. 1 root tomcat547 Oct 16 09:16 log4j.properties
-rw-r--r--. 1 root tomcat 3288 Oct 16 09:16 logging.properties
-rw-r--r--. 1 root tomcat 6613 Oct 16 09:16 server.xml
-rw-r--r--. 1 root tomcat 1651 Oct 16 09:16 tomcat.conf
-rw-r-. 1 root tomcat 2418 Oct 16 09:16 tomcat-users.xml
-rw-r--r--. 1 root tomcat 167655 Oct 16 09:16 web.xml
DocumentRoot (from httpd.conf)
var/www/html
ServerRoot (from httpd.conf)
/etc/httpd
webapps directory is at
/var/lib/tomcat
tomcat.conf
# System-wide configuration file for tomcat services
# This will be loaded by systemd as an environment file,
# so please keep the syntax. For shell expansion support
# place your custom files as /etc/tomcat/conf.d/*.conf
#
# There are 2 "classes" of startup behavior in this package.
# The old one, the default service named tomcat.service.
# The new named instances are called tomcat@instance.service.
#
# Use this file to change default values for all services.
# Change the service specific ones to affect only one service.
# For tomcat.service it's /etc/sysconfig/tomcat, for
# tomcat@instance it's /etc/sysconfig/tomcat@instance.
# This variable is used to figure out if config is loaded or not.
TOMCAT_CFG_LOADED="1"
# In new-style instances, if CATALINA_BASE isn't specified, it will
# be constructed by joining TOMCATS_BASE and NAME.
TOMCATS_BASE="/var/lib/tomcats/"
# Where your java installation
