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
- JOnAS OpenSource Java EE Application Server (55 clics)
- Télécharger JOnAS 5.1 M5 (35 clics)
- Liste détaillée des nouveautés de la version 5.1 M5 (10 clics)
- Description de Java EE (22 clics)
- Description d'OSGi (26 clics)
# Passerelle Apache Felix?
Posté par smc . Évalué à 3.
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 Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Passerelle Apache Felix?
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Passerelle Apache Felix?
Posté par Guillaume Sauthier . Évalué à 2.
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 smc . Évalué à 1.
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.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Passerelle Apache Felix?
Posté par IsNotGood . Évalué à 3.
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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Passerelle Apache Felix?
Posté par IsNotGood . Évalué à -1.
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 Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Passerelle Apache Felix?
Posté par IsNotGood . Évalué à 1.
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 Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Passerelle Apache Felix?
Posté par oau . Évalué à 4.
[^] # Re: Passerelle Apache Felix?
Posté par BAud (site web personnel) . Évalué à 2.
[^] # Re: Passerelle Apache Felix?
Posté par Julien . Évalué à 2.
Franchement tu trouves ça normal une consommation mémoire de 500 mo par application ? Moi pas.
[^] # Re: Passerelle Apache Felix?
Posté par François B. . Évalué à 2.
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 Sylvain AVRIL (site web personnel) . Évalué à 0.
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 François B. . Évalué à 1.
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 thedude . Évalué à -1.
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 icyfemur . Évalué à 1.
* 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 Guillaume Sauthier . Évalué à 2.
* 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 icyfemur . Évalué à 1.
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 Guillaume Sauthier . Évalué à 1.
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 icyfemur . Évalué à 1.
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/(...) )
[^] # Re: Passerelle Apache Felix?
Posté par Guillaume Sauthier . Évalué à 1.
C'est possible que le par modifie les bundles qu'il contient en rajoutant des metadonnées qui vont empecher d'autres bundles d'utiliser les packages.
Pour le coup du "datasource provider" generic, c'est une facon de faire. Une autre serait d'avoir une ManagedServiceFactory (http://www.osgi.org/javadoc/r4/org/osgi/service/cm/ManagedSe(...) par type de Datasource (MySQL, Oracle, ...) et d'utiliser ConfigAdmin (http://www.dynamicjava.org/articles/osgi-compendium/configur(...) pour creer les DataSources. Ca a l'avantage d'etre du pur service OSGi et aussi de marcher sur les plateformes ou les fragments sont pas supportés :)
D'ailleurs, dans Felix, le support des fragments est partiel, pas inexistant.
# Félicitations !
Posté par Xavier MOGHRABI (site web personnel) . Évalué à 2.
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 Matthieu . Évalué à 1.
[^] # Re: vs Tomcat
Posté par Guillaume Sauthier . Évalué à 2.
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 oau . Évalué à 2.
merci de votre aide pour éclaircir ce point.
[^] # Re: vs Tomcat
Posté par Guillaume Sauthier . Évalué à 2.
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 Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
# l'avenir ?
Posté par zlnix . Évalué à 2.
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 Guillaume Sauthier . Évalué à 2.
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.