Discussion :

[Hikage]

Avec l'arrivée de JEE 6 et de Spring 3.0, le développement Entreprise est de plus en plus facile.

De son coté, Spring est largement utilisé à l'heure actuelle. Cependant, celui-ci n'étant pas un standard, il est fort décrié et nous lie fortement avec SpringSource.
Pa contre, un simple conteneur de servlet, comme Tomcat 6, suffit pour tirer partie de ses fonctionnalités.


JEE 6 de son coté apporte une nouvelle jeunesse à JEE en tirant de l'expérience de framework comme Spring ou encore Hibernate et en le standardisant.
La seule chose qui risque de freiner un peu son adoption est l'obligation d'un serveur JEE compatible, ce qui impose des couts de migration de serveur.

D'où ce sondage, afin de voir à l'heure actuelle, quel infrastructure est la plus utilisée : Conteneur de Servlet ou JEE ?

[fr1man]

De mon côté c'est plutôt, serveur d'application + JEE + Spring.
On prend ce qui nous intéresse de part et d'autre.

[aragon]

Hello,

De mon côté c'est plutôt Weblogic 9.2 et 10.3 avec Spring 2.5.6.

A plus,

[Mickael Baron]

Salut,

J'ai voté autre ... puisque dans notre cas pour des prototypes de recherche, nous recherchons la simplicité. Pour l'instant j'ai opté pour Tomcat + OpenEJB.

Mickael

[joseph_p]

Y a pas que spring et les EJB tou diou

Hum, tout ça pour dire qu'ici c'est plutot Guice + caucho resin. Et ça nous convient à merveille

[Hikage]

Y a pas que spring et les EJB tou diou

Hum, tout ça pour dire qu'ici c'est plutot Guice + caucho resin. Et ça nous convient à merveille

Je suis d'accord, il y a bien sur des alternatives.

Le but ici est d'avoir une idée sur la part du marché pouvant potentiellement utilisé Spring 3.0 dès aujourd'hui, et cela sans migrer de serveur.

[Shinzul]

En général j'ai plutot travaillé avec un conteneur de servlet couplet avec Spring. Ma boite se refusait à faire migrer vers des serveurs d'applications pour les nouveaux projets.

[hhfr]

Tant qu'a attaquer un nouveau projet direction les derniers standards
Pour le metier EJBs sans hésitation.
EJB 3.1, MDB, CDI, JPA 2.0, Servlet 3....
Interceptors, Singletons, EJBs Asynchrones. On essaye et on adopte.

Pour l'ihm, je suis en revanche perplexe. j'opte pour Flex actuellement, mais je ne demande qu'a changer d'avis. Un faible pour XUL aussi, mais non standard et surtout un je m'en foutisme total de la part de mozilla qui on loupé le coche des RIAs.
JavaFX ? ce que j'en ai vu ne m'a pas convaincu.
HTML5 ? incomplet pour le RIA, non typé (javascript)
Quoi d'autre ?

[lunatix]

Coté RIA : il semble que HTML5 soit la solution d'avenir. Par contre, rien de folichon coté JEE. Si tu es pret a faire du javascript : tu peux partir sur jax-rs pour faire la partie serveur en rest (excellente api, tres bien pensée), et te trouver un systeme de templating correct (google closure template par exemple, ou StringTemplate)

(sinon le framework officiel web JEE, c'est JSF. bon perso, a part sous la torture, je ne l'utiliserais pas)

[OButterlin]

(sinon le framework officiel web JEE, c'est JSF. bon perso, a part sous la torture, je ne l'utiliserais pas)

Il y a une raison à cela ?

[lunatix]

1 : c'est complexe : faire son propre composant est difficile, le life cycle d'un bean jsf est horrible, il y a encore du xml de navigation inutile etc... Pire que tout, c'est un framework de composant ou il faut ensuite faire du xml dans le html a coups de <h:text etc... : le pire des deux mondes : des composants et un langage de templating mediocre.
Si on a pas le composant necessaire dans une lib : il est quasi impossible d'aller le chercher dans une autre.

2 : ca n'est adapté qu'aux applications : impossible de faire un site web qui ressemble a quelque chose. pas possible de faire du portail, du cms. Il est quand même evident qu'un framework a base de composants n'est pas adapté a tous les developpements web : sauf dans le monde JEE ou pour JEE6, les jsp ont été depreciées sans remplacement.

3 : ca rame : ca consomme beaucoup de memoire et de cpu. Un vrai probleme sur les sites a forte charge.

4 : ca genere du html horrible.

Au final : c'est tout sauf du web. Pas d'url restful, une integration d'ajax mediocre, pas d'acces au js. impossible d'integrer facilement un plugin jquery, utiliser les nouvelles fonctionnalités des navigateurs est compliqué... etc..

[OButterlin]

On dirait que ton appréciation date un peu. JSF 2.0 inclue pas mal de choses dont :

templating facelets
support total d'ajax
la création de composent ultra simple

Après, pour l'intégration de jQuery, je ne sais pas trop ce que tu cherches à faire mais on peut référencer et utilier jQuery avec JSF 2 avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<h:outputScript library="jquery-ui-1.8.6/js" name="jquery-1.4.2.min.js"/>

Les JSP ne sont plus le standard, et c'est tant mieux pour les performances, c'est du xhtml avec facelets.
Ca ne veut pas dire qu'on ne peut plus utiliser les jsp, pour les vieilles applications, voir les 2

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
<web-app>
     <context-param>
         <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
         <param-value>.jsp</param-value>
     </context-param>
 
      <!-- Facelets pages will use the .xhtml extension -->
     <context-param>
         <param-name>facelets.VIEW_MAPPINGS</param-name>
         <param-value>*.xhtml</param-value>
     </context-param>
 
     <servlet>
         <servlet-name>Faces Servlet</servlet-name>
         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
     </servlet>
 
      <!-- Use prefix mapping for Facelets pages, e.g. http://localhost:8080/webapp/faces/mypage.xhtml -->
     <servlet-mapping>
         <servlet-name>Faces Servlet</servlet-name>
         <url-pattern>/faces/*</url-pattern>
     </servlet-mapping>
 </web-app>

Mais bon, pour les performances, il semble qu'il y ait mieux... pour les applications à fortes demandes.
Là, je n'ai pas assez de recul pour en parler, je ne fais que des applications d'entreprises, l'aspect performance n'est pas trop important.