Tomcat : première version stable de la branche 5

Posté par  . Modéré par Nÿco.
Étiquettes :
0
4
déc.
2003
Java
Tomcat a annoncé cette nuit la première version stable de la branche 5.0 : la 5.0.16 a été déclarée stable.

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.

Aller plus loin

  • # Re: Tomcat : première version stable de la branche 5

    Posté par  (site web personnel) . Évalué à -1.

    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

    • [^] # Re: Tomcat : première version stable de la branche 5

      Posté par  (site web personnel) . É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  (site web personnel) . Évalué à 4.

    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 ?

    http://about.me/straumat

  • # Re: Tomcat : première version stable de la branche 5

    Posté par  . Évalué à 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  . É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 ?

    Posté par  . Évalué à 3.

    "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  . É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  (site web personnel) . É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  . É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  . É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  . É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  . É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

    Posté par  (site web personnel) . Évalué à 1.

    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

    Posté par  . Évalué à 3.

    Est ce que Tomcat est compatible avec les implémentations libres de Java(tm) ?

    • [^] # Re: Question bete

      Posté par  . É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  (site web personnel) . Évalué à 2.

      oui ca fais longtemps que tomcat est en paquet debian


      gros trolleur va :)

      • [^] # Re: Question bete

        Posté par  . Évalué à 2.

        Au fait, vous connaissez un paquet debian du tomcat 5?
        A priori non hacké svp (pataper pataper c'est que d'lhumour!)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.