il va encore falloir attendre pour avoir droit a jax-rs (qui est pourtant je pense une des plus brillantes api sortie coté web dans le monde java), et abandonner JEE pour faire par exemple du pur site web.

dommage, il aura fallu la pression de spring pour faire evoluer toute la partie EJB, qui saura faire avancer correctement la zone web ?

Et le mot pour rire : en 2010, vu que java mail n’est pas integré au profil web : il ne sera toujours pas possible de faire un mail sans ajouter des libs au serveur. (et je parle meme pas de la tete de l’api javamail). Je pense que si la communauté java voulait pousser les developpeurs web vers rails/django/grails elle ne pourrait pas faire beaucoup mieux.

> Promis juré, j’écrirai une série de post sur @Inject/CDI

Une démo @Inject implemented by Google Guice qui intègre un composant CDIsé ?

> « nourrissent un espoir d’évolution de JSP », là je crois que c’est mort ;o)

Merci pour la mauvaise nouvelle . Tant pis pour moi, je jouerai Freemarker en espérant qu’ils s’améliorent un peu plus encore en s’inspirant de Google Sitebricks.

@Alexis,

> la majorité des WebSphere dans la nature sont encore déployés sur un JVM Sun

WebSphere ou Weblogic ? IBM impose la JVM lors de l’installation de WebSphere (en particulier pour l’ORB) et j’ai même découvert un IBM SDK for Solaris, il n’y a que pour HP-UX qu’IBM annonce utiliser un JDK non-IBM : HP JDK for J2SE HP-UX 11i platform, adapted by IBM for IBM Software, Version 6.0.

En revanche, je serais curieux de connaître la proportion de serveurs Weblogic déployés en production avec Sun HotSpot .

> SpringSource a toujours prôné l’intégration vis-à-vis de plein d’implémentations tierces à commencer par JTA. Se sont-ils trompés en se positionnant sur le créneau des serveurs d’applications?

Il faudrait demander à VMWare étant donné le prix qu’ils ont payé SpringSource .

C’est vrai que SpringFramework a toujours revendiqué de reposer sur les implémentations des serveurs java sur lesquels il s’exécutait. C’était une autre époque, SpringFramework revendiquait de ne pas être intrusif dans le code, un grand éditeur de serveur J2EE ne pouvait s’empêcher de traiter Spring de « boite vide », …

Il y avait quand même quelques ombres à l’intégration transparente de SpringFramework dans les serveurs J2EE. L’intégration au Transaction Manager de WebSphere a été problématique jusqu’en Juin 2007 (Rod Johnson : Spring Framework Certified on WebSphere) !

Pour revenir sur le positionnement de SpringSource sur les serveurs Java léger, je suis plein d’espoirs :
* La plupart de nos applications java-web se contentent très bien d’un moteur de servlet
* Les utilisateurs recherchent aujourd’hui des serveurs Java légers, c’est notamment le positionnement de Glassfish v3
* J’ai envie que « Java Platform as a Service » devienne une réalité, j’en avais parlé dans Pourquoi VMWare / SpringSource ? Virtualisation matérielle vs. Cloud et un certain « Axel R » avait alors dit « il manque vraiment un OS et une JVM »

En ce qui concerne Spring DM Server et le Blue Print OSGi, malgré les prophéties que j’entends depuis des années à propos de la déferlante d’OSGi dans les applications JavaEE, je suis encore dubitatif. Peut-être en 2012 si ce n’est pas la fin du monde .

Désolé d’avoir été bavard.

Cyrille (Xebia)

Dans un app server, la question « CDI ou @Inject? » n’a pas de sens étant donné l’absence de sémantique de @Inject. C’est CDI qui « qualifie » @Inject.

« Committer pour être crédible »: je pense que la majorité des WebSphere dans la nature sont encore déployés sur un JVM Sun… SpringSource a toujours prôné l’intégration vis-à-vis de plein d’implémentations tierces à commencer par JTA. Se sont-ils trompés en se positionnant sur le créneau des serveurs d’applications?

JSF: je comprends que tout le monde ne veuille pas en faire (même avec la v2), mais le rôle de la plate-forme Java EE (complète ou profil Web) est de fournir des solutions dans tous les domaines, framework MVC y compris. Pour les autres (au risque de faire une redite) il y l’extensibilité de la plate-forme. Au passage, la présentation de Roberto à Devoxx (session, pas keynote) parle de manière avancée des différentes solution d’extensibilité, pas seulement des fragments servlet 3.0.

Pour la division qu’apportent CDI et @Inject, Antonio dit lui même qu’ils ont fait « beaucoup (trop) de bruit« . Web Beans a du au dernier moment être complètement revu car c’était, aux yeux de certains comme IBM, un modèle de composants concurrent des EJB. @Inject n’a-t-elle pas été souvent perçue comme « sortie à la dernière minute pour mettre des bâtons dans les roues de Web Beans / CDI » ?

Que dois-je utiliser aujourd’hui sur un nouveau projet ? CDI ou @Inject ? Que se passe-t-il si je choisis pour mon projet @Inject alors que j’intègre un composant qui a choisi CDI ? La coexistence @Inject < -> CDI a-t-elle été spécifiée ?

Comme les spécifications de CDI intègrent l’ensemble des API d’@Inject (annotations et interfaces), j’imagine que l’on peut intégrer des composants @Inject dans un projet qui repose sur CDI. En revanche, qu’en est-il de l’inverse ? Je ne trouve rien dans les spécifications, pour le moins laconiques, d’@Inject.

@Antonio et @Alexis

Je ne remets pas en cause les collaborations entre « grands éditeurs » sur des briques de base comme JPA, Validation ou encore JAX-WS.
Mon point est sur la difficulté de monter en puissance sur des technologies complexes comme JSF et d’être pertinent à offrir du support sur un framework sur lequel on n’est pas committer.
Qui n’a pas entendu un jour « il leur manque une JVM pour être crédible sur le middleware » ou « nous on est pertinent sur ce framework, on a été committer très actif dessus »

@Alexis,

« JSF … est aligné avec le reste de la plate-forme ».
Devrais-je me sentir en marge de la plateforme si je suis plus à l’aise avec un framework web orienté action ?
Pour ceux qui nourrissaient un espoir d’évolution de JSP, Rémi Maucherat nous l’avait déjà dit au Paris JUG, il n’y a qu’a passer à JSF 2 qui s’éloigne de JSP pour proposer son propre templating hérité de Facelets. Et si je n’utilise pas JSF 2 …

Cyrille (Xebia)

Je pense justement le contraire. Hormis le cas CDI et @Inject qui a fait, il est vrai, beaucoup (trop) de bruit, Java EE n’a jamais été aussi soudé. Tu donnes l’exemple de Mojarra (de Sun) qui est utilisé par JBoss. Il y a aussi EclipseLink (Eclipse) qui est utilisé par GlassFish (Sun). CDI et Bean Validation de JBoss utilisé par Sun…

Java EE 6, c’est la spécification de « Bugs bunny et tous ses amis » (j’ai pas trouvé un slogan aussi marquant chez les Bisounours)

Le ticket d’entrée du profil web est quand même bien plus bas qu’auparavant ou EJB CMP, JAX-R, et autres JAX-RPC étaient requis. Je pense que des trois cités, c’est largement à la portée de SpringSource et Caucho (jetty pas sûr qu’ils soient intéressés, mais Intalio va peut-être changer la donne).

Coté JSF, le débat entre MVC orienté composant ou action n’est pas clos effectivement et c’est là que l’extensibilité joue son rôle. JSF est un choix par défaut dont on sait qu’il est aligné avec le reste de la plate-forme. Pour ce qui est de l’implémentation, il en existe 2 et elles sont open source. Il existe plusieurs façons de se donner les moyens de supporter une brique qu’on n’a pas développer soi-même from scratch. Pas de pb pour GlassFish qui embarque Toplink depuis des années ou Weblogic qui fait du Metro.

CDI, @Inject: il faut que tu en dises plus sur la division!

J’ai manqué de clarté dans mes propos, j’espérais aussi un profil léger et consensuel qui satisferait les besoins de 95 % des applications java-web que nous développons et qui serait raisonnablement facile à satisfaire par atteindre de nouveaux entrants.

JTA est quasiment à l’opposé : c’est utilisé par très peu de projets mais très difficile à maîtriser pour un éditeur.
Pour mémoire, JBoss a du attendre le rachat d’Arjnua et JBoss AS 4.2 (mi 2007) pour proposer un moniteur JTA « production ready » pour reprendre les mots de Bill Burke.
Concernant les nouveaux entrants potentiels sur le marché des moteurs de servlet certifiés, j’en vois peu qui soient en mesure de proposer un moteur JTA « production ready » :
* SpringSource (Tomcat) n’a pas pour le moment de moniteur transactionnel,
* Webtide/Intalio (Jetty) embarque la version OpenSource de l’assez discret moniteur JTA Atomikos sans expliquer comment ils savent supporter cette technologie (le support Atomikos commercial coûte 3200 eruo /CPU/an),
* Caucho (Resin) annonce le support de XA mais je n’ai pas trouvé de documentation sur leur site.

Dans la même rubrique « loin d’être utilisé par 95% des application java-web mais compliqué à maîtriser », il y a JSF 2.
Les implémentation JSF 2 sont très rares. Même JBoss qui pourtant investit beaucoup dans JSF utilise l’implémentation de Glassfish/Sun. Quel nouvel entrant voudra/pourra supporter ses clients sur JSF 2 et apporter une solution plutôt que de répondre « c’est un problème dans l’implémentation de Glassfish/Sun, veuillez attendre qu’ils corrigent » ?
Sans oublier le manque de consensus à prendre JSF alors que les débats restent passionnels autour de JSF vs. Wicket vs. Tapestry vs. Spring MVC vs. Struts vs. Stripes vs. …
Comme l’a rappelé Alexis, il est trivial d’intégrer dans une web app ou un middleware un framework comme JSF ou JAX-RS.

Enfin, JCDI et @Inject, c’état probablement inévitable de les intégrer. Leur présence me rappelle juste que le vent de la division souffle sur Java EE 6.

Cyrille (Xebia)

Le moniteur de transactions distribuées nécessaire à JTA laisse un gouffre entre le Web Profile et Tomcat ou Jetty .

Ensuite, l’intégration dans le Web Profile de « JSF 2″, « JSR 299 – Web Beans » et « JSR 330 – Dependency Injection for Java » plutôt, par exemple, que de JAX-RS me laisse un arrière goût politique qui nuira à la diffusion du JavaEE Web Profile.

Cyrille (Xebia)

Une information que je trouve très intéressante, est l’arrivée de nouveaux acteurs dans le cercle (trop) fermé des serveurs d’applications. Grâce au profile web, les éditeurs peuvent n’implémenter qu’un sous ensemble des APIs. Entre WebSpehere et Tomcat, il y avait un gouffre à combler. Le premier à tirer son épingle du jeu est Resin (de Caucho). Resin 4.x implémentera le profil web… à suivre.

http://www.caucho.com/