JOnAS 5.1 M5 : Serveur d'application certifié Java EE 5 !

Posté par  . Modéré par patrick_g.
Étiquettes :
8
18
mar.
2009
Java
Le moment est enfin arrivé d'annoncer la première version certifiée Java EE 5 de JOnAS ! En effet, JOnAS passe désormais avec succès l'intégralité de la suite de tests Java EE 5.

Cette nouvelle version (M5) de JOnAS 5.1 inclut le support complet JAX-WS 2.0 (Service web) et EJB 3.0. La persistance (Java Persistance API 1.0) est fournie par Hibernate (3.4.0 GA) ou EclipseLink (1.0.1). Cette nouvelle version apporte aussi de nombreuses améliorations dans le cœur de JOnAS ainsi que de nombreuses corrections de bugs.

JOnAS est un serveur d'applications construit à base de composants OSGi et s'appuie sur la passerelle Apache Felix. Pour encore améliorer JOnAS, un seul moyen : téléchargez et installez-le (consultez le tutoriel et le guide du débutant), essayez vos applications Java EE et donnez nous autant de retours que possible.

Remarques, questions et commentaires sont les bienvenus et peuvent être postés sur les listes francophones (jonas-fr -at- ow2.org) ou sur les listes anglophones (jonas -at- ow2.org ou jonas-team -at- ow2.org pour les questions plus techniques).

Si vous rencontrez des problèmes lors de votre utilisation de JOnAS, notre gestionnaire de problèmes est là pour vous : OW2 Forge.

Aller plus loin

  • # Passerelle Apache Felix?

    Posté par  . Évalué à 3.

    Drôle de traduction pour un framework OSGi qui n'a rien à voir avec une passerelle :). Mauvaise traduction du G deprecated d'OSGi ? Je crois que la traduction officielle est cadriciel (et celui qui a inventé ce mot devrait être pendu).

    En tout cas, c'est sympa de voir d'autres serveurs JEE basés sur OSGi après Glassfish, dommage qu'OW2 et JOnAS n'aient pas le support marketing et l'image de JBoss.

    Malheureusement cette dépêche va faire un flop ici, car les moules n'aiment pas le monde Java par principe, même quand c'est libre et bien fait. Merde, on n'est pas vendredi.
    • [^] # Commentaire supprimé

      Posté par  . Évalué à 3.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Passerelle Apache Felix?

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

        On a un socle technique basé sur JOnAS et on en est satisfait... mais c'est vrai qu'on réfléchit à passer à autre chose.. pourquoi pas un Jetty (on développe avec Hibernate/Spring/GWT).

        http://about.me/straumat

        • [^] # Re: Passerelle Apache Felix?

          Posté par  . Évalué à 2.

          Un de nos objectifs est aussi de pouvoir fabriquer des serveurs à la demande.
          C'est à dire dans le serveur, il n'ya que ce dont l'application a besoin: une appli web qui envoit des mails ? ne seront installés (et présents en mémoire) que les services nécessaires.
          De plus si les besoins de l'application evoluent (on rajoute des EJBs par exemple), on peut rajouter les services à la volée. Voire meme les enlever si le besoin s'en fait sentir.

          Bref, on optimise la gestion des resources en s'adaptant aux applications.
      • [^] # Re: Passerelle Apache Felix?

        Posté par  . Évalué à 1.

        Je ne suis ni sysadmin ni devin donc je ne risque pas de savoir pourquoi ta JVM se comporte comme ça. A priori elle réserve de la mémoire pour une raison (sans doute d'optimisation), ça se trouve c'est JBoss qui le lui demande. Effectivement, normalement la resident memory est pas remplie à moins que la JVM en ait besoin ou soit lancée avec l'option qui -Xmxn (min memoire résidente allouée).

        En revanche je ne connais pas beaucoup de VM meilleures que HotSpot en terme de performance -- certainement pas celles de Ruby, Python ou Mono. C'est pas pour rien que les optimisation de HotSpot sont réputées, il y a eu un effort impressionnant dessus.

        C'est simple de répondre ça. Je peux te montrer la sortie de ps sur programme C ou C++ qui fait rien de bien utile mais qui bouffe 1GB de mémoire. Tu le dis toi même, c'est peut-être au niveau de la gestion que Linux fait. Il y a sans doute une bonne raison, après à toi de voir si l'effort de la trouver vaut la chandelle, mais ton exemple ne prouve rien d'autre que le fait que vendredi se rapproche.

        Il y a bien plus dans le monde Java que la JVM uniquement. Le confiner aux performances de Java (dont une grande partie relève d'idées reçues suites aux piètres performances des débuts du langage), c'est simplificateur. Je réitère, la 'communauté' de DLFP rejette Java en grande partie par principe.

        Mais bon vu le succès qu'a eu le journal sur Perl et le nombre de fans qui semblent lurker ici, tout s'explique :P.
      • [^] # Re: Passerelle Apache Felix?

        Posté par  . Évalué à 3.

        > un jboss qui vient d'être lancé j'ai 500Mo en mémoire en résident

        Et ?
        Soyons généreux, disons que 500 Mo coûte 100 €. C'est rien du tout par rapport à une solution serveur/midleware. Si JBoss te fait gagner une journée, t'as largement récupérer les 100 €.
        • [^] # Commentaire supprimé

          Posté par  . Évalué à 4.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Passerelle Apache Felix?

            Posté par  . Évalué à -1.

            > J'aime bien utiliser le bon langage et le bon environnement pour faire un projet précis. Je n'ai pas encore rencontré un seul projet qui se fait plus rapidement et/ou plus efficacement avec JBoss et consort.

            Manifestement t'as seulement envis de vomir sur JBoss.
            Je n'utilise pas JBoss, mais tes arguments sont complètement nazes.
        • [^] # Commentaire supprimé

          Posté par  . Évalué à 2.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Re: Passerelle Apache Felix?

            Posté par  . Évalué à 1.

            Par défaut les machines d'aujourd'hui ont 2 Go minimum.
            Assez pour utiliser JBoss par les développeurs.

            > - 150 développeurs qui doivent avoir un upgrade mémoire

            Tu me donner le ratio entre le prix d'une barrette de 2 Go (soyons généreux) et un développeur payé durant 1 an (sans compter le PC, l'écran, le réseau, etc).
            Mais toi tu fais une fixation sur 500 Mo. Ridicule.

            > Cela nécessite de la logistique (et pour ceux qui travaille à l'état : un appel d'offre).

            Si tu achètes en gros, tu auras 4 Go pour 50 €. Beaucoup moins d'un millième du coût d'un développeur sur un an.
            Si 500 Mo est si important que ça, fait la proposition d'utiliser Vim et non Eclipse. Demande aussi à développer en C.
            • [^] # Commentaire supprimé

              Posté par  . Évalué à 4.

              Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Passerelle Apache Felix?

              Posté par  . Évalué à 4.

              tu achetes ta ram à montgallet ? :) Sinon il va falloir me donner l'adresse et le nom de tes fournisseurs. Parce que moi la ram ECC je l'ai pas vraiment à ce prix là pour des i386 et pour des pSeries j'en parle même pas.
        • [^] # Re: Passerelle Apache Felix?

          Posté par  . Évalué à 2.

          C'est bien une mentalité de développeur Java ça ...
          Franchement tu trouves ça normal une consommation mémoire de 500 mo par application ? Moi pas.
          • [^] # Re: Passerelle Apache Felix?

            Posté par  . Évalué à 2.

            Non, tous les développeurs Java ne pensent pas ça...
            En fait, je dois dire que ça me désole quand je vois les goinfres de mémoire que je suis obligé de coder pour certains clients ! Mais tant qu'ils payent, je dois faire profil bas. Ça ne m'empêche pas en revanche de chercher à réduire l'empreinte mémoire et processeur sur les applications où on peut agir sur l'architecture.
            • [^] # Re: Passerelle Apache Felix?

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

              Vu que les serveur d'applications J2EE fournissent une énorme quantité de services (gestion de transactions J2EE, bus de message, ...), la consommation mémoire n'est pas choquante (d'autant plus que cela doit être plus lié au Xmx).

              SI tu savais configurer JBoss ou Jonas, tu saurais que tu peut choisir les composants qui seront lancés et utilisés. Tu peut réduire les 2 serveurs au niveau fonctionnel d'un tomcat ou moins et là forcément ça consomme beaucoup moins. La conso d'un tomcat qui ne fait rien par rapport à un apache 2 + PHP 5 reste comparable.
              • [^] # Re: Passerelle Apache Felix?

                Posté par  . Évalué à 1.

                Je pense que ce message ne m'était pas adressé, mais je vais quand même y répondre ;-)

                Tout d'abord, ce n'est pas au dévelopeur de configurer le serveur d'applications. C'est l'architecte qui doit déterminer les modules nécessaire, et la configuration en est déduite directement par l'équipe d'exploitation. Bien sûr, les dévelopeurs (probablement uniquement les séniors) peuvent être consultés pour afiner l'architecture.

                Sinon, si tu savais configurer JBoss ou JOnAS, je pense que tu aurais également quelques bases en lancement de JVM : Xmx fixe la taille maximale utilisable de mémoire. C'est Xms pour la mémoire au lancement ;-)

                Enfin, on n'a pas besoin d'un serveur J2EE complet pour utiliser beaucoup de mémoire... Sur le projet qui m'exaspère le plus, on tourne sur du Tomcat, mais il y a tellement de couches rajoutées et extrèmement mal codées qu'en pratique la consommation mémoire explose (préchargement systématique d'instances utilisées uniquement en traitement mensuel ou annuel, codage non thread-safe imposant d'instancier systématiquement à chaque utilisation, sérialisation/désérialisation XML pour des messages locaux à l'application, utilisation de DOM pour les flux XML sus-nommés, réutilisation de code par copier/coller...)
          • [^] # Re: Passerelle Apache Felix?

            Posté par  . Évalué à -1.

            500Mo pour un serveur jee complet, c'est pas non plus un truc de ouf, hein.
            c'est sur que si tu compares a lighttpd, ca va faire une difference.

            Sans compter que, comme ca a deja ete souligne, ya tres certainement moyen de jouer sur les -Xms -Xmx et autres parametres de memoire de la jvm.
            C'est juste que ca sera un peu idiot de le faire baisser en prod, c'est un serveur cense tenir un minimum de charge, donc qui va bouffer de la ram quoiqu'il arrive, autant reserver toute la ram au chargement, ca evitera de la demander 10 minutes plus tard, idem pour le reallocation: si t'as deja tout bouffe, plutot que de redemander 50 fois un petit bout de ram, mieux vaut en demander 1 fois un gros bout.

            Et derniere chose, aux dernieres nouvelles, la ram inutilisee ne fructifie pas et ne se reproduit pas non plus. Si elle est dans la machine, c'est pour etre utilisee.
            Donc utilisez la!! Au lieu de la laisser dormir et de fanfaronner qu'il reste 1Go de ram dispo.

            Un systeme qui a *beaucoup* de ram dispo est soit un Os qui gere mal la memoire virtuelle, soit une machine ostensiblement surdimensionne par rapport au besoin.
    • [^] # Re: Passerelle Apache Felix?

      Posté par  . Évalué à 1.

      Quelques questions qui me passent par la tête :

      * Est ce qu'on peut utiliser Eclipse Equinox à la place de Felix comme framework OSGi ? De mémoire, j'ai trouvé Equinox plus pratique que Felix dans mes tous premiers essais d'OSGi.

      * Parmi les offres existantes de serveurs basés sur OSGi, il y a notament Spring DM Server (basé sur Equinox et sur Tomcat, ce n'est pas un serveur JEE-compliant), qui est très interessant quand il s'agit de déployer une application Web packagée en WAR traditionnel, tout en profitant de certaines fonctionnalités d'OSGi comme l'export ou la consommation de services (via l'excellent Spring Dynamic Modules). Est ce que JOnAS sait faire aussi cela ? JOnAS sait il également gérer des packages comme les fichiers "PAR" que propose SpringDM Server (archive qui contient un ensemble de bundles OSGi, qui forment un tout indépendant des autres applications).

      Pour l'instant je travaille principalement avec Equinox et Spring DM Server, mais pourquoi pas utiliser JOnAS si celui me permet plus de choses.
      • [^] # Re: Passerelle Apache Felix?

        Posté par  . Évalué à 2.

        Dans l'ordre:
        * Pour le moment, seul Felix est supporté comme framework OSGi, néanmoins les adhérences à une implémentation particuliere sont extremement limitées et donc le support d'un autre framework est possible relativement simplement.
        * Le support des WAR avec meta-données OSGi est une chose que l'on veut faire. De maniere générale, supporter tous les types d'archives Java EE comme bundles OSGi
        * Pour les PAR, coté JOnAS nous avons des deployment-plan. Ce sont des fichiers XML qui permettent de regrouper des bundles ou modules Java EE afin de les deployer/undeployer ensemble.
        • [^] # Re: Passerelle Apache Felix?

          Posté par  . Évalué à 1.

          * Pour le moment, seul Felix est supporté comme framework OSGi, néanmoins les adhérences à une implémentation particuliere sont extremement limitées et donc le support d'un autre framework est possible relativement simplement.

          Oui alors *simplement*, avec OSGi, je me méfie... ;-)


          * Pour les PAR, coté JOnAS nous avons des deployment-plan. Ce sont des fichiers XML qui permettent de regrouper des bundles ou modules Java EE afin de les deployer/undeployer ensemble.


          Un peu comme les features de ServiceMix donc. A noter que l'avantage du .PAR chez SpringDM Server, c'est que les applications sont sépérés les unes des autres, comme si elles étaient dans des conteneurs OSGi différents. On peut donc potentiellement déployer 2 fois le même bundle, une fois dans chaque application.
          • [^] # Re: Passerelle Apache Felix?

            Posté par  . Évalué à 1.

            Lol, on voit le connaisseur OSGi ;)
            Non sans rire, C'est faisable. j'en veux pour preuve le conteneur EJB3 EasyBeans qui fonctionne à la fois sur Felix et Equinox.

            Les features de service-mix ayant repris le nom des features eclipse :)
            En ce qui concerne les Par, il n'y a pas isolation totale. D'apres la doc, ca tourne toujours avec 1 seul framework, donc pas de possibilité de faire tourner indépendament l'une de l'autre 2 versions IDENTIQUES du meme bundle.
            Par contre c'est tout à fait faisable d'avoir, de maniere colocaliser 2 versions differentes du bundle, si les import/export sont bien gérés, il est possible de bien isoler les applications. Et ca, ce n'est pas le PAR qui t'apporte ca, ce sont tes metaddonnées OSGi. Donc avec nos deployment plan on peut faire pareil: il n'y a qu'a declarer des versions DIFFERENTES de chaque bundle et le tour est joué...
            • [^] # Re: Passerelle Apache Felix?

              Posté par  . Évalué à 1.

              De ce que j'ai lu dans les présentations sur SpringDM Server et dans la documentation http://static.springsource.com/projects/dm-server/1.0.x/prog(...) :

              Furthermore, PARs scope the modules of your application within the dm Server. Scoping provides both a physical and logical application boundary, effectively shielding the internals of your application from other PARs deployed within the dm Server. This means your application doesn't have to worry about clashing with other running applications (e.g., in the OSGi Service Registry).

              J'en ai déduit qu'il y a une isolation totale, mais j'ai peut etre mal compris. Ca mériterai d'etre essayé. En tout cas j'ai essayé un bundle simple .JAR qui essaye d'accéder (Import-Package) à un bundle inclus dans un .PAR, et ce ne marche pas, il lui est effectivement inaccessible.

              En ce qui concerne les bundle/versions, je suis d'accord, c'est à la base du framework OSGi. Ce qui me parait interessant dans l'approche de Spring DM Server, c'est si on a un bundle du genre "datasource provider" générique, et un fragment qui complete ce bundle pour spécifier sa configuration (login / pass par exemple), il est impossible sans la possibilité de bien rendre indépendant deux applications, d'utiliser deux fois ce "datasource provider" avec des configurations (donc des bundle fragments) différentes. (Et par ailleurs, aux derniers nouvelles, Felix ne supporte pas les fragments). Info sur les fragments : http://static.springframework.org/osgi/docs/1.1.0/reference/(...) )
  • # Félicitations !

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

    C'est une très bonne nouvelle pour le projet JOnAS et ses utilisateurs.

    Je travaille en ce moment dans l'administration du canton de Genève. J'ai participé à la mise en place de JOnAS et cela c'est très bien passé. On a une vingtaine d'applications en exploitation dont certaines très critiques.

    Nous allons pouvoir maintenant envisager d'abonner ma bonne vielle branche 4.8.
  • # vs Tomcat

    Posté par  . Évalué à 1.

    Quelle est la différence entre Tomcat et JOnAS si ces deux produits sont comparables ?
    • [^] # Re: vs Tomcat

      Posté par  . Évalué à 2.

      Tomcat est un conteneur de Servlet/JSP, il ne sait donc pas gerer les EJBs par exemple (la specification Java EE est beaucoup plus etendue que seulement l'etage web).
      JOnAS lui est un server Java EE complet, il supporte donc l'ensemble de la stack standard (EJB, Webservices, Resources, Persistence, Application Client Container, ...).
      • [^] # Re: vs Tomcat

        Posté par  . Évalué à 2.

        Donc la différence entre JOnAS et Jboss est ?

        merci de votre aide pour éclaircir ce point.
        • [^] # Re: vs Tomcat

          Posté par  . Évalué à 2.

          La ce sont deja des projets plus comparables: ce sont 2 serveurs d'applications certifiés Java EE 5.
          Les différences viennent des a-cotés: modularité et flexibilité, solution de clustering, console d'administration, facilités de dévelopement sont quelqu'uns des points forts de JOnAS.
          Certains diront aussi que la communauté JOnAS est plus sympathique et réactive, mais je suis biaisé ;)
    • [^] # Re: vs Tomcat

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

      Tomcat est un conteneur web, il permet de faire tourner des servlets et jsp (je fais vite hein, je rentre pas dans les détails...). Concrètement, Tomcat ne fourni par tous les services de la norme JEE. JOnAS lui fournit l'ensemble des services, donc le conteneur web et d'autres services (JMS, JCA...)

      http://about.me/straumat

  • # l'avenir ?

    Posté par  . Évalué à 2.

    La question qu’il faudrait se poser serait plutôt « ce type de serveur n’est-il pas (doucement) en train de disparaitre ». Je serais très curieux de connaitre les organisations qui utilisent > 30% des capacités d’un Jonas par exemple. Jboss (l’entreprise) a bien diversifié son model et effectivement JBoss server n’est maintenant qu’une brique Open source navigant au milieu d’un Jboss portal , Jboss ESB etc..
    L’on pourrait facilement imaginer que de nos jours le couple Tomcat/OSGI suffirait à résoudre l’ensemble des problématiques de 90 % des applications d’entreprises et le delta propre ne devrait pas peser très lourd.
    Pour illustrer cela il suffit de regarder l’approche de SpringSource qui se base sur TOMCAT, OSGI et son container léger (le bien) et ne cherche pas le moins du monde à coller a Java EE (le mal)
    La prochaine décennie sera l’avènement du light et utile ?
    • [^] # Re: l'avenir ?

      Posté par  . Évalué à 2.

      A mon avis (et je suis d'accord avec toi), l'age des serveurs d'applications monolithiques et lourd est en train de se terminer.

      Si l'on prend du recul, JOnAS fait, lui aussi, parti d'un ensemble plus grand: OW2.
      Meme si OW2 n'est pas une entreprise, les projets OW2 peuvent former les pieces d'une plateforme SOA (Portal avec eXo, JBI avec PEtALS, ...)

      La suite est peut-etre plus polemique, entre partisans Spring/Java EE :)

      L'ennui avec une approche SpringSource, c'est l'absence de standard. Ils piochent a droite à gauche ce qui les interresse.
      A y regarder de plus pret, à force de rajouter des trucs dans Spring, on se retrouve avec un serveur d'application complet (transaction, persistence, connexion DB, ...) packagé dans une webapp ! Le tout sans support des standard alors qu'ils existent.

      En quoi Java EE c'est le mal ? Les EJB2 et le XML partout c'est fini ! Si vous suivez les nouvelles specifications Java EE, c'est bien la modularité et la légereté qui s'imposent (EJB3.1 lite, Java EE Web Profile pour n'en citer que deux).

      L'approche JOnAS est la suivante: JOnAS est un socle sur lequel deployer les services techniques dont vos applications ont besoin. Et seulement ceux requis! En bref, si seuls les servlets et un support transactionnel sont necessaire pour vos applications, JOnAS peut etre configuré pour n'installer que le conteneur web (Tomcat) et JOTM. Et la on se rapproche du triplet magique Tomcat/OSGi/Conteneur leger (en meme temps on peut mettre Jetty si on veut)...

Suivre le flux des commentaires

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