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 ) avec IIS, ou PWS (serveurs web de microsoft, ss NT et ss Win98)?

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 ?

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 ?

euuuh...je sais pas!!

gfive a écrit a écrit : euuuh...je sais pas!!

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

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

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 :  

 
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.

 
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 !?

 
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
 

 
et
 

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

 
   
 
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 ...)

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

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

 
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

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 !  
Si j'me suis un peu excité ce que j'devais avoir une bonne raison.

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

DarkLord a écrit a écrit :           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 !?

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

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 !

 
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 !    
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 ?

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 !

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:

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:

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

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. Bou-hou-hou... Bou-hou-hou (au fond des bois)

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

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

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

 
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 !

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

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

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.

 
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 ?

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

Cherrytree a écrit a écrit : OK

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

ben nan ...

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