Articles précédents : Développeur
J'ai trouvé qu'il serait une bonne idée d'en faire profiter la communauté. Je lui ai demandé son accord et voilà ...
![[en]](../../../images/en.png)
tomcat (2081 hits)
> Lire la dépêche (140 commentaires, moyenne: 0,4).
-------------------------
- php est un langage procédurale avec possibilité de faire de l'objet
jsp (donc java) est un langage full objet avec tous les avantages que cela
comporte en terme de rapidité de développement + de nombreux IDE
- en terme de système d'information, java possède beaucoup plus d'api que
php pour tous types de connexions à d'autres applicatifs ou protocoles :
cela permet de se greffer plus facilement à tout système d'information :
CICS, MQSeries, SNMP, tivoli, bases de données, corba, RMI, XMLRPC, FTP...
(la liste pourrait faire des pages et des pages)
--> notamment, java permet de faire tourner de réelle applications derrière
le serveur applicatif
- php peut se connecter à toutes les bases de données du marche mais les
interfaces sont propriétaires :
Pour ouvrir une connexion avec mysql : mysql_connect
Pour ouvrir une connexion avec oracle : OCILogon
Java à une interface d'abstraction de connexion au bases : JDBC (Java
Data Base Connectivity)
---> avantage par rapport à php : lorsque l'on change de base de
données, normalement, il n'y a pas besoin de changer le code de
l'application
- Toujours concernant les bases de données : php gère en natif un système de
pooling de connexion, ce système, quoi que relativement performant n'est pas
aussi performant que les systèmes de pool de connexion que l'on peut avoir en
java (plus de possibilité de configuration du pool)
- Les serveurs applicatifs java (respectant les spécifications servlet 2.2)
permettent bcp plus de choses :
meilleure gestion des sessions,
gestion de contexte
meilleure gestion du système de request
- Les serveurs applicatif java peuvent se greffer sur tous les serveurs WEB
du marche, php ne doit (a vérifier) que fonctionner avec Apache et IIS
- les serveurs applicatifs java peuvent fonctionner "in process" ou "out
process" : c'est a dire dans le même processus que le serveur web ou dans un
processus sépare, ce qui permet (dans le cas du out-process) de placer le
serveur web et le serveur applicatif sur des machines différentes : cela
permet d'avoir un système complet N-Tiers qui assure notamment du load
balancing et de la haute disponibilité a tous les niveaux.
PHP ne permet pas cette souplesse d'architecture, car il tourne
"in-process", (je crois que php possède maintenant un module lui permettant
de faire de l'out-process aussi, mais lorsqu'on l'utilise, je crois que
certaines fonctionnalités (par exemple la gestion des sessions) ne
fonctionnent pas <--- à vérifier quand même)
- au niveau du développement de l'application, java permet de manière plus
simple de respecter de design patern MVC (Model View Controler), un grand
nombre de framework de développement existent d'ailleurs pour faciliter et
respecter ce paradigme (voir les framework STRUTS et TURBINE de l'Apache
Software Foundation). Implémenter un MVC en php est pratiquement impossible,
car pas de possibilité de faire du code autrement que des des pages php,
alors que java permet de créer des servlets (Controler), des javaBeans
(Model) et des JSP (View) ce qui confère une grande souplesse de
développement (partages nette des taches et des compétences sur un projet).
- comme son nom l'indique (php = Personnal Home Page) permet le
développement plus rapide de petites applications web, mais en aucun cas de
vrai applications web scalable et fortement connectées. Des lors que le
projet commence a devenir gros, le PHP devient complexe a mettre en oeuvre.
- PHP nécessite un peu moins de ressource qu'un serveur applicatif java. Si
on résonne en revanche en terme de coût : les coûts induit (pour de gros
projet) par des développements php dépasse très rapidement le coût marginal
de la puissance machine nécessaire pour faire tourner la même chose en java.
En terme de rapidité d'exécution, les temps de réponses de JAVA sont
aujourd'hui équivalent a ceux de PHP, même si la ressource machine et
mémoire est supérieur pour JAVA.
- enfin, mais ça a son importance, JAVA est soutenu par un grand nombre de
TRES grand noms de l'informatique : SUN, IBM, ORACLE...
Si j'avais a donner une conclusion :
Pour de petits applicatifs qui n'ont vraiment aucune raison (même a long
terme) d'être connectée au système d'information de l'entreprise le choix
PHP semble s'imposer. Pour le reste, je conseille fortement JAVA...
Remarque : ce qui fait la force de JSP, ce n'est pas JSP lui même, mais
c'est JAVA, dont JSP est un moyen simple de fabriquer des pages HTML.
Car en terme pure, n'utiliser QUE du JSP, JSP tout seul n'a pas grand
avantages par rapport à PHP puisque globalement ils font la même chose :
mettre des lignes de programme dans une page HTML qui sera exécutée par le
serveur.
Bon, je m'arrete la,
Pardon pour les fautes.
Mantha
Java c'est caca
Et de toute facon rien ne vaut le Fast CGI. Rien.
-
[^]Re: Java c'est caca
-
[^]Re: Java c'est caca
Posté par Roger Rabbit () le 23/07/2001 à 10:47. (lien). Évalué à 1.je réponds même pas tant ton commentaire n'en vaut pas la peine..
Mais qu'ont tous ces gens contre java ?-
[^]Re: Java c'est caca
-
PHP que sur Apache et IIS ????
PHP existe en module Apache mais aussi en executable ce qui permet de l'utiliser en CGI quel que soit le serveur.
-
[^]Re: PHP sur IIS
Posté par Chadom (page perso, ) le 23/07/2001 à 11:17. (lien). Évalué à 1.Nom seulement il peut fonctionner en CGI, mais il existe maintenant aussi en temps qu'objet DCOM.
Il est alors utilisable "in-process" par IIS, et je pense meme qu'il doit etre possible de faire de la repartition de charge a travers MTS.
Euh ...
Je le sens pas trop impartial le Mantha ... je le sens complement pro-java ce qui est pas le cas de tout le monde ...
En tout cas j'ai développé en JSP ( pour un client ) ... et si on m'en donne l'occasion j'en referait pas ... de toutes facons je suis un decu de java en general ...
Oui, mais...
Quand j'ai lu l'article, j'ai cru que c'était une pub pour JSP... ;o) Non, sérieusement, je ne peux ni approuver, ni réfuter les arguments ci-dessus, même si j'estime que jsp est plus gourmand que php en termes de charge. Par contre, je peux dire que PHP est beaucoup plus simple à mettre en oeuvre que JSP... et pour cause : le langage, dérivé du C, est immédiatement accessible pour ceux qui ont déjà codé en C. Personnellement, j'ai codé en C et en Java, et je trouve JSP plus complexe à mettre en oeuvre. Mais c'est peut-être aussi parce que je n'ai pas eu la bonne doc sous la main au bon moment... Et puis dans le cadre de gros projets, cela n'a pas forcément d'importance.
-
[^]Re: Oui, mais...
Posté par mister popo (page perso, ) le 23/07/2001 à 10:51. (lien). Évalué à 1.le soucis du JSP, c'est le debugging, les erreurs que l'on recupere en dessous du magnifique "erreur 500" sont les erreurs de la servlet generé, et c'est pas évident de retrouver la ligne dans le JSP.
Pour revenir sur le MVC, le projet Velocity de Jakarta est bien plus propre que du JSP :
http://jakarta.apache.org/velocity/index.html(...)
sinon, en PHP, je cherche toujour comment utilisé une variable accessible depuis toutes les pages du site.-
[^]Re: Oui, mais...
-
[^]Re: Oui, mais...
Posté par Yann Bloch (page perso, ) le 23/07/2001 à 11:36. (lien). Évalué à 1.Et quelqu'un a déjà eu des expériences avec Cocoon ? surtout Cocoon 2, en fait ?
http://xml.apache.org/cocoon2/index.html(...)--
Yann.-
[+] [^]Re: Oui, mais...
Posté par Anonyme () le 23/07/2001 à 12:33. (lien). Évalué à -1.Moi j'avais bien aimé le film surtout
--
Nono-
[+] [^]OTBD ?
Posté par Yann Bloch (page perso, ) le 23/07/2001 à 12:37. (lien). Évalué à -1.C'est toi ?
--
Yann.
-
-
[^]Cocoon 1 et 2
Posté par mister popo (page perso, ) le 23/07/2001 à 13:31. (lien). Évalué à 1.Cocoon 1 marche tres bien, c'est rigolo, mais on se trouve vite coincé quand on veut faire du dynamique, un XSL par page? ou plein de XSL?
Par contre le 2 semble prometeur, mais j'arrive pas à l'installer. Je voudrais pas dire de connerie, mais il me semble que l'on peut utiliser du PHP pour generer le XML (qui sera ensuite mouliner avec un XSL par Cocoon 2)-
[^]Re: Cocoon 1 et 2
Posté par Nico () le 23/07/2001 à 14:12. (lien). Évalué à 1.on peut pas appliquer de feuilles XSL directement par PHP ?
-
[^]Re: Cocoon 1 et 2
Posté par mister popo (page perso, ) le 23/07/2001 à 15:03. (lien). Évalué à 1.> on peut pas appliquer de feuilles XSL directement par PHP ?
Si, avec Sablotron. Mais c'est plus complexe, avec Sablotron, tu concatene tout ton XML (ou tu utilises une fonction ou un objet) et tu le passes comme argument dans la moulinette Sablotron, ta page risque de contenir que du code. Avec la bidouille Cocoon2, ta page PHP genere du XML comme elle aurait geré du HTML, et c'est cocoon qui s'occupe du reste. Cocoon a besoin de data (le XML) et d'une feuille de style (le XSL), les datas peuvent etre dynamique et provenir de l'exterieur.-
[^]Re: Cocoon 1 et 2
Posté par Nico () le 23/07/2001 à 16:09. (lien). Évalué à 1.Ok... je connais un peu Cocoon 1, je l'ai utilisé... mais je n'arrive pas à voir l'enchainement. Comment dire à Apache de passer par PHP puis de passer au processeur Cocoon le XML sorti par PHP ?
-
[^]Re: Cocoon 1 et 2
Posté par Anonyme () le 24/07/2001 à 09:12. (lien). Évalué à 0.Apache avec le handler sur tout ce qui est XML
envoie à cocoon. Jusqu'à présent, ce handler
n'était pas chainé sur les résultats ...
en gros tu produis avec un script php du XML
et il te l'envoie sur ton navigateur. Maintenant,
tu repasses par le handler d'apache quelque soit
le type de données produites, donc si tu produis un fichier xml qui contient une feuille de style
cocoon2 applique cette feuille de style.
Théoriquement dans cocoon2, tant que tu produiras
des fichiers contenant une feuille xsl, tu pourras l'appliquer... ce qui moins lourd que dans cocoon 1 ou tu es obligé d'ajouter des ordres pour que cocoon1 réappliques ces feuilles de style en dynamique.
-
-
-
-
-
[^]Re: Oui, mais...
-
-
[^]Re: Oui, mais...
Posté par Anonyme () le 23/07/2001 à 11:47. (lien). Évalué à 0.Pas d'accord,
une erreur 500 avec la stacktrace, il suffit de regarder le code généré et tu trouves la ligne
qui fait planter.
J'ai fait du JSP/servlet et je n'ai jamais eu de problème de debugging.
le tout est de savoir ce que l'on cherche et où on doit le chercher
NioTo
-
[^]Re: Oui, mais...
Posté par gwenn cumunel (page perso, ) le 23/07/2001 à 11:55. (lien). Évalué à 1.utilise les sessions...
(hop -1)-
[^]Re: Oui, mais...
Posté par mister popo (page perso, ) le 23/07/2001 à 13:36. (lien). Évalué à 1.> utilise les sessions...
Les sessions sont propres à un utilisateur. C'est une variable disponible par tous les utilisateurs que je cherche. En java, c'est une variable "static", en ColdFusion une variable "application", ya pas d'equivalent en PHP?-
[^]Re: Oui, mais...
-
-
-
[^]Re: Oui, mais...
-
[^]Re: Oui, mais...
-
[^]Re: Oui, mais...
-
[^]Euh le debugger ca existe ;-)
Posté par Anonyme () le 23/07/2001 à 15:04. (lien). Évalué à 0.Tout bon IDE Java (JBuilder, Netbeans, ...) te permet de passer ta page JSP en mode debug et de t'arreter juste ou a eut lieu ton exception ...
Comme quoi un debugger ca sert à qqch !
Aller un dernier tips pour la route :
rajouter -classic dans les parametres de la VM lancé au moment du debug ca booste la vitesse du debug ... la raison : J2SE est livré avec Hotspot Client qui n'est pas prevu pour passer en mode debug :(
2 solutions :
- mettre le Hotspot Server
- passer en JIT classique (symantec) : la fameuse option -classic
Enfin, pour casser le troll qui pointe son nez :
- Oui, en perf brute PHP est plus rapide !
- Oui, en moté en charge JSP est plus performant !
- Oui, PHP est plus simple a mettre en place pour des choses simples !
- Oui, JSP est plus simple a utiliser dans les gros projets et à réutiliser.
En resumer : Les deux technos sont biens ....
Bien sur pour ceux qui connaissent les JSP il n'y a pas trop d'interet à passer à JSP ... pour ceux qui maitrisent PHP, le seul interet à passer à JSP est l'utilisation/le besion de : multiples Taglibs, nombreuses API couvrant tout les besoins possibles et imaginables, charges de folies ...
Mon seul reproche pour PHP, est que l'on doit retourner à l'ecole et se mettre à reapprendre une flopé des methodes ... :(
Ah si seulement tout etait fait en objet sous PHP ...
Pour finir : Mieux vaut faire du PHP que de l'ASP !
3hck'.
-
-
[^]Re: Oui, mais...
Posté par loopkin (page perso, ) le 24/07/2001 à 09:52. (lien). Évalué à 1.heuu... à vrai dire Java est dérivé du C (enfin du C++), alors que PHP est dérivé du PERL... c'est d'ailleurs pour ça que Java est un vrai language objet alors que le PHP est procédural avec des possibilités objet, quand on regarde la filiation, ça se comprend tout de suite.
D'ailleurs le vrai "concurrent" de PHP, c'est pas le JSP, c'est EmbPerl / mod_perl (ou perlIS pour les inconditionnels de MaxiSaloperie).
Enfin, Java est un vrai plus c'est sur, mais je ne suis pas forcément convaincu par le JSP direct non plus, ça n'apporte pas grand chose, et si on veut respecter le MVC, il faut quand meme pas mal bosser dessus. Essayez Enhydra....-
[^]Re: Oui, mais...
Posté par Vincent Ferrari () le 24/07/2001 à 11:39. (lien). Évalué à 1.Java est un "dérivé" de l'objective C.
-
moui...
Difficile de pas tomber dans le troll..
C'est assez objectif tout de meme pour un
article ecrit par developpeur java (parceque ca ce voit qd meme :)
Mais il manque le plus important: un des 2 est en open-source..
-
[^]Re: moui...
8^D >>> moins lourdingue <<< 8^D
j'ai deja installe JSP et c'est une vraie usine a
gaz... une sorte d'ASP a la sauce SUN , dans ce
style je prefere la simplicite de PHP...
je conseilerai a ceux qui veulent un site en
java de faire des CGI en java, en plus on peut
ecrire des programmes (bytecode) java avec
d'autres langages (moins lourdingues) comme
python (tout en gardant l'acces aux api java)
http://www.jython.org/(...)
ah que ca c'est vraiement cool ...
-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Nelis (page perso, ) le 23/07/2001 à 11:06. (lien). Évalué à 1.j'ai deja installe JSP
Qu'appelles-tu installer JSP ? On n'installe pas JSP mais un serveur d'application supportant JSP/Servlet ...
et c'est une vraie usine a gaz... une sorte d'ASP a la sauce SUN
Même remarque ... Quel serveur as-tu installé ? Il y en a qui sont lourds, d'autres légers, ... Installe Weblogic pour faire tourner ton petit site web perso, ça va etre super lourd, pourtant pour faire tourner une grosse application J2EE, c'est au poil ...
dans ce style je prefere la simplicite de PHP...
Pour tes besoins a toi peut-être ... Mais pour une application plus grosse qui doit se connecter a d'autres systèmes ou exécuter des taches plus complexes, on préfèrera la richesse de Java ...
Tout est une question de besoins ...--
Vache qui rit, à moitié dans son lit-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
Posté par gabuzo () le 23/07/2001 à 11:39. (lien). Évalué à 1.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.
De toute façon mod_perl rewlz ;-).-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Nelis (page perso, ) le 23/07/2001 à 11:54. (lien). Évalué à 1.Il ne faut pas nécessairement un serveur d'application pour faire du JSP/Servlet mais uniquement un moteur de servlet
Je suis tout à fait d'accord, c'est de cela que je parlais ... Weblogic utilise son propre moteur JSP/Servlet, Orion aussi, ...
Simplement il en existe forcément de mieux fait que d'autres ...
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)
La plupart des engines vont te donner : L'exception et le message associé, la stack trace complète, le numéro de la ligne DU JSP ou l'erreur s'est produite, ...
Donc le debuging n'est ABSOLUMENT pas une catastrophe, et je sais ce que j'avance, je le fais tous les jours :-)
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é.
Effectivement cela se passe ainsi : lors d'une requete vers un JSP, l'engine regarde si le JSP a deja été compilé. Si oui, il l'execute, si non, il génère le servlet, le compile, puis l'exécute. Une fois que le JSP a été compilé, il ne devra plus l'etre. De plus, tout ça est 100% transparant pour le développeur.
particulier la difficulté pour s'interfacer avec des bibliothèques "natives"
Java est justement réputé pour s'interfacer avec un peu tout et n'importe quoi sans trop de problèmes ... Et ça se vérifie dans la pratique ! J'ai récemment du faire l'interfacage entre des bibliothèques C++ d'un logiciel de mathématique et du code Java, ça s'est passé sans problèmes !! J'ai du compiler du C ? Et alors ? Je ne vois pas le problème :-)
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
Possible... Je ne sais pas ... Aucuns des Servlet engine que j'ai utilisé n'ont encore planté ainsi ;-)--
Vache qui rit, à moitié dans son lit-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Anonyme () le 23/07/2001 à 12:09. (lien). Évalué à 0.>Possible... Je ne sais pas ... Aucuns des Servlet engine que j'ai utilisé n'ont encore planté ainsi ;-)
Arrêtes nelis! Tu ne savais pas que Sun avait créé les sites web qui plantent comme les applis?
Ne fais pas l'innocent!
De toute façon, java est accessible depuis php donc php aussi s'interface avec tout et n'importe quoi!
Sans rancune, nelis ;)-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Nelis (page perso, ) le 23/07/2001 à 12:18. (lien). Évalué à 1.Ce qui m'amuse bcp avec la plupart des "débats" ici, c'est que ça tourne vite en X contre Y avec un X tout blanc et un Y tout noir. Et que la plupart des gens ne peuvent pas concevoir qu'on aime bien X et Y, ou qu'on aime X mais qu'on ne connait pas Y, ou pire encore : qu'on aime X, qu'on aime pas trop Y mais que ce n'est pas pour ça qu'on va troller sur Y ! Vous imaginez ?? Des gens qui ne trollent pas ! Nooooon j'y crois pas ...
Je n'ai jamais dis que PHP c'était pas bien ou lent ou pas puissant ou quoi que ce soit ! J'ai dit, je connais pas PHP mais je vais y jeter un oeil car ça a l'air intéressant. Personnellement l'utilise Java, j'adore cette plateforme, mais ce n'est pas pour ça que je dis que tout le monde doit l'utiliser, je peux très bien comprendre que des gens n'utilisent pas Java car ils ne l'appécient pas ou qu'ils ne réponds pas a leurs besoins... Ce que je ne supporte pas, c'est que des gens qui critiquent qqchose qu'ils ne connaissent pas... (je ne dis pas ça pour toi, ms en regle générale)--
Vache qui rit, à moitié dans son lit-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
-
-
-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
Posté par gabuzo () le 23/07/2001 à 12:25. (lien). Évalué à 1.La plupart des engines vont te donner : L'exception et le message associé, la stack trace complète, le numéro de la ligne DU JSP ou l'erreur s'est produite, ...
Je veux bien le nom des moteurs car avec Tomcat 3.2.1 j'ai le numéro de ligne de la servlet, rien de plus.
Effectivement cela se passe ainsi : lors d'une requete vers un JSP, l'engine regarde si le JSP a deja été compilé. Si oui, il l'execute, si non, il génère le servlet, le compile, puis l'exécute. Une fois que le JSP a été compilé, il ne devra plus l'etre. De plus, tout ça est 100% transparant pour le développeur.
Oui c'est assez vrai sauf dans un cas particulier. Sur un filesystem qui ne fait pas la différence en tre majuscules et minuscules (NTFS pour ne pas le nommer) on peut s'amuser à appeler d'abord http://azerty/qwerty.jsp(...) puis http://azerty/QwErTy.jsp.(...) Avec Tomcat on se retrouve avec une erreur 500 pour ClassNotFoundException. C'est con mais Tomcat recherche le fichier QwErTy.class, le trouve car le FS ne fait pas la différence avec qwerty.class. Lorsqu'il essaye d'instancier la classe QwErTy et bien il n'y arrive pas puisque la classe dans le fichier est "qwerty" :-(.
Java est justement réputé pour s'interfacer avec un peu tout et n'importe quoi sans trop de problèmes ... Et ça se vérifie dans la pratique ! J'ai récemment du faire l'interfacage entre des bibliothèques C++ d'un logiciel de mathématique et du code Java, ça s'est passé sans problèmes !! J'ai du compiler du C ? Et alors ? Je ne vois pas le problème :-)
Bah moi j'en vois un. Lorsque tu es dans une entreprise et que tu n'as pas de licence d'un compilateur C (non gcc ça ne va pas car sous Windows gcc produit du code "cygwin" donc dépendant de l'environnement du même nom). Bref rien de techniquement infaisable mais dans la pratique impossible à faire. Sinon il faut noter que dans un service d'une entreprise travaillant uniquement en Java trouver quelqu'un pour faire le stub en C peut être un problème.
Aucuns des Servlet engine que j'ai utilisé n'ont encore planté ainsi ;-)
Bon faut que tu me donnes l'adresse de ton fournisseur de morteur de serlvet, moi j'en ai une par semaine. :-)
(PS : si tu as des URL de site "comment bien faire ses applications JSP/Servlet" je prend).-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Nelis (page perso, ) le 23/07/2001 à 12:47. (lien). Évalué à 1.
Je veux bien le nom des moteurs car avec Tomcat 3.2.1 j'ai le numéro de ligne de la servlet, rien de plus.
Avec Orion (www.orionserver.com) à la compilation :
500 Internal Server Error
Error parsing JSP page /xyz/brochure.jsp
Error in sourceFound 1 semantic error compiling "C:/orion152//brochure.jsp.java":
513. JSPHlper.getLocalDir(session) (JSP page line 116)
<------>
*** Error: "JSPHlper" is either a misplaced package name or a non-existent entity.
Erreur de runtime :
java.lang.NullPointerException
at /brochure.jsp._jspService(/brochure.jsp.java:1097) (JSP page line 287)
at com.orionserver[Orion/1.5.2 (build 10460)].http.OrionHttpJspPage.service(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)]._ah._rad(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)].server.http.JSPServlet.service(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)]._cxb._abe(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)]._cxb._uec(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)]._io._twc(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)]._io._gc(Unknown Source)
at com.evermind[Orion/1.5.2 (build 10460)]._if.run(Unknown Source)
Oui c'est assez vrai sauf dans un cas particulier. Sur un filesystem qui ne fait pas la différence en tre majuscules et minuscules (NTFS pour ne pas le nommer) on peut s'amuser à appeler d'abord azerty/qwerty.jsp puis azerty/QwErTy.jsp. Avec Tomcat on se retrouve avec une erreur 500 pour ClassNotFoundException. C'est con mais Tomcat recherche le fichier QwErTy.class, le trouve car le FS ne fait pas la différence avec qwerty.class. Lorsqu'il essaye d'instancier la classe QwErTy et bien il n'y arrive pas puisque la classe dans le fichier est "qwerty" :-(.
Ce comportement est tout à fait normal ... Les noms de classes sont case-sensitives !!
Bah moi j'en vois un. Lorsque tu es dans une entreprise et que tu n'as pas de licence d'un compilateur C (non gcc ça ne va pas car sous Windows gcc produit du code "cygwin" donc dépendant de l'environnement du même nom). Bref rien de techniquement infaisable mais dans la pratique impossible à faire. Sinon il faut noter que dans un service d'une entreprise travaillant uniquement en Java trouver quelqu'un pour faire le stub en C peut être un problème.
Bah vous achetez une licence pour un compilo C, ou vous en trouvez un gratuit (ça doit bien exister :-)). Sinon pour l'entreprise travaillant uniquement avec Java qui pourrait avoir un problème avec le stub en C, ils n'ont qu'a engager des informaticiens :-) Non mais c'est quoi ces gens qui ne sauraient faire qu'un seul langage ...
(PS : si tu as des URL de site "comment bien faire ses applications JSP/Servlet" je prend).
http://www.javaworld.com(...)
http://theserverside.com(...)
Ce sont deux très bon sites--
Vache qui rit, à moitié dans son lit-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
Posté par gabuzo () le 23/07/2001 à 12:56. (lien). Évalué à 1.Bah vous achetez une licence pour un compilo C
Bah oui mais non. Lorsqu'une boite commence à avoir une certaine taille tu peux difficilement acheter un logiciel comme un compilateur C en claquant des doigts. Ce n'est pas nécessairement impossible mais ça prend du temps.-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Anonyme () le 23/07/2001 à 13:08. (lien). Évalué à 0.T'es un peu sot-sot toi ! Tu connais bcp de grosses sociétés qui n'ont pas de compilateur C sous la main ? Franchement ?
-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
Posté par gabuzo () le 23/07/2001 à 13:54. (lien). Évalué à 1.Version courte : Oui !
Version longue : non bien sûr pour peu que le métier de la boîte soit lié au développement de logiciel c'est peut probable. Mais dans la pratique savoir que M. Tartempion a un compilateur C sur sa machine ne t'arrange pas des masses car il est sur un autre site ; ne travaille pas du tout sur la même chose que toi et malgré toute sa bonne volonté acceptera difficilement que tu le virer de son poste une journée pour faire tes trucs. Donc ça revient au même.-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
-
[^]Avec un peu d'huile de coude...
Posté par Anonyme () le 23/07/2001 à 22:11. (lien). Évalué à 0.http://www.google.fr/search?q=%22free+compiler%22+windows&hl=fr(...)
Xavier
-
-
-
-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
Posté par Anonyme () le 23/07/2001 à 13:03. (lien). Évalué à 0.>Non mais c'est quoi ces gens qui ne sauraient faire qu'un seul langage ...
C'est l'objectif que Sun veut atteindre! Un seul language qui te permettrait de TOUT faire! D'où les JSP qui arrivent pour rattraper le retard pris sur php et asp et en général au niveau du web. Depuis, ils ont bien rattrapé le coup en terme de positionnement mais uniquement grâce au marketing!
-
-
-
-
-
-
[^]Re: 8^D >>> moins lourdingue <<< 8^D
Posté par benjamin truquet () le 05/09/2002 à 12:01. (lien). Évalué à 1.si tu veux utiliser les JSP pour te faire ton site perso franchement t'as rien compris. Les JSP sont utilisées pour les grosses applications web dynamiques qui utilisent des bases de données (oracle), des serveurs LDAP et tout le toutim !
C'est fait pour fonctionner avec des serveurs d'appli comme Tomcat, Weblogic, WebSphere ...
Php c bien mais est ce que c'est portable ? je suis pas sur :o) !! Une appli developpée en jsp tu fais un .war et hop tu la passes sur une plateforme Linux, Windows ou Solaris sans faire aucun changement ds le code. Les JSP c'est uniquement fait pour les pros et pas pour faire son petit site à la maison :o)
Pour les JSP, c'est objectif :-)
Je ne connais pas PHP, mais en ce qui concerne les JSP (que eux je connais), c'est assez objectif.
Je pense que les conclusions du comparatif vont énerver pas mal de monde :) (je pense a tout ceux qui aiment se complaire dans l'idée totalement fausse que Java, c'est lourd, c'est lent, et ça ne marche pas)
Bon sur ce, je vais aller regarder à quoi ressemble le PHP, ce comparatif m'a donné envie d'y jeter un oeil :)
Vache qui rit, à moitié dans son lit
-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par François BOTTIN () le 23/07/2001 à 11:24. (lien). Évalué à 1.Moi, je connais les deux et j'ai actuellement des projets avec les deux ...
- L'un est le site pour une association, petite taille, pas de miroir ==> PHP (de toutes façon l'hébergeur ne propose pas de JSP ;-))
- L'autre est une partie d'une grosse application dont les données sont vraiment très complexes. Les données ne seraient pas raisonnablement manipulables avec PHP. La solution est donc EJB, Beans et JSP.
PS : j'ai fait quelques tests de charge avec mon projet JSP. Le serveur était sur un Pentium 233MMX, 64 MB de RAM sur réseau local 10Base-T. Avec 100 utilisateurs, temps moyen de réponse 2 s, temps maximum 5 s. Avec 1000 utilisateurs, 7 et 21 s. Donc Java n'est pas toujours lourdingue : il suffit de programmer autrement et arrêter de faire confiance au matériel pour récupérer les erreurs de conception.-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme () le 23/07/2001 à 11:43. (lien). Évalué à 0.Acné(=François B :) ; tu n'as pas compris que jsp est une grosse m@@de ???
Je suis désolé mais ton P233Mhz sous Patate , je doute qu'il fasse tourner décemment
quoi que ce soit programmé en Java .
Remarques , tu devrais essayer une Suse , pit'aitre que là ton projet JSP aurait plus
de punch .
Et puis ... ton super portable là qui tourne avec une misérable patate pas remise à jour :
Pourquoi ne pas profiter de la formidable avancé technologique que seul SUSE est à meme
de proposer ?
Je ne vois pas pourquoi tu perds ton temps à faire du Java (Mouarfff) et à laisser des patates
(Mouarfft * 2) dans tes bécanes .
PS; SI SI , JAVA EST TOUJOURS LOURDINGUE (sourtout quand ça ne tourne pas
sous SUSE(tm) )
MOUAAARRRFFF (quelqu'un que tu connais mais qui ne va pas se dénoncer , à la limite
je balance quelqu'un d'autre :)-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par Nelis (page perso, ) le 23/07/2001 à 11:58. (lien). Évalué à 1.Il y a des jours où j'ai honte de défendre la liberté d'expression ... :-|
No comment ...--
Vache qui rit, à moitié dans son lit-
[^]Re: Pour les JSP, c'est objectif :-)
-
-
[^]T'es pas sectaire non plus toi ...
Posté par Maillequeule () le 23/07/2001 à 13:15. (lien). Évalué à 1.Je m'etonne que personne n'ai encore dit que seul COBOL vaut quelque chose et qu'il serait incorrect de meme oser penser autre chose...
quelqu'un a un decapsuleur sur lui ? parce que je vois des oeilleres qui ne vont pas etre faciles à enlever la...
Ok, le semblant d'etude est a mon gout un peu leger, et pas vraiment objectif. Ok, c'est une magnifique rampe de lancement pour trolls , mais quand meme...
Est ce quelqu'un va prendre un jour le recul necessaire pour penser que ce qu'il pratique au jour le jour n'est pas le meilleur langage du monde (a supposer que ca existe, mais ca me fait bien rire) et que d'autres font au moins aussi efficace avec d'autres choix technologiques ?
Pour avoir pratiqué les JSP et PHP sur des projets de taille sympathique, je prefere vous dire qu'a ces occasions la il etait impossible de preferer l'un a l'autre, pour la simple raison qu'il ne collaient pas tous les deux aux besoins ni a l'architecture choisie au moment T.
Bon, ceci dit, il faut que je m'excuse aupres de messieurs les fanatiques hein : PHP, servlets, jsp, et base oracle tournent sous RedHat, ce qui va a l'encontre de l'elitisme ambiant.
Et non je n'ai pas eu honte, et oui merci, ca tourne bien.
Mike
-
-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme () le 23/07/2001 à 13:25. (lien). Évalué à 0.le tout c'est de ne pas programmer comme un porc. j'en connais même qui mettent des goto en C ...
bon aller je te balance pas mais par pure gentillesse.-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme () le 23/07/2001 à 20:03. (lien). Évalué à 0.Moi aussi je connais des porcs qui codent avec des goto : dans le code de certains drivers du noyau Linux...
Un bon grep goto *.c dans les sources, du cote des drivers, riqueraient de te faire penser ce qui suit :
<SecondDegre>
Ca doit vraiment etre une grosse merde avec des goto dans code C, beurk beurk...
</SecondDegre>-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme () le 23/07/2001 à 21:46. (lien). Évalué à 0.oui mais la c'est pas des drivers du noyo et faudrait pas croire que c'est méga optimisé.
-
[^]vive le goto (parfois)
Posté par Anonyme () le 23/07/2001 à 22:39. (lien). Évalué à 0.Le goto peut être utiliser pour améliorer la lisibilité (on evite de ce trainer une variable qui indique l'état de la fonction).
Exemple pour la gestion d'erreur :
int toto(void) {
int all_ok = 0 ;
if ( .... == probleme ) {
goto erreur ;
}
.
.
.
if ( ... == probleme ) {
goto erreur ;
}
.
.
.
return ok ;
erreur:
// boulot sur erreur
return pas_ok ;
}
Visual Basic propose l'excellent "on error goto".
Exemple pour sortir de beaucoups de boucle imbriqués.
qqc * chercher(...) {
for(....) {
while {
for(....) {
if (c'est presque le bon) {
.
.
.
if (c'est le bon) {
goto trouve ;
}
}
}
for(....) {
if (c'est le bon) {
goto trouve ;
}
}
}
}
return NULL ;
trouve:
// faire qqc
return qqc ;
}
P.S.: désolé pour ce code pas indenté mais dacode n'autorise pas la borne "<pre>" ni les " "
Dacode pourrait autoriser "<pre>" mais dans ce cas utiliser la fonction wordwrap() (cf:http://www.php.net/manual/en/function.wordwrap.php(...)) pour éviter les lignes trop longues.
-
-
-
-
-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par PLuG () le 23/07/2001 à 11:48. (lien). Évalué à 1.humm ... comment a tu fait tes tests ?
avec quel injecteur ??
qu'est-ce qu'un UTILISATEUR pour ton injecteur ?
parce que simuler ne serai-ce que 1000 requetes simultanées c'est pas une chose aisée ... il faut plusieurs machines en parallèle ...
de plus 1 requete != 1 utilisateur:
sur une page web souvent il y a des images ... donc plusieurs requetes HTTP.
quand il y a des saisies, un utilisateur qui par pisser au milieu d'un écran de saisie ca peut bloquer sa session du cote du serveur ... et quand tu as 1000 utilisateurs simultanés, tu peux avoir beaucoup de sessions en attente ...
bref prenons des pincettes pour manipuler ces chiffres.
PLuG-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par François BOTTIN () le 23/07/2001 à 14:00. (lien). Évalué à 1.Bon, on va faire ça dans l'ordre ...
humm ... comment a tu fait tes tests ?
avec quel injecteur ??
Deluge ( http://deluge.sourceforge.net(...) ) et Hammerhead ( http://hammerhead.sourceforge.net(...) ). Tous deux sont en GPL ...
qu'est-ce qu'un UTILISATEUR pour ton injecteur ?
Un utilisateur pour l'injecteur est un utilisateur dans l'application : préférences + contexte.
parce que simuler ne serai-ce que 1000 requetes simultanées c'est pas une chose aisée ... il faut plusieurs machines en parallèle ...
En effet, il y en avait trois. De toutes façons, je pense que je n'étais pas loin de la limitation physique du réseau (10 Mb/s). Il faudrait que je regarde plus en détail les résultats ...
de plus 1 requete != 1 utilisateur:
En effet, il s'agit d'un serveur de documentation. Je suis parti de l'hypothèse qu'un utilisateur actif charge une page environ toutes les 30 secondes. Je pense d'ailleurs que c'est assez large ... mais comme je suis au début du développement du projet, c'était juste pour voir si la solution était viable.
sur une page web souvent il y a des images ... donc plusieurs requetes HTTP.
Il y a en fait très peu d'images dans mon cas, et la plupart d'entre elles sont sur toutes les pages (logo de l'application, pictogrammes de sections ...) et résident donc dans le cache du navigateur. Sinon, il doit y avoir une dizaine d'images non récurrentes. La probabilité de tomber sur une page ayant une image doit être inférieure à 0.1%. Mais bon, ce que je voulais tester était la réponse applicative (J2EE + BDD), pas le serveur ...
quand il y a des saisies, un utilisateur qui par pisser au milieu d'un écran de saisie ca peut bloquer sa session du cote du serveur ... et quand tu as 1000 utilisateurs simultanés, tu peux avoir beaucoup de sessions en attente ...
Dans mon application, les actions d'un utilisateur n'impactent pas les autres. Je n'ai à aucun endroit de système de verrou sur les données globales par un utilisateur. Les seules saisies possibles concernent les préférences de l'utilisateur (ne peut potentiellement bloquer que cet utilisateur) et l'administration de l'application (un bloquage des sessions est alors voulu). J'ai considéré que ces saisies étaient marginales dans l'utilisation de l'aplication, je les ai donc exclues de mon test.
En fait, les chargements de données dans la base ne sont possible que depuis une application indépendante qui va directement taper dans les EJB. Il serait beaucoup trop complexe d'essayer de faire ça depuis l'application HTTP à cause de la très grande quantité d'informations à lire sur le disque ... Il est également prévu d'automatiser ces mises à jour, qui peuvent alors avoir lieu pendant les heures creuses d'utilisation.
bref prenons des pincettes pour manipuler ces chiffres.
C'est vrai que j'aurais dû préciser dès le début, mais les frustrés qui ne connaissent pas Java m'ont trop énervé pour que j'y pense de prime abord ...-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme () le 23/07/2001 à 14:31. (lien). Évalué à 0.>C'est vrai que j'aurais dû préciser dès le début, mais les frustrés qui ne connaissent pas Java m'ont trop énervé pour que j'y pense de prime abord ...
Donc, tu nous as sorti une réponse de frustré! Un test sur ta machine perso pour servir de la doc à 3 clampins pour prouver que les JSP sont faites pour les gros projets! Merci Acne, en tout cas, de te joindre à mantha pour nous fournir ce pur moment de rigolade pendant les vacances :))
-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par PLuG () le 23/07/2001 à 16:39. (lien). Évalué à 1.Merci beaucoup, ca fait un moment que j'ai pas fait de mesures de performance et je ne connaissais pas ces 2 projets opensource. ==> bookmark.
Je suis tout de même agréablement surpris par les chiffres que tu donnes. Ils sont plus qu'honnorable pour la configuration matérielle utilisée.
Ca me fait penser à un jour ou un collegue avait des temps de réponse terrible ... en fait les pages qu'il récupérait avec son injecteur etaient toutes des erreurs 404 :-)) Mais vu ta réponse je vois que tu as du étudier tout cela de près.
-
-
-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par PLuG () le 23/07/2001 à 11:34. (lien). Évalué à 1.Bon je rebondis de suite sur cette phrase:
Java c'est lourd,c'est lent, ....
Je ne suis pas un trolleur fou et je vais donc argumenter.
Java est une solution technique (c'est pas seulement un language) forcement lourde puisque le code généré n'est pas adapté au CPU mais à une machine virtuelle [quand on a pas un cpu JAVA]. Ca ressemble à executer du code pour x86 sur un macIntosh dans un emulateur.
Les fanatiques de JAVA vont dire que ca marche quand meme et ils auront raison. Mais le même programme compilé pour l'architecture cible et écrit correctement sera forcement moins gourmand en ressources CPU/RAM/... et donc potentiellement plus rapide puique seul l'algo utile tournera.
Ensuite les mêmes fanatiques de JAVA nous reparleront des tests qui ont montré un code JAVA tourner aussi vite que son homologue en C, mais ils oublieront que cela depend de la charge de la machine, que en JAVA sur beaucoup de plateformes c'est la JVM qui gère le scheduling des threads JAVA [et elle est moins douée que le scheduleur de l'OS, ca peut même bloquer tous les threads JAVA sur un seul CPU !!] et enfin que dans le cadre de ces tests, le code JAVA avait été soigné [de vous à moi, entre un développeur C et un développeur JAVA, lequel des deux risque de mieux soigner son algo ? celui qui ne se pose même pas la question de libérer la mémoire et espère le passage d'un garbage collector à un moment ou son appli n'aura pas besoin de trop de CPU ??]
Je ne suis pas un fanatique de JAVA, mais je vois bien les avantages des solutions JAVA quand même:
Un seul package qui s'installe sur toutes les plateformes. C'est le seul avantage mais il est de taille pour tous ceux qui ont déjà VRAIMENT produit du logiciel, cela supprime des hommes/mois de boulot de packaging, tests ...
Ce package multiplateforme est donc tout indiqué pour le web ou l'architecture du client est inconnue (applets). Pour les servlets ca se discute plus, mais ca fait le bonheur des vendeurs de serveurs ... et des developpeurs. Si JAVA est plutot une solution d'architecture, il a su séduire beaucoup de développeurs en tant que langage. Du coup il y a souvent confusion ...
PLuG-
[^]Re: Pour les JSP, c'est objectif :-)
-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par truelle () le 24/07/2001 à 07:16. (lien). Évalué à 1.Pourquoi troller lorsque l'on peut argumenter de cette façon. Bref, je suis tout à fait d'accord avec toi PLuG.
Il va sans dire qu'avec la pléthore de langages disponibles actuellement, il n'est pas déraisonnable de choisir celui répondant le plus aux besoins du projet. Actuellement, c'est encore le coeur qui parle...
-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par gle () le 24/07/2001 à 08:17. (lien). Évalué à 1.Effectivement Java en tant que plateforme a d'énormes avantages au niveau de la portablilité. Ceux qui ont déjà eu à maintenir des projets multi-plteforme comprendront.
En tant que langage, Java est aussi très bien. Une approche totalement objet, un syntaxe claire, et la majorité des erreurs sont détectées à la compilation car le langage est peu permissif.
Et en tant qu'API, Java c'est aussi un vrai bonheur, car presque tout ce dont vous avez besoin existe, bien programmé, et avec une interface standard. Un vrai régal!
Quand aux trolls sur le thème Java c'est lent, sachez que tout le monde se fout que le C soit 10% plus rapide dans les milieux professionnels. Si l'algo est bien fait, la montée en charge sera la même en C et en Java (avec toujours 10% de différence), et c'est ça qui importe. Sauf que le C plantera sans doute en arrivant à ses limites parceque le programmeur aura eu la flemme de faire la gestion d'erreurs correctement, ou qu'un free() aura été oublié.
Vous ne semblez pas comprendre que généralement la démarche est de programmer l'algo, de faire des tests de charge, et de choisir la conf de la machine de prod en fonction de la charge à supporter. Avec Java, la machine sera peut-être un peu plus chère mais comparé au coût de développement du logiciel, c'est peanuts.
Enfin, quant à la guerre JSP contre PHP, elle n'a pas lieu d'être pour moi car leurs domaines de prédilection ne se recoupent pas. PHP est adapté à la création de sites dynamiques légers et rapides, les JSP permettent de mettre en oeuvre des solutions lourdes et de s'interfacer avec d'autres sytèmes (genre Bdd professionnelle, middleware ou aute système d'information de l'entreprise).-
[^]Re: Pour les JSP, c'est objectif :-)
Posté par Anonyme () le 24/07/2001 à 10:21. (lien). Évalué à 0.hmmm..... Non, vraiment non. J'ai beau chercher mais tu ne fais pas le poids fasse à PLUG. Tu aurais posté dans un autre commentaire, tu aurais eu ta chance mais ici, ça le fait vraiment pas.
Tu te raménes avec les mêmes vieux arguments marketing.
Il faut sortir, le week-end, pour voir ce qui se passe à l'extérieur.
A oui, ta signature aussi, ça te décrédibilise vachement. Je serai toi, j'éviterai si je veux paraître sérieux.-
[+] [^]Re: Pour les JSP, c'est objectif :-)
Posté par gle () le 24/07/2001 à 15:58. (lien). Évalué à -1.Qui es-tu, petit scarabée anonyme pour m'attaquer personnellement? Ton commentaire ne vaut même pas la note de zéro qui lui a été si généreusement infligée. Bafouant les règles élémentaires d'orthographe, de grammaire et de typographie, tu te permets de déverser ta bile sans argument aucun.
Sache que je te méprise cordialement et t'invite à essayer d'utiliser la masse spongieuse qui git entre tes oreilles pour tenter de réfléchir, et pourquoi pas d'argumenter pour transformer cette foire à trolls en débat.
Quant à ma signature, j'en fais ce que j'en veux.
(-1 - Ca fait pas avancer le débat)
-
-
-
-
[^]Re: Pour les JSP, c'est objectif :-)
Licence
php est en gpl, mais je crois que ce n'est pas le cas de jsp?
si quelqu'un sait q'il réponde!
-
[^]Re: Licence
Posté par Val (page perso, ) le 23/07/2001 à 11:19. (lien). Évalué à 1.Ouais je veux bien répondre à une question aussi débile, ça veut dire quoi pour toi ça :
http://packages.debian.org/testing/libs/libservlet2.2-java.html(...)
Cordialement, et sans troll :-P-
[^]Re: Licence
-
-
[^]Re: Licence
Posté par Nelis (page perso, ) le 23/07/2001 à 11:21. (lien). Évalué à 1.Il faut replacer les différentes choses dans leurs contextes ...
Les spécifications JSP ne sont pas en GPL (d'ailleurs je ne sais pas si la GPL en tant que telle peut-être appliquée à des specs), mais elles sont publiques : tu as accès gratuitement aux specs complètes et tu es libre de les implémenter (comme toutes les specs Java).
Par contre tu as des implémentations des spécifications JSP qui sont sous diverses licenses : propriétaire (Weblogic par exemple), Apache Software License (Jakarta/Tomcat), peut etre meme GPL (je n'ai pas de nom en tete).
Voilà, j'espère que les choses sont un peu plus claires pour toi :-)--
Vache qui rit, à moitié dans son lit-
[^]Re: Licence
Posté par Anonyme () le 23/07/2001 à 11:42. (lien). Évalué à 0.rappelons au passage (en essayant de passer entre les trolls) que PHP n'est pas 100% GPL : il y a un optimiseur de qqch (dont j'ai oublié le nom) qui améliorerait notablement les perf et que les auteurs n'ont pas jugé bon de soumettre à la même licence que le reste.
-
[^]Re: Licence
-
[^]Re: Licence
Posté par Serge Rossi (page perso, ) le 23/07/2001 à 12:09. (lien). Évalué à 1.Oui, le compilateur JIT Zend.
Y'a meme un compilateur qui crée de vrais binaires à partir de code PHP en commercial. Je vais regarder son cout et le faire acheter par ma boite si besoin... Si ça peut permettre de gagner un millipoil en temps de réponse sur les PHP les plus utilisés, ça peut etre intéressant...
Tiens, ça aussi c'est un avantage de PHP que Java n'a pas : générer un vrai binaire :-)-
[^]Re: Licence
Posté par Anonyme () le 23/07/2001 à 13:30. (lien). Évalué à 0.> Tiens, ça aussi c'est un avantage de PHP que Java n'a pas : générer un vrai binaire :-)
Tout dépend de ton environnement d'exécution. Il existe des compilateurs java qui produisent du code natif. Au hasard, le GNU java compiler :
http://gcc.gnu.org/java/(...)
-
[^]Re: License
Posté par Anonyme () le 23/07/2001 à 14:12. (lien). Évalué à 0.et non .......
Le compilo de Zend n'est pas un compilateur ...
il génère du byte code ... comme les compilo java (faudrait changer les noms c'est vrai que appeler ca compilateur aussi ca prete à confusion)
D'ailleurs pire ... pour pouvoir le réinterpreter derriere il faut avoir le Zend Optimizer (qui fait office d'interpreteur pour le byte code)
Et d'apres ce qu'on ma dit (désolé je n'ai pas les sous pour faire les tests moi meme) on ne gagne pas grand chose .... c'est plus pour cacher les sources.
-
-
-
ja va est trop gourmand en ressources
un serveur d'application J2EE est extremement gourmand en ressources.
Il semblerait que ce soit pour cela que des serveurs avec Tomcat/Jboss tombent régulièrement
ceci dit c'est vrai que pour traiter de l'objet metier au sein d'un intranet il vaut mieux java que php
-
[^]Re: ja va est trop gourmand en ressources
Posté par Anonyme () le 23/07/2001 à 11:48. (lien). Évalué à 0.Certes, mais les machines actuelles sont suffisament puissantes pour que cela ne se fasse pas trop sentir... si bien sur la conception de l'appli java est assez propre :)
Pour moi le comparatif est un peu faussé par le fait qu'on ne peut pas réellement comparer jsp et php puisque l'interet de développer des jsp sans servlets derrière est assez limité... Mais ce comparatif a le mérite de faire le point.
[+] ATTENTION !!!
Cette news cache un Troll énorme !!!
-
[^]ABSOLUMENT PAS !!!!
Posté par Nelis (page perso, ) le 23/07/2001 à 11:27. (lien). Évalué à 1.Cette news ne cache AUCUN troll !!! C'est un comparatif assez objectif entre PHP et JSP.
Alors arrete de dire des conneries, si dès qu'une news parle de qqchose qui ne te plait pas, c'est que c'est un troll, créé la DaAnonymeFrenchPage et ne parle que de toi dessus ... La tu auras la paix !!--
Vache qui rit, à moitié dans son lit-
[^]Re: ABSOLUMENT PAS !!!!
Posté par François BOTTIN () le 23/07/2001 à 11:41. (lien). Évalué à 1.<parodie src="slogan de pub">
Ce sont ceux qui trollent le plus qui connaissent le moins ...
</parodie>-
[^]Re: ABSOLUMENT PAS !!!!
-
-
[^]Re: ABSOLUMENT PAS !!!!
-
[^]Re: ABSOLUMENT PAS !!!!
Posté par Anonyme () le 23/07/2001 à 11:57. (lien). Évalué à 0.Tu commences à nous gonfler nelis avec ton java machin!
Personne ne t'empêche de l'utiliser mais ne te raméne pas avec tes potes trollesques pour démonter ceux qui ne l'utilisent pas!
C'est quoi cette news à 2 balles sinon un troll?
Rien n'est objectif!
Le mec balance des énormitées:
"- php peut se connecter à toutes les bases de données du marche mais les
interfaces sont propriétaires :
Pour ouvrir une connexion avec mysql : mysql_connect
Pour ouvrir une connexion avec oracle : OCILogon"
Je ne compte pas le nombre de fois ou il dit: "je crois, enfin je ne suis pas sûr, à vérifier quand même,..."
L'auteur nous prouve que c'est un troll:
"comme son nom l'indique (php = Personnal Home Page) permet le
développement plus rapide de petites applications web"
Si ça, c'est un comparatif objectif... Ca veut aussi dire "PHP: Hypertext Preprocessor" mais peu importe. L'auteur se base sur le nom du produit pour tirer des conclusions: trés objectif!
Bon, je ne parle pas du reste qui ne sert à prouver que "directeur technique" ne veut vraiment rien dire (dans ce cas là en tout cas). Au moins il retient les grandes lignes maketing, c'est déjà ça! MVC, EJB,etc...
Bref, c'est quoi cette news de merde? Ca part peut être d'une bonne intention mais il fallait faire quelque chose de + sérieux au niveau de la comparaison et pas ce lynchage idiot qui est un trollpot!
Au fait, nelis. Tu l'a eu, ton bac, cette année?-
[^]Re: ABSOLUMENT PAS !!!!
Posté par Nelis (page perso, ) le 23/07/2001 à 12:06. (lien). Évalué à 1.Ouh la :-) C'est quoi toute cette agressivité mon grand ?? :-) Tu crois vraiment que j'organise un complot pour te faire aimer Java ? Je te rassure ce n'est absolument pas le cas :-)
Je ne connais pas l'auteur de la news, et je trouve qu'avec le JSP il est objectif ! Pour le PHP voir mon commentaire plus haut, j'ai dis que je ne savais pas juger parce que je ne connaissais pas, mais que ça m'a donné envie d'y jeter un oeil ;-)
Je ne démonte personne, je n'ai jamais dit a personne d'utiliser PHP plutot que Java, je donne juste des arguments lorsque je ne suis pas d'accord avec un commentaire ... Regarde mes différents post sur cette page et dis moi ou tu vois des trolls ...
Enfin dernier commentaire concernant ta dernière phrase, j'ai terminé mon graduat en informatique industrielle il y a un an, et depuis je travaille pour une boite qui développe des applications ... J2EE :-) Voilà pkoi le sujet me tient à coeur ... Et toi, tu l'as eu ton bac ?--
Vache qui rit, à moitié dans son lit-
[^]Re: ABSOLUMENT PAS !!!!
Posté par Anonyme () le 23/07/2001 à 12:34. (lien). Évalué à 0.J'avoue, nelis, j'ai voulu te taquiner.
Aprés ton post où tu disais gentillement:
>Alors arrete de dire des conneries
j'ai voulu voir ta réaction, surtout que ta fougue envers java m'amusait déjà.
Bonne réaction, tu ne m'as pas insulté même si tu en mourrais d'envie! Trés bien!
N'empêche nelis, ce texte a beau être à la limite du correct quand il parle des JSP, s'il ne l'est pas au niveau du PHP, c'est un troll,FUD,etc...
Et là, malgré ta politesse, je ne peux être d'accord avec toi quand tu défends ce genre de truc. Je pensais que java n'avait pas besoin de ça pour être considéré comme une solution viable.
Par contre, je n'ai que mon brevet des colléges et un bi-proc 800MHz, donc je crains que java et les EJB ne restent pour moi qu'un doux rêve!-
[^]Re: ABSOLUMENT PAS !!!!
Posté par Nelis (page perso, ) le 23/07/2001 à 12:52. (lien). Évalué à 1.Bonne réaction, tu ne m'as pas insulté même si tu en mourrais d'envie! Trés bien!
Bah on y gagne rien a insulter :-) Meme si parfois ça fait du bien et ça défoule, ça nous retombre tjrs dessus ...
N'empêche nelis, ce texte a beau être à la limite du correct quand il parle des JSP, s'il ne l'est pas au niveau du PHP, c'est un troll,FUD,etc...
C'est possible, comme je l'ai dis je ne connais pas PHP, par contre je serais très heureux de l'apprendre :-) Si tu veux on en parle autour d'une bonne bière ? ;-)--
Vache qui rit, à moitié dans son lit
-
-
-
-
[^]Re: ABSOLUMENT PAS !!!!
Posté par Anonyme () le 23/07/2001 à 12:04. (lien). Évalué à 0.dès qu'une news parle de qqchose qui ne te plait pas, c'est que c'est un troll
non, cette news n'est pas objective. elle est pro-jsp.
et c'est pour cela que c'est un troll déguisé.
et je ne connais pas assez le jsp pour en parler, donc je ne participerait pas plus au débat, mais il n'y a pas besoin de s'y connaitre dans le domaine pour le voir.
magic23, qui n'etait pas autentifié, qui n'avait pas fait gaffe, et qui a la flemme de retrouver son mot de passe.
-
[^]Re: ABSOLUMENT PAS !!!!
-
Amusant :-)
Depuis 3 ans, on fait tous nos développements d'entreprise en PHP (PHP3 au début, 4 maintenant), le tout attaquant directement la base de données d'entreprise : Oracle. (plateforme Apache sur Solaris)
Parmis les "petites" applis qu'on a réalisé, je peux citer un workflow complet d'achats connecté à notre serveur SAP/R3, les systèmes de saisie d'heures travaillées et de congés tenant compte de la legislation des 35 heures, un SGDT pour notre système de CAO permettant, entre autres, de faire des compositions numériques de véhicules et de visualiser ces compositions en VRML sur n'importe client....
Point de vue développement, c'est extrèmement rapide et c'est parfaitement fiable. L'orientation
objet de PHP permet facilement de définir des classes comunes à toutes les applis et donc de développer toutes les applis selon un framework commun. Quelqu'un d'autre de ma boite qui lit aussi linuxfr.org pourra en rajouter sur le sujet si ça lui dit ;-)
Parallèlement, du fait de l'achat (pas eu mon mot à dire) d'un logiciel du commerce basé sur JSP, j'ai du le mettre en place (JSP avec Apache sur Solaris, encore) et je peux dire que de mon expérience (admin, pas développeur), c'est un véritable cauchemard à mettre en place, c'est lent lourd et pénible à maintenir. Et je trouve que ça bouffe bien trop de ressources par rapport au peu de hits que ça fait.
Pour moi, JSP = bricolage... Mais ce n'est que le point de vue d'un admin...
Dans l'équipe des développeurs, y'en a un qui a déjà fait du JSP et il préfère largement le PHP, y'a pas photo (ca fait un peu léger comme argument technique mais bon...)
-
[^]Re: Amusant :-)
Posté par Val (page perso, ) le 23/07/2001 à 15:07. (lien). Évalué à 1.C'est bien, t'as l'air de maitriser PHP et c'est tout à ton honneur. Seulement t'as pas l'air d'avoir lu le moindre bouquin sur les JSP et encore moins sur Java : l'apprentissage en est certainement plus long. Aussi je rassure tous les autres, une fois qu'on a compris comment marche un serveur (je dirai presque "un serveur quelconque") de JSP les autres ont globalement la même façon de fonctionner, d'un point de vue administration et développement : ça fait partie du fameux contrat "Container-Developer" et "Container-administrator". Mais j'ai bien compris, tu lis pas les docs... et encore moins les spécifications :-P.
Aller, finalement t'aime pas... alors ne dit pas que ça ne marche pas chez toi.-
[+] [^]Re: Amusant :-)
Posté par Anonyme () le 23/07/2001 à 16:12. (lien). Évalué à -1.eh vallar!
Toi ka l'air de bien maitriser jsp et autres (java koi), pourquoi tu nous réécrirais pas dacode 1.2 en jsp? C'est vrai ke 10Mhit/M, c'est pas un gros site mais c'est juste pour voir.
Tu peux développer avec ki tu veux (nelis,acne,frafra,etc....) pour qu'on ai une chance de voir kkchose avant 2003.
Juste une restriction: pas de mainframe!
Il faut ke sa tourne sur le même serveur k'actuellement!
Alors, ça roule pour le challenge?-
[^]Re: Amusant :-)
Posté par Nelis (page perso, ) le 23/07/2001 à 18:36. (lien). Évalué à 1.C'est pas drole de cloner :-( Puis il va très bien DaCode, pkoi vouloir le changer ??
Sinon, si vous avez un projet intéressant à proposer, je suis partant :-)--
Vache qui rit, à moitié dans son lit
-
-
[^]Re: Amusant :-)
Posté par Serge Rossi (page perso, ) le 23/07/2001 à 17:20. (lien). Évalué à 1.Je te rapelle que je suis admin, pas développeur : j'ai donné le point mon point de vue d'admin qui est que maintenir un serveur Apache + JSP c'est chiant, lourd et consomateur de ressources, surtout comparé à un serveur PHP !
Et là, je parle d'un serveur dans un bureau d'études de 3000 personnes avec des utilisateurs éparpillées un peu partout en Europe et en Amérique du Sud, donc la disponibilité est TRES importante !
Pour ce qui est de la doc, j'en ai déjà lu un tout petit peu (!), je te remercie, pour mettre en place des config Apache + PHP + SSL + authentifications Radius et LDAP, sans meme parler de Apache + JSP et j'oublie tout un tas d'autres modules !
Pour ce qui est du développement, je fais confiance aux développeurs quand ils me disent préférer PHP à JSP. Et quand je vois les superbes applis qu'ils pondent en PHP : je les crois :-)
-
-
[^]Re: Amusant :-)
Posté par Anonyme () le 14/09/2001 à 15:51. (lien). Évalué à 0.C'est vrai idem. moi je développe un site de E-BROKER en PHP3 avec MySQL mais on va passé sous ORACLE..... MAis il est vrai que dans la tendance actuelle pour tout ce qui touche le banquaire, il est demandé d'utilisé de JSP... car beaucoup de transaction d'un server à un autre ETC... donc Java il y derrière.....
là vous comparé ACCESS avec Visual BASIC...
PHP est très puissant je pense même que c'est plus rapide que le JSP, mais le PHP est extra pour tout ce les site Editoriaux. Ensuite on passe dans la cour des grands avec le JSP.
Aujourd'hui les entreprise demande du java car il y a une image derièrre pourtant
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.