Discussion :

[alexismp]

Il etait le premier à implémenter Java EE 5, il me semble même qu'il le faisait avant la validation complète de la spécification.

GlassFish v1 est sorti en même temps que la spécification Java EE 5 en mai 2006.

"GlassFish Community" fait référence aux différents projets Open Source qui gravitent autour de GlassFish:
- Open ESB (implémentation JBI + moteur BPEL) => intégré dans GlassFish v2
- JavaDB (Apache Derby) => intégré dès GlassFish v1
- OpenSSO / OpenFederation (single sign-on, liberty alliance)
- Portal (JSR 168, WSRP, ...)
- OpenDS (annuaire LDAP)
...sans parler des sous-projets de GlassFish lui-même : JAX-WS RI, JSF RI, WSIT, JPA/TopLink, Grizzly, ...

Tous sont des projets sur java.net sauf JavaDB (Apache). (tous les projets sur java.net ne sont pas des projets Sun, loin de là).

[hterrolle]

bonsoir,

J'ai hesité avant de donner mon avis sur glassfish. Cela fait a peut pres 1 mois que j'explore glassfish, L'histoire de comprendre son architecture.

Je suis un partisan de Sun, même si j'aurais preferer des performences de cache memory un peut moins commomatrice mais c'est le prix a payer pour êtrecompatible sur differents OS. L'interpreter a aussi des avantages qui sont la portabilité.

par contre pour l'avenir de glassfish tout va dependre de la capacité a obtenir les sources. Cela fait donc un mois que je debug glassfish est je dois avouer que cote sources, c'est un peu la galere si ont veut sortir de maven.

Je pense que se petit detail peux peser sont poid lors d'une decision. Je pense que beaucoup de client veulent être maitre de leur sources. Cela leur permet d'innover et d'être maitre de leur server. Ce qui peut se comprendre surtout si ont aborde les contrainte de securité.

Pour moi glassfish dans le version EJB3 a fait une grande avancé au niveau du deploiement comme au niveaux des annotations. L'equilibre commence a se faire entre EJB3 et spring/hibernate.

Il semblerait donc sue sun est fait un grand effort de standardisation. Par contre il me semble important de fournir des sources qui conresponde au version de SDK disponible. Le fait d'avoir separer la binary code et les source code ne peut être qu'une erreur de strategie. Puisque cla crée une enorme confusion entre se qui est installe sur la machine est ce qui est disponible sous CVS.

Je trouve que il y a quelques années sun offrait la possibilité des donwloader le SDK avec ou sans les sources. La simple fait d'avoir separer cees deux notions. C'est dire offrir le SDK d'un coté et les sources de l'autre ne peut conduire qu'a une augmentation de la confusion.

Donc un client qui a du mal a matcher sont binary et sont code. Ne peux que reflechir a deux fois avant d'utiliser un outils.

J'avoue que je ne regarde que le coté pratique. Mais c'est aussi se qui reste le plus efficace, pour moi en tout cas.

J'espere que V3 sera un outil mature. C'est a dire un outils ou la notion d'object aura pris le dessus sur la notion de container, Qui reste quand même tres limité même si la securité y est plus facile a gerer.

Je pense pour ma part que les serveur 'application n'en sont qu'a leur balbuciment est que la competition reste grande ouverte.

Generer du HTML c'est pas vraiment sorcier. Offrir une architecture object neuronal (genre toile d'araigner pour ouvrir large) ca fera toute la difference.

Se n'est qu'un avis personel. Je reste quand même javaworld.

[alexismp]

Merci pour ton commentaire Hervé.

Concernant la "séparation" entre binaire et source, il n'y a pas de mystère, l'objectif principal est de limiter la taille du téléchargement. Ensuite il y a tout ce qu'il faut de tags dans ls CVS pour retrouver le code source. En fait dans la démarche Open Source c'est même plutôt une facilité que de fournir les binaires. Tu peux aussi reconstruire à partir des sources.

Je suis d'accord avec ton analyse du marché des serveurs d'applications. Je pense que l'arrivée dans l'open source de plusieurs produits va apporter un souffle nouveau et de nombreuses innovations.

[hterrolle]

Re bonjour,

Je viens de passer un peu plus de deux mois à comprendre et debugger glassfish. Pour ma part, cela reste un beau défi technologique et un mixte d'une grande partie des technologies java ( sécurité, routage, JNDI et tout ce qui gravite autour de la notion de serveur). Par contre c'est une petite usine à gaz, lorsque l'on se penche sur la communication inter-processus (thread).

Les trois étapes de démarage du serveur (à savoir l'initialisation des services, le startup des services et pour finir le onready). Il semblerait que tout ait été fait pour qu'il soit presque impossible de démarrer le serveur en debug. Le fait d'utiliser System.out comme outils de communication entre les différentes instances rende le debug presque impossible. Et du fait il s'avere très difficile pour un client d'être maitre de glassfish, voir de le modifier.

Certe le produit fonctionne si on l'utilise comme un produit fini et que l'on suit bien les instructions. Mais cela n'a plus rien à voir avec la phillosophie SUN c'est à dire fournir des outils de developement. Avec glassfish il n'est plus possible de parler de developement. Puisqu'il n'est plus possible de suivre ni de comprendre ce qui se passe à l'intérieur de glassfish.

Deuxiéme remarque qui me semble intérressant de pointer du doigt. Les package sont tellement différents d'une version à l'autre qu'il me semble que certaines sources ne soient plus valable d'une version à l'autre ce qui rend encore plus difficile de suivre ce qui se passe au niveau du codage.

Je me permet donc de faire quelques propositions afin que glassfish puisse avoir un avenir.

1) Modifier la communication inter thread lors du onstartup et utiliser autre chose que System.out pour la communication entre Thread. Ce qui facilitera le debugging donc la possibilité au client d'être maitre du source. Et lui donner la possibilité d'innover ses propres solutions.

2) Améliorer la documentation concernant le flux de l'information entre threads. Et particulierement le routage des traitements à partir du connect client (requête http) . C'est presque impossible de suivre une requête client.

3) Je pense que SUN a tout à gagner à redéfinir la structure logique de glassfish. Et de définir ce qui est d'un coté (html, Jsp, servlet) et d'un autre ce qui est Application (EJB). Dans le premier cas apache fait très bien l'affaire, ce qui reste innovant est de faire en sorte que la partie client (dans une application client-serveur) puisse s'exécuter sur le serveur.

Donc pour poursuivre mes posts précédents. Il me semble que celui qui emportera le marché des serveurs d'application devra être en mesure de fournir une transparence sur le code (fournir le code), permettre une comprehension logique des rouages du serveur (doc sur l'algorythme du traitement d'une requête http) et pour finir sufissament de souplesse afin qu'un client utilisant d'autres outils puisse les utiliser sans devoir réécrire son code.

Pour la derniere remarque. Donner aux clients la possibilité d'utiliser de nouveaux outils déjà intégrés (EJB3 et un bon exemple de la volonté de glassfish d'être flexible (annotaion et injection).

En fait plutot de bâtir sur des bases J2EE. Il serait bon que la communauté glassfish n'hésite pas à tout revoir de A à Z. Afin de fournir un outil pro et non pas une sorte de server baroque entre apache,J2EE, Spring, Hibernate.

M'enfin je dois avouer que la sécurité et vraiment au top. C'est d'ailleurs là que le bas blesse. Puisque cela impose un mode de fonctionnement fixe. D'où la difficulté de passer à une organisation flexible de la communication entre container. Sinon de rajouter encore une couche de communication entre les threads gérant les containers.

[alexismp]

Bonjour,

GlassFish v3 est un travail en cours pour rendre l'architecture de beaucoup plus modulaire et pour gagner en performance au passage. Coté documentation, regardes là: http://modsys.dev.java.net
http://wiki.glassfish.java.net/gfwik...ForGlassFishV3

Une video des débuts de GFv3 est dispo ici:
http://blogs.sun.com/dochez/entry/fi...v3_screencast1

[lesne]

Il ne faut oublier l'essentiel: Le développeur ne joue pas au légo. Il a autre chose à faire !!

Glassfish répond aussi à une simplification du packaging de la plate-forme JEE. Je suis OCA sur Oracle App Server, et là y'a pas photo. C'est simple à installer, complet, avec une console d'admin digne de ce nom. Je parle de Glassfish...

Alors vive Glassfish pour sa simplificité !

Au fait, serait-il possible de faire un reloading plus réactif comme JBoss ou Tomcat ?? Merci pour toutes ces minutes gagnées.

[alexismp]

Merci pour les compliments sur GlassFish.
A priori le redéploiement incrémental est excellent avec des web applications (WAR). La partie EAR n'est pas encore aussi rapide. A noter qu'il existe aussi le déploiement à partir d'arborescence de répertoires.

[lesne]

C'est ce que j'utilise ;-) le déploiement à plat avec Eclipse...

Serait-il possible de désactiver certaines fonctionnalités depuis la console d'admin ?

[alexismp]

ca dépend des fonctionnalités...
C'est pour éviter que les administrateurs se "tirent une balle dans le pied"?

[lesne]

Non, ce serait plutot pour les développeurs.
Projet sans JBI, WS, etc. L'objectif serait plutot de définir un environnement à la carte (j'active ou pas selon le projet). En cela accélèrerait le chargement en mémoire sur le poste du développeur !!

[alexismp]

Il n'y a malheureusement pas de moyen simple de supprimer le support JBI.
Essaye:
1. Suppression du JBI lifecycle module dans domain.xml
2. mv glassfish/jbi/lib/jbi-admin-common.jar vers glassfish/lib
3. mv glassfish/jbi/lib/xbean.jar vers glassfish/lib
4. rm -rf glassfish/jbi

A priori tout accès à JBI depuis asadmin, asant, et autre netbeans ne fonctionnera alors plus (avec un message d'erreur plus ou moins joli).

Ceci dit, il y a déjà un chargement à la volée des services et le temps de démarrage et l'empreinte mémoire sont déjà relativement optimisés.

Tout ceci sera corrigé/amélioré dans la v3 (beaucoup plu modulaire).

[alexismp]

Bon, il est peut-être temps de relancer un peu le débat avec la sortie de GlassFish v2

Ce qui a changé depuis cette discussion:
- double licence CDDL + GPLv2 (intégration dans les distribs Linux facilitée et en cours de discussion)
- performances SPEC #1 devant BEA Weblogic
- clustering complet intégré dans GF (pas un rajout, pas un autre produit)
- temps de démarrage amélioré (mieux que Tomcat?)
- Web Services Metro finalisé et près pour la prod.

Coté arguments pour décideurs:
- open source : pas mal d'études en cours pour trouver une alternative (pas nécessairement un remplaçant) à WebSphere ou WebLogic
- 2ème génération de produit Java EE 5. Certains n'y sont toujours pas. Suivez mon regard...
- Clustering et le monitoring complètement intégrés. Un décideur est près à changer pourvu qu'il n'y perde pas en fonctionnalités
- si on ramène le résultat de benchmark à un rapport perf/€, ça commence vraiment à parler à un décideur.
- interopérabilité .Net avec WSIT (passé une certaine taille, toute entreprise possède du java et du .net).
- Pricing de glassfish, à la fois pour le modèle de business clairement Open Source indexé sur du service et pour les coûts particulièrement raisonnables.

Chacun ses mesures, mais en comparaison à Geronimo, Google Trends est intéressant (je n'arrive pas à faire apparaitre OW2 JOnAS). Et puis difficile de rester insensible aux propos de Marc Fleury sur GlassFish...

Avec tout ça, je pense que GlassFish a fait des progrès sensibles mais il reste fatalement de nombreuses améliorations souhaitables. Selon vous, lesquelles?

[mickael.guilbert]

Et depuis le rachat SUN par Oracle qui a deja son middle war ?

[hasalex]

Et depuis le rachat SUN par Oracle qui a deja son middle war ?

Ses middlewares, plutôt :
- Oracle AS (avec OC4J)
- Weblogic

[zorm]

Bonjour,

Pour apporter un élément de réponse à ta question mickael.guilbert, il faut comprendre que le rachat de Sun par Oracle peut avoir sur le temps (car c'est jamais immédiat sur d'aussi gros marchés) des impactes sur les projets qui ont été initié mais cela dépendra surtout de la stratégie qui sera proposée.
C'est sur que ce n'est pas GlassFish et la part de marché qu'il dégage qui a motivé le souhait d'oracle de devenir actionnaire majoritaire de sun. Mais ce n'est pas pour autant qu'ils vont décider de stopper ce genre de projet. Cela leur permet aussi d'étendre leur portefeuille de service et ainsi de récupérer à leur compte les utilisateurs. Un arret de l'évolution de ces projets fera à termes partir les utilisateurs et ceux ci ne choisiront pas nécessairement les solutions Oracle.
Bref, tout ça pour dire qu'actuellement, on a pas assez de visibilité sur les stratégies qui seront engagées. Si on lit les communiqués de presse, on nous dit que tout est beau et tout sera super "This is a fantastic day for Sun's customers, developers, partners and employees across the globe" (on n'en doute pas) mais il est probable aussi que la priorité qu'avait mis Sun sur les développements avenirs de ses projets changent dans le temps.

[alexismp]

Roadmap pour GlassFish annoncée ce jeudi, 20h00 (heure française) :
http://blogs.sun.com/theaquarium/ent...ssfish_roadmap

-Alexis

[Ricky81]

Voici donc quelques extraits de la roadmap GlassFish v3.1 à v4 annoncée il y a quelques heures :
poursuite du projet Open Source, avec transparence et ouverture (GlassFish Server Open Source Edition)
intégration avec Oracle Fusion Middleware
version et documentation commerciale Oracle à venir (Oracle GlassFish Server) comprenant des addons closed source

En ce qui concerne les futures versions :

• GlassFish 2.1.2, 3.01 pour 2010
• GlassFish 3.1 pour 2010 : Haute dispo et réplication d'état, administration centralisé de clusters, support d'Oracle Coherence
• GlassFish 3.2 pour 2011 : amélioration de l'administration de clusters en haute dispo, meilleure intégration avec Oracle Identity Management, compatibilité avec la virtualisation, mise à niveau Java EE 6 et début de support Java EE 7
• GlassFish 4 pour 2012 : Java EE 7 et synergies avec WebLogic

Qu'en pensez-vous ?

Consulter la roadmap en détail (PDF 3Mo)
Pour ceux qui préfèrent le français : la présentation (son + slides) en français par Alexis.

[saad.hessane]

Bonjour,
Est-ce qu'aujourd'hui cela vaut la peine de passer à Glassfish? Selon ce que j'ai lu il est le seul à être aujourd'hui compatible EE6 et il serait plus rapide.
Serait il réservé au projet de grandes envergures avec EJB, ou il serait bien de l'utiliser aussi en remplacement de Tomcat?

[hasalex]

Ça fait quelques mois que je trimballe mes doutes sur l'avenir de Glassfish et je dois dire que je commence à regarder les choses différemment. C'est vrai que l'équipe GF et Oracle font de gros efforts pour nous rassurer et quand Oracle fait ce genre d'effort, c'est qu'ils envisagent un retour sur investissement. Je crois qu'il faut mettre en veille un scepticisme qui n'apporte rien et accorder un minimum de confiance à Oracle sur ses actes futurs pour GF et Java en général. Il est clair que le modèle économique autour de ces produits est très différent de leur modèle historique, mais Oracle a déjà évolué dans un passé récent et évoluera encore. L'opposition de la communauté ne peut pas être constructif dans ce contexte.

A titre personnel, je vais donc recommencer à travailler avec GF, à le proposer comme solution probablement pérenne à mes clients et à l'inclure dans mon offre de prestations.

Pour répondre plus précisément à ilys05, oui GF est le seul (avec Tmaxsoft) à implémenter complètement JavaEE 6. Quant à le prendre en remplacement de Tomcat, je te laisse évaluer les aspects pratiques. Tomcat garde encore l'avantage d'une grande simplicité, et son remplaçant, si tu en cherches un, serait plutôt Jetty. Pour rebondir aussi sur ta question, si tu veux utiliser JavaEE 6, associer les termes "grande envergure" et "EJB" n'est plus aussi pertinent que par le passé. Le modèle de développement a bien évolué et EJB 3.1 + JPA + CDI constitue un ensemble très intéressant, le tout dans Netbeans qui, lui aussi, a un temps d'avance sur la concurrence.

Ceux qui me connaissent un peu doivent sourire à mes propos, moi qui ne jurais que par Eclipse + JBoss ou Tomcat, il y a un an seulement. Pour les rassurer, je dirais que je n'ai pas changé de bord, je me suis juste ouvert à d'autres possibilités.

[nicorama]

J'ai utilisé Glassfish pendant deux ans et j'en suis très content.

Comme tous les produits Sun, il est très bien documenté, ce qui est bien plus important à mon sens qu'une communauté active qui documente avec des moufles - non, je ne parle pas des plugins JBOSS pour Ecplise .

Bref, pour les versions 2.1 et 3.0, je n'ai jamais eu de soucis avec Netbeans, si en le deployant sous Ubuntu. Pas testé sous Eclipse.

Quant à l'âge du capitaine, il a bien 4-5 ans, plus l'expérience Sun Application Server, ce qui est bien suffisant.