[Java- Servlet] Bonne config (gratuite) pour faire tourner une servlet

Bonne config (gratuite) pour faire tourner une servlet [Java- Servlet] - Java - Programmation

Marsh Posté le 11-04-2002 à 08:43:25    

Voila, ma servlet à déja bien avancé. Pour mes tests, j'utilise les serveur web Tomcat. Ms je crois que c pas le mieux, niveau performances, j'en sais rien, ms j'veux dire que c pas le mieux pour moi, parce qu'il fait en même temps serveur web, et moteur de servlet. Du coup je distingue pas les 2.
D'ou ma question: quels sont les moteurs de servlets gratuits, qui ont fait leur preuves ?
Et plus précis: comment faire tourner des servlets de manière efficace (et tjs gratuitement :D) avec IIS, ou PWS (serveurs web de microsoft, ss NT et ss Win98)?

Reply

Marsh Posté le 11-04-2002 à 08:43:25   

Reply

Marsh Posté le 11-04-2002 à 08:57:05    

Bah, a mon sens, le meilleur rapport qualité/prix/performances, ça va être Tomcat comme moteur de servlets avec Apache comme serveur web.

Reply

Marsh Posté le 11-04-2002 à 09:00:31    

gfive a écrit a écrit :

Bah, a mon sens, le meilleur rapport qualité/prix/performances, ça va être Tomcat comme moteur de servlets avec Apache comme serveur web.  




 
Et c possible de coupler Tomcat (comme moteur de servlet) à IIS, PWS ou n'importe quel autre serveur web ?

Reply

Marsh Posté le 11-04-2002 à 09:04:51    

Ah, ça, je sais pas, j'ai jamais utilisé aucun des trucs dont tu parles...Mais en allant voir sur le site de tomcat, tu devrais trouver ça dans la doc en ligne, non??
 
C'est sur http://jakarta.apache.org/tomcat/index.html

Reply

Marsh Posté le 11-04-2002 à 09:06:54    

gfive a écrit a écrit :

Ah, ça, je sais pas, j'ai jamais utilisé aucun des trucs dont tu parles...Mais en allant voir sur le site de tomcat, tu devrais trouver ça dans la doc en ligne, non??
 
C'est sur http://jakarta.apache.org/tomcat/index.html  




 
Ouais, j'vais voir ça, merci.
 
Et, une question qui n'a rien à voir au passage: c quoi en HTTP, la différence entre les méthodes GET, POST, et PUT ?

Reply

Marsh Posté le 11-04-2002 à 09:24:53    

euuuh...je sais pas!! :D

Reply

Marsh Posté le 11-04-2002 à 09:30:21    

gfive a écrit a écrit :

euuuh...je sais pas!! :D  




 
ha la la, c Darklord qui va être content de répondre quand y va voir ça ! :D :D  :D

Reply

Marsh Posté le 11-04-2002 à 10:28:22    

El_Gringo a écrit a écrit :

 
 
Et c possible de coupler Tomcat (comme moteur de servlet) à IIS, PWS ou n'importe quel autre serveur web ?  




oui pour IIS et apache: http://jakarta.apache.org/tomcat/t [...] g/ajp.html
 
les autres je sais pas ...

Reply

Marsh Posté le 11-04-2002 à 10:37:35    

El_Gringo a écrit a écrit :

 
Et, une question qui n'a rien à voir au passage: c quoi en HTTP, la différence entre les méthodes GET, POST, et PUT ?  




PUT, je sais pas. si je ne me trompe pas, c'est jamais utilisé par les navigateurs.
 
GET c'est la demande d'une page. POST c'est l'envoi d'information.
 
En pratique, les deux renvoient une page HTML, donc on ne voit pas la différence. La seule différence "visible" c'est que dans le cas d'un formulaire si la methode est reglée en GET, les paramètres (champs input) seront transférés dans l'URL (GET /trux.xsp?param=value HTTP/1.0). Si le formulaire à une méthode POST, les paramètres seront passés directement dans le corp de la requête HTTP :  

Citation :

POST /truc.xsp HTTP/1.0
...
Content-Length: 0
...
 
 
param=valeur


 
d'un point de vue utilisateur, les paramètres seront visibles dans le cas du Get, et invisible dans le cas du Post; Et lorsqu'il demande un refresh, dans le cas d'un post, le navigateur demande l'autorisation de renvoyer les données dans la reqûete, dans le cas d'un Get c'ets inutile : les donénes sont dans l'URL => automatiquement réenvoyées

Reply

Marsh Posté le 11-04-2002 à 11:06:36    

benou a écrit a écrit :

 
PUT, je sais pas. si je ne me trompe pas, c'est jamais utilisé par les navigateurs.
 
GET c'est la demande d'une page. POST c'est l'envoi d'information.
 
En pratique, les deux renvoient une page HTML, donc on ne voit pas la différence. La seule différence "visible" c'est que dans le cas d'un formulaire si la methode est reglée en GET, les paramètres (champs input) seront transférés dans l'URL (GET /trux.xsp?param=value HTTP/1.0). Si le formulaire à une méthode POST, les paramètres seront passés directement dans le corp de la requête HTTP :  

Citation :

POST /truc.xsp HTTP/1.0
...
Content-Length: 0
...
 
 
param=valeur


 
d'un point de vue utilisateur, les paramètres seront visibles dans le cas du Get, et invisible dans le cas du Post; Et lorsqu'il demande un refresh, dans le cas d'un post, le navigateur demande l'autorisation de renvoyer les données dans la reqûete, dans le cas d'un Get c'ets inutile : les donénes sont dans l'URL => automatiquement réenvoyées  




 
en gros, en général, on peut utiliser indifféremment l'un ou l'autre. Merci.

Reply

Marsh Posté le 11-04-2002 à 11:06:36   

Reply

Marsh Posté le 11-04-2002 à 11:10:07    

benou a écrit a écrit :

 
oui pour IIS et apache: http://jakarta.apache.org/tomcat/t [...] g/ajp.html
 
les autres je sais pas ...  




 
heu, t sur qu'il faut utiliser l'ajp connector pour faire marcher Tomcat avec IIS, genre tu l'as déja fait ? ou tu m'a balancé le liens vite fait parce que tu t'es dit que c peut être ça !?

Reply

Marsh Posté le 11-04-2002 à 11:18:11    

El_Gringo a écrit a écrit :

 
 
Ouais, j'vais voir ça, merci.
 
Et, une question qui n'a rien à voir au passage: c quoi en HTTP, la différence entre les méthodes GET, POST, et PUT ?  




 
PUT est utilisé pour mettre à jour des donnés sur le serveur. C'est utilise en intranet par exemple. Le plus simple c'est d'aller voir le RFC
 

Citation :


 The PUT method requests that the enclosed entity be stored under the
   supplied Request-URI. If the Request-URI refers to an already
   existing resource, the enclosed entity SHOULD be considered as a
   modified version of the one residing on the origin server. If the
   Request-URI does not point to an existing resource, and that URI is
   capable of being defined as a new resource by the requesting user
   agent, the origin server can create the resource with that URI. If a
   new resource is created, the origin server MUST inform the user agent
   via the 201 (Created) response.


 
et
 

Citation :


The fundamental difference between the POST and PUT requests is
   reflected in the different meaning of the Request-URI. The URI in a
   POST request identifies the resource that will handle the enclosed
   entity.  That resource may be a data-accepting process, a gateway to
   some other protocol, or a separate entity that accepts annotations.
   In contrast, the URI in a PUT request identifies the entity enclosed
   with the request -- the user agent knows what URI is intended and the
   server MUST NOT attempt to apply the request to some other resource.
   If the server desires that the request be applied to a different URI,
   it MUST send a 301 (Moved Permanently) response; the user agent MAY
   then make its own decision regarding whether or not to redirect the
   request.


 
http://www.ietf.org/rfc/rfc2068.txt


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 11-04-2002 à 11:18:50    

El_Gringo a écrit a écrit :

 
 
ha la la, c Darklord qui va être content de répondre quand y va voir ça ! :D :D  :D  




 
 :non:  :(


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 11-04-2002 à 11:20:24    

El_Gringo a écrit a écrit :

 
 
en gros, en général, on peut utiliser indifféremment l'un ou l'autre. Merci.  




 
 :non:  
 
En général oui mais bon par exemple en PHP tu récupères pas les infos de la meme facon. En Servlet tu as une méthode doGet et une méthode doPost.
 
Donc c'est pas l'un ou l'autre (sauf si le service peut répondre indiférement que ce soit post ou get ...)


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 11-04-2002 à 11:20:44    

El_Gringo a écrit a écrit :

 
heu, t sur qu'il faut utiliser l'ajp connector pour faire marcher Tomcat avec IIS, genre tu l'as déja fait ? ou tu m'a balancé le liens vite fait parce que tu t'es dit que c peut être ça !?  




je l'ai déjà fait. et y a toutes les infos dont tu as besoin sur le lien que je t'ai fillé.
 
et puis quoi ? tu fais pas confiance aux développeurs de tomkat ? tu crois qu'ils mettent une doc la dessus alors que ca marche pas ?  
... faut apprendre à faire confiance ! à moi autant qu'à eux.

Reply

Marsh Posté le 11-04-2002 à 11:23:02    

benou a écrit a écrit :

 
je l'ai déjà fait. et y a toutes les infos dont tu as besoin sur le lien que je t'ai fillé.
 
et puis quoi ? tu fais pas confiance aux développeurs de tomkat ? tu crois qu'ils mettent une doc la dessus alors que ca marche pas ?  
... faut apprendre à faire confiance ! à moi autant qu'à eux.  




 
le gringo c'est un petit nerveux. Il s'était déjà excité sur je sais plus qui (l'arbre à cerise je crois bien) sans raison.
 
Keep cool gringo ;)


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 11-04-2002 à 11:24:12    

ouais mais bon, quand on pose une question, en principe c'est qu'no est près à croire les réponses ...
:(

Reply

Marsh Posté le 11-04-2002 à 11:24:20    

benou a écrit a écrit :

 
je l'ai déjà fait. et y a toutes les infos dont tu as besoin sur le lien que je t'ai fillé.
 
et puis quoi ? tu fais pas confiance aux développeurs de tomkat ? tu crois qu'ils mettent une doc la dessus alors que ca marche pas ?  
... faut apprendre à faire confiance ! à moi autant qu'à eux.  




 
ms j'fais confiance. c juste que j'avais pas vu qu'ils parlaient d'IIS en dessous. et j'trouvais la description du connector par super clair. bref, j'la comprenais pas.
J'me met à la lecture. merci pr le lien

Reply

Marsh Posté le 11-04-2002 à 11:26:01    

DarkLord a écrit a écrit :

 
 
le gringo c'est un petit nerveux. Il s'était déjà excité sur je sais plus qui (l'arbre à cerise je crois bien) sans raison.
 
Keep cool gringo ;)  




 
Meuuuuuuh non. je suis tout gentil tout doux ! :D  
Si j'me suis un peu excité ce que j'devais avoir une bonne raison.

Reply

Marsh Posté le 11-04-2002 à 11:26:20    

El_Gringo a écrit a écrit :

 
 
ms j'fais confiance. c juste que j'avais pas vu qu'ils parlaient d'IIS en dessous. et j'trouvais la description du connector par super clair. bref, j'la comprenais pas.
J'me met à la lecture. merci pr le lien  




y a toute la marche à suivre. point par point.
c'est un truc qui marchait déjà sur les anciennes versions de tomkat...

Reply

Marsh Posté le 11-04-2002 à 11:26:23    

:hello:


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 11-04-2002 à 11:28:00    

DarkLord a écrit a écrit :

 
 
 :non:  
 
En Servlet tu as une méthode doGet et une méthode doPost.
 
Donc c'est pas l'un ou l'autre (sauf si le service peut répondre indiférement que ce soit post ou get ...)  




 
g vu ça. c ça qui m'a fait me poser la question.
Ms de toute façon, c moi qui choisirai si je reçois le requetes par Get ou par Post, vu que c moi qui génère la page HTML.
Donc je peux bien choisir d'n'utiliser QUE post par exemple, ça devrais pas poser de pb, si !?

Reply

Marsh Posté le 11-04-2002 à 11:31:46    

ils ont l'air d'avoir changer le connector AJP dans les nouvelles versions de tomkat. En regardant rapidement, je n'ai pas vu de différence avec l'ancien fonctionnement ...
 
http://jakarta.apache.org/tomcat/t [...] ig/jk.html
http://jakarta.apache.org/tomcat/t [...] g/jk2.html

Reply

Marsh Posté le 11-04-2002 à 18:19:21    

Benouuuuuu, j'y arrive pas !
IIS veut pas charger la dll de redirection (isapi_redirect.dll), dans les filtres ISAPI. tu te rappel avoir fait qqch de particulier pr faire marcher ça ?
si non, tu peux m'envoyer ta version de isapi_redirect.dll (on sait jammais, si ça s'trouve, celle que g récupéré merde, même si j crois pas trop qd même !)
 
J'reviens demain, merci...

Reply

Marsh Posté le 11-04-2002 à 18:27:24    

El_Gringo a écrit a écrit :

Benouuuuuu, j'y arrive pas !
IIS veut pas charger la dll de redirection (isapi_redirect.dll), dans les filtres ISAPI. tu te rappel avoir fait qqch de particulier pr faire marcher ça ?
si non, tu peux m'envoyer ta version de isapi_redirect.dll (on sait jammais, si ça s'trouve, celle que g récupéré merde, même si j crois pas trop qd même !)
 
J'reviens demain, merci...  




 
nan, j'ai juste suivi les indicaions.
Tu as mis à jour la base de registre, tu as copié les fichiers properties au bon endroit ?  
 
je me souviens que ca a pas marché du premier coup et qu'il a fallu que je redémarre IIS et tomcat une bonne paire de fois, mais ca fonctionnait. Pour les redémarrer, passe par le gestionnaire de service plutot que par la console de IIS ... j'ai lu que dans certains cas, ca ne marchait pas bien sinon.
 
T'inquiète pas, c'est pas la dll qui chie : c'est la même dll qui est utilisée depuis tomkat 3.2 !

Reply

Marsh Posté le 12-04-2002 à 09:35:56    

benou a écrit a écrit :

 
 
nan, j'ai juste suivi les indicaions.
Tu as mis à jour la base de registre, tu as copié les fichiers properties au bon endroit ?  
 
je me souviens que ca a pas marché du premier coup et qu'il a fallu que je redémarre IIS et tomcat une bonne paire de fois, mais ca fonctionnait. Pour les redémarrer, passe par le gestionnaire de service plutot que par la console de IIS ... j'ai lu que dans certains cas, ca ne marchait pas bien sinon.
 
T'inquiète pas, c'est pas la dll qui chie : c'est la même dll qui est utilisée depuis tomkat 3.2 !  




 
Je m'en doutais bien que ça peut pas venir de la Dll, ms c justement ça qui m'inquiète. g aucune idée d'ou ça peut venir. surtout que c vraiment dès le départ que ça merde. IIS arrive pas à charger la dll de redirection en mémoire !  :fou:  
ils disent que ce truc marche avec IIS4.0 ou 5.0
moi g pas trouvé de n° de version de mon IIS, c juste l'IIS de l'option pack pour NT4, t'as un n° de version toi ?

Reply

Marsh Posté le 12-04-2002 à 14:26:55    

c'était sur du 2000, mais je suis sur que ca marche sur NT.
 
t'as bien mit les fichiers de properties où il faut et mis la base de registre à jour ? la dll s'en sert au moment où IIS la charge => si tu as le moindre problème de config, elle marchera pas !

Reply

Marsh Posté le 16-04-2002 à 09:21:31    

Yess, merci, ça y est presque... (j'vous rassure, g pas fait QUE ça pdt tt ce temps.)
En fait, on vient de passer sosu XP. Du coup g IIS 5.1, et avec, le filtre isapi (isapi_redirect.dll) se charge correctement en mémoire.
Tient, au passage, ss XP, on peut pas exécuter des .reg qu'on a crée sois même !? (g été obligé d'aller écrire moi même dans la base de registres, XP ms disait qu'on peut uniquement éxécuter des scripts .reg qui ont été exportés du base de registres, ennfin, bon...).
Mais le truc important, c'est (c surtout Benou qui doit se sentir concerné par ma question, vu que t'as déja essayé...):
Une fois que la dll est chargée, que tt est fait.
Sachant:
qu'en local, j'accède à ma servlet par cette ligne de commande:

Code :
  1. http://localhost:8080/JLdsWeb/servlet/MaServlet


et que le répertoire virtuel que g fait pointer sur la dll redirect.dll s'appel: jakarta
 
comment j'accède à ma servlet en passant par IIS !?
ce qui m'aurait parrut logique, c ça:

Code :
  1. http://127.0.0.1/jakarta/JLdsWeb/servlet/MaServlet


ms apprement, c pas ça...
comme ça s'passe là !?

Reply

Marsh Posté le 16-04-2002 à 10:00:23    

DarkLord a écrit a écrit :

 
 
le gringo c'est un petit nerveux. Il s'était déjà excité sur je sais plus qui (l'arbre à cerise je crois bien) sans raison.
 
Keep cool gringo ;)  



Ouais, c'était sur moi, alors que j'avais rien fait de mal. :cry: Bou-hou-hou... Bou-hou-hou (au fond des bois) :cry:

Reply

Marsh Posté le 16-04-2002 à 10:03:45    

Cherrytree a écrit a écrit :

Ouais, c'était sur moi, alors que j'avais rien fait de mal. :cry: Bou-hou-hou... Bou-hou-hou (au fond des bois) :cry:  




 
1h30 pour faire 28Km ce matin, alors c'est moi qui pleure et pas au fond des bois !!!
 
 :cry:


---------------
Just because you feel good does not make you right
Reply

Marsh Posté le 16-04-2002 à 10:16:29    

Cherrytree a écrit a écrit :

Ouais, c'était sur moi, alors que j'avais rien fait de mal. :cry: Bou-hou-hou... Bou-hou-hou (au fond des bois) :cry:  




 
Allons allons, mon piti, sèche tes larmes. C fini maintenant, tout va bien. :)
 
 
 
 
MAIS COMMENCES PAS A MON POLLUER MON TOPIC AVEC TES CONNERIES !

Reply

Marsh Posté le 16-04-2002 à 10:16:59    

...J'déconne hein, c pas grave ! :D

Reply

Marsh Posté le 16-04-2002 à 10:26:49    

el_gringo a écrit a écrit :

Une fois que la dll est chargée, que tt est fait.
Sachant:
qu'en local, j'accède à ma servlet par cette ligne de commande:

Code :
  1. http://localhost:8080/JLdsWeb/servlet/MaServlet


et que le répertoire virtuel que g fait pointer sur la dll redirect.dll s'appel: jakarta
 
comment j'accède à ma servlet en passant par IIS !?
ce qui m'aurait parrut logique, c ça:

Code :
  1. http://127.0.0.1/jakarta/JLdsWeb/servlet/MaServlet


ms apprement, c pas ça...
comme ça s'passe là !?  




nan, le rep virtuel de IIS n'a rien à voir. Ce qui est important c'est la règle de filtrage que tu as déclaré dans le fichier uriworkermap.properties.
en faite, la dll va analyser toutes les requêtes arrivant sur IIS, va les comparer au filtre se trouavnt dans le ficiher uriworkermap. Si ca correspond, elle redirige la requête vers tomcat et c'est lui qui fait le boulot.
 
donc si dans le fichier tu as ca :
 
/JLdsWeb/*=ajp13
 
(JLdsWeb est une webapp de tomcat)
 
il faudra que tu y accèdes en tapant ca :
 
http://localhost/JLdsWeb/servlet/MaServlet

Reply

Marsh Posté le 16-04-2002 à 10:28:52    

si je me souviens bien, je trouvais que le paratge virtuel dans IIS ne servait pas à grand chose : c'est juste qu'il y a un chemin (dans la base de registre, je crois) qui l'utilise.
 mais si on ne le fais pas et qu'on met le chemin en dur (c:\...) ca marche pas.

Reply

Marsh Posté le 16-04-2002 à 12:35:17    

benou a écrit a écrit :

 
nan, le rep virtuel de IIS n'a rien à voir. Ce qui est important c'est la règle de filtrage que tu as déclaré dans le fichier uriworkermap.properties.
en faite, la dll va analyser toutes les requêtes arrivant sur IIS, va les comparer au filtre se trouavnt dans le ficiher uriworkermap. Si ca correspond, elle redirige la requête vers tomcat et c'est lui qui fait le boulot.
 
donc si dans le fichier tu as ca :
 
/JLdsWeb/*=ajp13
 
(JLdsWeb est une webapp de tomcat)
 
il faudra que tu y accèdes en tapant ca :
 
http://localhost/JLdsWeb/servlet/MaServlet  




 
merci déja pr ça, ça risquait pas de marcher.
Ms de toute façon, y avait déja ça de défini ds le fichier, y avait déja ça:
/examples/*=ajp13
et pourtant, la page
http://localhost:8080/examples/ser [...] rldExample
qui marche (en local) quand juste tomcat est lancé, ne marche plus quand IIS est lancé (donc qd on passe pas la redirection).
ça n'marche pas non plus quand je passe par le port TCP par défaut:
http://localhost/examples/servlet/HelloWorldExample
 
y a pas une histoire de port à changer qq part ?

Reply

Marsh Posté le 16-04-2002 à 13:08:58    

DarkLord a écrit a écrit :

 
 
1h30 pour faire 28Km ce matin, alors c'est moi qui pleure et pas au fond des bois !!!
 
 :cry:


:cry:

Reply

Marsh Posté le 16-04-2002 à 13:09:22    

el_gringo a écrit a écrit :

 
 
Allons allons, mon piti, sèche tes larmes. C fini maintenant, tout va bien. :)
 
 
 
 
MAIS COMMENCES PAS A MON POLLUER MON TOPIC AVEC TES CONNERIES !  



OK :sweat:

Reply

Marsh Posté le 16-04-2002 à 14:12:44    

Cherrytree a écrit a écrit :

OK :sweat:  




 
Bouh, qu'il a l'air pleurnichard ce CherryTree

Reply

Marsh Posté le 16-04-2002 à 14:32:07    

el_gringo a écrit a écrit :

 
y a pas une histoire de port à changer qq part ?  




ben nan ...

Reply

Marsh Posté le 16-04-2002 à 15:01:50    

benou a écrit a écrit :

 
ben nan ...  




 
ben merde... g plus d'idées moi.
ça m'saoule !

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed