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

Posté par (page perso) . Modéré par patrick_g.
Tags :
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.
  • # 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.
    • [^] # Re: Passerelle Apache Felix?

      Posté par (page perso) . Évalué à 3.

      >car les moules n'aiment pas le monde Java par principe

      Et surtout pleins de raisons très raisonnable... J'étais d'ailleurs entrain de me pencher sur le problème de consomation de mémoire (pour des jboss) :


      # ps -e -o vsz,rss,osz,pmem,args | egrep 'java|VSZ' | sort -n -k 1
      VSZ RSS SZ COMMAND
      [...]
      762336 487648 95292 /bin/java -server
      762968 480944 95371
      770072 442240 96259
      832136 501248 104017
      927768 502104 115971
      965752 710624 120719 /bin/java -server
      [...]


      Je me demande vraiment pourquoi il n'y a pas plus de trucs en mémoire virtuelle (et de partagés entre les différentes instances jboss) sur le disque et pourquoi dans un jboss qui vient d'être lancé j'ai 500Mo en mémoire en résident (rien ne s'exécute dessus, rien de déployé).

      Je pense que le problème vient du fait que le noyau de l'os ne considère pas le code java comme du code mais des data. J'ai l'impression que la VM charge tout en mémoire. Donc, utilisation de librairie ou pas tout est en mémoire.

      Il parait que c'est pour notre bien pour optimiser le système. J'ai comme un doute...
      • [^] # Re: Passerelle Apache Felix?

        Posté par (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 3.

          >u le dis toi même, c'est peut-être au niveau de la gestion que Linux fait.

          Je n'ai jamais dit que c'est linux (surtout que le ps vient d'un solaris) le problème tout au contraire.

          >mais ton exemple ne prouve rien d'autre que le fait que vendredi se rapproche.

          Si 30 jboss qui bouffent 40Go de ram sur un serveur, avant de faire quoique ce soit d'utile, n'est pas un problème pour toi, je pense que tu as besoin d'enlever la poutrelle de ton oeil.

          Normalement, un paquet de trucs doivent être partagés en mémoire (les segments de code, par exemple, dans les programmes car entre 30 jboss seules les données changent) mais ce n'est pas le cas sous windows, solaris ou encore linux. Donc, l'os est hors de cause...

          >Je réitère, la 'communauté' de DLFP rejette Java en grande partie par principe.

          Java possède beaucoup de problèmes. Je t'en ai cité un (lié à jboss qui est une des implémentation de jee). Mais apparement, tu le rejettes uniquement sur des a priori sur les gens utilisant linux.

          C'est triste ton point de vue sur les DLFPien !
      • [^] # 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 €.
        • [^] # Re: Passerelle Apache Felix?

          Posté par (page perso) . Évalué à 4.

          >Soyons généreux, disons que 500 Mo coûte 100 €.

          Quand tu dois faire tourner 30Jboss sur une machine (supportant >40Go de ram) cela te coute beaucoup, beaucoup, beaucoup plus cher... Le faire sur des serveurs différents dédiés n'est pas une solution car cela te coute plus en infrastructure d'accueil (locaux, rack, ...) et en électricité.

          J'ai également, pu constater, que plus un logiciel est gros, plus les chances d'avoir des problèmes de stabilité, maintenabilité et de disponibilité. http://blog.amber.org/2006/06/13/complexity-is-not-abstracti(...) http://ptrthomas.wordpress.com/2006/06/06/java-call-stack-fr(...)

          >Si JBoss te fait gagner une journée, t'as largement récupérer les 100 €.

          Jusqu'à présent cela m'en a fait surtout perdre beaucoup de journées... et apparement, je ne suis pas le seul dans le cas ici (>150 développeurs).

          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.
          • [^] # 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.
        • [^] # Re: Passerelle Apache Felix?

          Posté par (page perso) . Évalué à 2.

          >Soyons généreux, disons que 500 Mo coûte 100 €.

          Pour compléter, ce n'est pas très généreux car il faut penser qu'il y a :
          - 4 environnements (Dev, intégration, acceptance, Production)
          - 150 développeurs qui doivent avoir un upgrade mémoire

          Cela nécessite de la logistique (et pour ceux qui travaille à l'état : un appel d'offre).
          • [^] # 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.
            • [^] # Re: Passerelle Apache Felix?

              Posté par (page perso) . Évalué à 4.

              >Si tu achètes en gros, tu auras 4 Go pour 50 €.

              Tu as juste loupé plusieurs détails pour ce qui pour ma part, mon cas :
              >(et pour ceux qui travaille à l'état : un appel d'offre).

              Un appel d'offre cela dure longtemps et nécessite beaucoup de personnel.

              >Par défaut les machines d'aujourd'hui ont 2 Go minimum.

              Pas chez les fonctionnaires... Le parc ne date pas nécessairement de cette année, certaine (beaucoup) machine ont de 3 à 6 ans.

              Un développeur Java fait tourner JBoss, eclipse, programme de modélisation, programme de test, et pleins d'autre en simultané.

              Le vrai problème c'est quand je fait tourner 10 apache ou 100 apache la mémoire utilisée n'augmente pas linéairement. 10 ou 100 apache ce n'est pas 10x plus de mémoire utilisée mais quasi rien en plus. Pour JBoss 10 instances ou 100 cela fait un facteur 10. Cela pose des problèmes constants de redimensionnement.
            • [^] # 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 (page perso) . Évalué à 2.

                bin euh 12000 euros les 16 Go c'est donné non ? c'est un upgrade hein, t'avais qu'à bien dimensionner ton serveur au départ :D
        • [^] # Re: Passerelle Apache Felix?

          Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.