Articles précédents : Logiciel
- [68] Lecteur DivX des platines Kiss sous licence GPL
- [45] Mark Shuttleworth offre des récompenses pour développer Mozilla
- [18] Knoppix STD : un concentré de securité dans 1 CD
- [9] Digikam 0.6.0 disponible en Release Candidate
- [77] La branche de développement de Gnome (2.5.0) vient d'émerger
- [37] Sortie du noyau Linux 2.4.23
- [19] Résumé GNOME 22-11-2003
- [24] Nouveau manuel blender en pré-commande
- [19] News de la fondation Xiph : Vorbis 1.0.1 et Speex 1.0.3
- [48] Sortie d'ALSA 1.0.0pre1
Liens connexes
- L'annonce (774 hits)
- Le site tomcat (1408 hits)
- Les binaires (574 hits)
- Les sources (435 hits)
Dépêche modérée par
Logiciel : Tomcat : première version stable de la branche 5
Posté par Xavier Poinsard (page perso, ). Modéré le 04 décembre 2003.
Par rapport à la version 4 :
- implémentation des spécifications Servlet 2.4 et JSP 2.0,
- performances, stabilité et montée en charge améliorées
- monitoring possible grâce à JMX
- possibilité de précompiler l'application
Rappel : Tomcat est le serveur de servlet et de jsp utilisé dans l'implémentation officielle de référence et est développé sous licence Apache.
![[en]](../../../images/en.png)
L'annonce (774 hits)-
Le site tomcat (1408 hits)
-
Les binaires (574 hits)
-
Les sources (435 hits)
> Lire la dépêche (28 commentaires, moyenne: 3,2).
[+] Re: Tomcat : première version stable de la branche 5
Cool !!!!!!!!
On va tester ça sur les serveurs de test !! De l'amusement en perspective en cette fin de semaine :op
Bonne journée, vais me lire tout ça et m'amuser !!
Christophe
- Christophe -
-
[^]Re: Tomcat : première version stable de la branche 5
Posté par lorill (page perso, ) le 04/12/2003 à 10:06. (lien). Évalué à 3.sauf que a peine downloadé, ca marche pas :
INFO: Installation d'une application pour le chemin de contexte /jsp-examples depuis l'URL file:C:\Documents and Settings\fiackv\Bureau\tomcat5\jakarta-tomcat-5.0.16\webapps\jsp-examples
4 déc. 2003 11:02:18 org.apache.catalina.core.StandardContext start
GRAVE: Error filterStart
4 déc. 2003 11:02:18 org.apache.catalina.core.StandardContext start
GRAVE: Erreur de démarrage du contexte suite aux erreurs précédentes
...-
[^]Re: Tomcat : première version stable de la branche 5
Posté par Wallou Wally () le 04/12/2003 à 10:12. (lien). Évalué à 2.C'est koi la trace d'erreur complète ?
-
[^]Re: Tomcat : première version stable de la branche 5
Posté par lorill (page perso, ) le 04/12/2003 à 10:18. (lien). Évalué à 2.2003-12-04 11:16:11 StandardContext[/jsp-examples]Exception au démarrage du filtre Compression Filter
java.lang.ClassNotFoundException: compressionFilters.CompressionFilter
[...]
2003-12-04 11:16:11 StandardContext[/servlets-examples]Exception au démarrage du filtre Set Character Encoding
java.lang.ClassNotFoundException: filters.SetCharacterEncodingFilter
[...]
2003-12-04 11:16:11 StandardContext[/servlets-examples]Exception au démarrage du filtre Compression Filter
java.lang.ClassNotFoundException: compressionFilters.CompressionFilter
bon, c'est simple a corriger, mais c'est un peu moche d'avoir ca dans un binaire sorti du package.
-
-
[^]Re: Tomcat : première version stable de la branche 5
Posté par governator () le 04/12/2003 à 10:48. (lien). Évalué à 1.sous linux ça tourne, enfin les exemples jsp / servlets, je n'ai pas encore testé d'applis complètes
-
[^]Re: Tomcat : première version stable de la branche 5
Posté par lorill (page perso, ) le 04/12/2003 à 11:32. (lien). Évalué à 3.ouais en fait j'ai trouvé, c'est le tgz qui se décompresse mal :
CompressionFilter.clas100644 au lieu de .class, ca peut pas marcher :o
-
-
[^]Re: Tomcat : première version stable de la branche 5
Posté par ome () le 04/12/2003 à 11:37. (lien). Évalué à 1.Essaie déjà d'installer Tomcat dans un répertoire qui ressemble à quelque chose!
Et pas un truc du style ".../Document and Settings/..." ou ".../Program files/..." avec des noms composés de répertoire...-
[^]Re: Tomcat : première version stable de la branche 5
Posté par KaZeKaMi (page perso, ) le 04/12/2003 à 13:30. (lien). Évalué à 1.cela fonctionne très bien dans Program Files, et il me paraît logique qu'on puisse l'installer dans un répertoire qui contienne des espaces.
-
[^]Re: Tomcat : première version stable de la branche 5
-
-
-
Re: Tomcat : première version stable de la branche 5
Quelqu'un s'y connait en JMX ?
J'en ai entendu que du bien mais j'ai pas eu le temps de me pencher dessus...
C'est bien ? facile ? porteur ?
-
[^]Re: Tomcat : première version stable de la branche 5
Posté par Wallou Wally () le 04/12/2003 à 10:11. (lien). Évalué à 4.C'est super, JBoss intégère une console JMX complète accessible en HTTP et avec tu peux tout monitorer, tout administrer.
-
[^]Re: Tomcat : première version stable de la branche 5
-
[^]Re: Tomcat : première version stable de la branche 5
Posté par Pierre Tramonson () le 04/12/2003 à 10:27. (lien). Évalué à 12.http://java.sun.com/products/JavaManagement/(...)
En gros c'est une API qui te dit comment tu peux déployer, gérer et surveiller tes applis J2EE.
Plus d'infos pour les décideurs là : http://www.theserverside.com/resources/article.jsp?l=AdventnetJMX(...)
-
[^]Re: Tomcat : première version stable de la branche 5
Posté par Nicolas Delsaux (page perso, ) le 04/12/2003 à 11:09. (lien). Évalué à 8.Quelques infos : http://www.open-j2ee.org/opencms/opencms/fr/articles/j2ee/j2ee_jmx.(...)
Pour faire ultra-simple, c'est une API de téléadministration apparement compatible avec SNMP
-
-
Re: Tomcat : première version stable de la branche 5
Bonjour,
quelqu'un connait un benchmark comparant les perfs entre cette version et les autres. Afin de savoir sur quoi porte les optimisations (moins de garbage collector etc ...)
merci
-
[^]Re: Tomcat : première version stable de la branche 5
Posté par Pierre Tramonson () le 04/12/2003 à 10:23. (lien). Évalué à 8.Tomcat 5.0.x. Tomcat 5.0 improves on Tomcat 4.1 in many ways, including:
* Performance optimizations and reduced garbage collection
* Refactored application deployer, with an optional standalone deployer allowing validation and compilation of a web application before putting it in production
* Complete server monitoring using JMX and the manager web application
* Scalability and reliability enhancements
* Improved Taglibs handling, including advanced pooling and tag plugins
* Improved platform integration, with native Windows and Unix wrappers
* Embedding of Tomcat using JMX
* Enhanced Security Manager support
* Integrated session clustering
* Expanded documentation
Je ne crois pas avoir vu de comparaison point par point.
Par contre j'ai trouvé ceci http://jakarta.apache.org/tomcat/articles/performance.pdf(...) (doc PDF) qui peut être intéressant, mais j'ai pas encore tout lu.
Précompilation ?
"possibilité de précompiler l'application"
Euh? Une page JSP est dans tous les cas transformée
en une classe java étendant Servlet, puis compilé
pour l'execution.
A ma connaissance c'est toujours précompilé, ou par
tomcat , ou par javac manuellement dans le cas du déploiement
d'un .war, c'est bien des binaires java qui sont manipulés ...
Plus d'infos ? c'est moi qui me trompe ?
-
[^]Re: Précompilation ?
Posté par Roger Rabbit () le 04/12/2003 à 11:34. (lien). Évalué à 4.Autant pour moi,
en fait la description de la feature est la suivante
"Refactored application deployer, with an optional standalone deployer allowing validation and compilation of a web application before putting it in production"
Qui comprend des taches ant, jasper pour la compilation des jsp, un
validateur de descripteur de déploiement. Ensuite on passe à la moulinette
ant et on obtient un .war valide.
Dans la news "possibilité de précompiler l'application" c'est à prendre
dans le sens, "on a une moulinette pour packager des .war",
pas dans le sens "avant on recompilait les jsp à chaque fois".
-
[^]Re: Précompilation ?
Posté par Nicolas Delsaux (page perso, ) le 04/12/2003 à 11:35. (lien). Évalué à 2.Euh? Une page JSP est dans tous les cas transformée
en une classe java étendant Servlet, puis compilé
pour l'execution.
Oui, tout à fait.
A ma connaissance c'est toujours précompilé, ou par
tomcat , ou par javac manuellement dans le cas du déploiement
d'un .war, c'est bien des binaires java qui sont manipulés ...
C'est Tomcat (ou un quelconque serveur de jsp) qui va les compiler. Ce que je comprend de cette phrase, c'est qu'il est possible d'invoquer séparément (par exemple dans un IDE) la classe qui fait cette précompilation pour pouvoir vérifier les erreurs d'écriture qui peuvent se glisser dans la jsp. Et ça, c'est un avantage significatif !
-
[^]Re: Précompilation ?
Posté par Joachim Wolfgang Kaltz () le 04/12/2003 à 11:37. (lien). Évalué à 1.Voila, la JSP est transformee en une servlet puis compilee.
La question est, quand ... soit le serveur fait ca au demarrage, soit a la premiere requete utilisateur pour cette page. Je suis pas sur a quel moment Tomcat 4 le fait.
En tout cas, si tu as beaucoup de pages, longues a compiler, tu peux les compiler avant le deploiement, donc precompiler.
L´avantage c´est que (suivant le serveur) le serveur va demarrer plus rapidement, ou, mieux, si les pages sont d´habitude generees que a la premiere demande, la reponse pour le premier utilisateur sera beaucoup plus rapide que d´habitude.-
[^]Re: Précompilation ?
Posté par Roger Rabbit () le 04/12/2003 à 11:48. (lien). Évalué à 1.Enfin déployer du source c'est goret en production :)
En général tu déploie des war (zip) packagés comme
il faut.
Dans le cas d'un application correctement packagée,
c'est à dire fournie sous forme binaire et pas en source,
ce qui peut influer sur la rapidité de temps de réponse
c'est :
1- Le préchargment des classes ou non
2- Le degré de compilation native atteind pour
cette classe par la jvm ( plus tu appelle la page,
plus ca va vite )
Pour revenir sur la "precompilation" citée dans la news,
j'ai expliqué plus haut ce qu'était cette feature.-
[^]Re: Précompilation ?
Posté par jde () le 04/12/2003 à 13:20. (lien). Évalué à 2.Enfin déployer du source c'est goret en production :)
En général tu déploie des war (zip) packagés comme
il faut.
Avant cette possibilité de précompilation des JSP je ne vois pas comment tu pouvais inclure les binaires de JSP dans un war.
Ou alors ça veut dire que tu fais un war en incluant le "tomcat scratch dir" d'un serveur de test, auquel cas c'est ta méthode qui est celle d'un goret :-) (je dis ça mais en plus ça doit même pas marcher).
-
-
-
[^]Re: Précompilation ?
Posté par Alexandre Touret (page perso, ) le 04/12/2003 à 11:40. (lien). Évalué à 4.En fait le truc c est que les JSP sont par defaut compilees au fur et a mesure.
Pour une petite webapp ce n est pas trop genant, mais en production ca le devient. Scenario typique: tu fais la demo eu client et chaque JSP se compile au fur et a mesure, pour peu que t utilises un framework genre Struts ou JSF ca prendra un peu + de tps. Et la tu auras a coup sur le remarque "Java c est lent!"
De plus, si tu compiles ttes les JSP au deploiement, tu sauras tt de suite si elle st OK ou non et ton application aura des le premier appel un comportement "normal".
Cette fonctionnalite est deja presente sur les serveurs d applications tels que Weblogic ou Websphere Application Server.
Moi qui travaille sur JBOSS - Tomcat je peux te dire ca faisait cruellement defaut.
Tomcat et Squid en reverse-proxy HTTPS
Est-ce que cette nouvelle version souffre toujours du symptôme que j'avais déjà noté avec les anciennes versions ou existe-t-il une méthode "propre" de contourner ce problème:
Admettons que vous ayez un serveur proxy HTTPS en front-end monté en reverse[1]
afin de mutualiser plusieurs serveurs HTTP avec un seul certificat SSL.
En effet, squid est le seul à présenter le certificat à la demande du client,
et il correspondra aux informations publiques du serveur proxy (FQDN/IP).
Il faut savoir que Squid communique alors avec les autres serveurs en HTTP,
et non plus en HTTPS (comme avec le client).
Tout se déroule très bien avec la plupart des serveurs HTTP si ce n'est
l'habitude de Tomcat de renvoyer un Redirect HTTP dès la première requête émise par le client...
Résultat des courses, le client envoie donc une requête HTTPS à squid,
Squid la renvoie au bon serveur HTTP mais en HTTP,
et Tomcat renvoie finalement l'url de Redirect en ...http://...(...)
Du coup, pour peu que l'HTTP ne soit pas autorisé, le client essaie alors de poursuivre en HTTP et non plus HTTPS...
Quelqu'un a-t-il une idée sur le sujet ?
[1]: http://squid.visolve.com/white_papers/reverseproxy.htm#ee(...)
Question bete
Est ce que Tomcat est compatible avec les implémentations libres de Java(tm) ?
-
[^]Re: Question bete
Posté par Roger Rabbit () le 04/12/2003 à 19:45. (lien). Évalué à 5.la question c'est plutot est ce que les implémentations libres respectent les spécification du jdk ;)
la réponse est oui !
les packages de tomcat compilé avec gcj pour RH sont dispo là :
http://people.redhat.com/gbenson/naoko/i386/(...)
[ 3eme résultat google, pas cherché plus loin ]
-
[^]Re: Question bete
Posté par vrm (page perso, ) le 06/12/2003 à 11:29. (lien). Évalué à 2.oui ca fais longtemps que tomcat est en paquet debian
gros trolleur va :)-
[^]Re: Question bete
-
Cette page a été générée par Templeet en 0.1491s (dont 0.0381 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
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.