Désolé, moi y'en a pas être d'accord. Il ne faut pas nécessairement un serveur d'application pour faire du JSP/Servlet mais uniquement un moteur de servlet (comme Tomcat par exemple). Un serveur d'application tel que Weblogic, Borland AppServer ou Websphere ajoute au JSP/Serlvet les EJB et autres J2EEseuries.
Concernant l'article lui même :
- Comme cela a été dis, le debuggage des JSP est une catastrophe (Internal server error avec un numéro de ligne qui ne correspond pas à qq chose dans la page JSP) ;
- Le principe de fonctionnement des JSP est un millefeuilles : les jsp sont traduits en servlet (une classe java qui enverra sur "stdout" ce qui doit être envoyé au navigateur), le code java de cette servlet est alors compilé en bytecode java qui va être chargé par le moteur de servlet et exécuté.
- « ce qui fait la force de JSP, ce n'est pas JSP lui même, mais c'est JAVA », j'ajouterais que c'est aussi sa faiblesse on notera en particulier la difficulté pour s'interfacer avec des bibliothèques "natives" (c'est possible mais il faut un compilateur C pour faire le stub) ; la lourdeur du JRE (trois ou quatre objets un instancier pour lire un fichier ligne à ligne) et ses manques (impossible de locker un fichier en pure java) ;
- concernant l'interfaçage, PHP est nettement plus souple puisqu'écrit en C on notera que PHP s'interface avec COM sous Windows ou même Java ;
- dans la version "out of process" de JSP/Servlet on notera qu'un plantage du moteur de Servlets (core ou Docteur Watson) bloque tout le site alors qu'un plantage identique en PHP ne bloquera que la requête en cours.
Mis à part ces "oublis" l'article est intéressant.
[^] # Re: 8^D >>> moins lourdingue <<< 8^D
Posté par gabuzo . En réponse à la dépêche Comparatif jsp/php. Évalué à 1.
Concernant l'article lui même :
- Comme cela a été dis, le debuggage des JSP est une catastrophe (Internal server error avec un numéro de ligne qui ne correspond pas à qq chose dans la page JSP) ;
- Le principe de fonctionnement des JSP est un millefeuilles : les jsp sont traduits en servlet (une classe java qui enverra sur "stdout" ce qui doit être envoyé au navigateur), le code java de cette servlet est alors compilé en bytecode java qui va être chargé par le moteur de servlet et exécuté.
- « ce qui fait la force de JSP, ce n'est pas JSP lui même, mais c'est JAVA », j'ajouterais que c'est aussi sa faiblesse on notera en particulier la difficulté pour s'interfacer avec des bibliothèques "natives" (c'est possible mais il faut un compilateur C pour faire le stub) ; la lourdeur du JRE (trois ou quatre objets un instancier pour lire un fichier ligne à ligne) et ses manques (impossible de locker un fichier en pure java) ;
- concernant l'interfaçage, PHP est nettement plus souple puisqu'écrit en C on notera que PHP s'interface avec COM sous Windows ou même Java ;
- dans la version "out of process" de JSP/Servlet on notera qu'un plantage du moteur de Servlets (core ou Docteur Watson) bloque tout le site alors qu'un plantage identique en PHP ne bloquera que la requête en cours.
Mis à part ces "oublis" l'article est intéressant.
De toute façon mod_perl rewlz ;-).