Conteneur de Servlet+Spring vs. JEE. Quelle direction prenez-vous ?

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 ?

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.

Hello,

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

A plus,

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

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 :)

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.

Citation:

---

Envoyé par ZedroS

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.

j'ai voté pour autre: on utilise maintenant seam

je suis passé a tomcat, et la souplesse qu'il permet (en gros on fait une application par tomcat, et un gros nginx ou apache en proxy devant en sticky session) est imbattable avec un serveur d'application plus lourd.

chaque application est isolée des autres, augmenter la puissance pour une application consiste a ajouter un tomcat

En préconisation, je préfère un serveur JEE avec EJB3.
Ceci dit, on utilise indifféremment un serveur Tomcat avec ou sans Spring ou du JBoss avec EJB ... c'est plutôt le client qui impose son point de vue... et là, on dirait qu'ils lisent un peu tous la même chose aux wc :mouarf:
C'est un peu dommage d'ailleurs, on en arrive à se voire imposer Spring là où il n'apporte rien voir même il complexifie... galère galère :mur:

Clairement JEE5 + EJB. Le développement normé est plus qu'important dans le monde de l'entreprise. De plus le développement de ce type de technologie c'est grandement simplifié au fil des ans ;)

Citation:

---

Envoyé par OButterlin

En préconisation, je préfère un serveur JEE avec EJB3.
Ceci dit, on utilise indifféremment un serveur Tomcat avec ou sans Spring ou du JBoss avec EJB ... c'est plutôt le client qui impose son point de vue... et là, on dirait qu'ils lisent un peu tous la même chose aux wc :mouarf:
C'est un peu dommage d'ailleurs, on en arrive à se voire imposer Spring là où il n'apporte rien voir même il complexifie... galère galère :mur:

---

Tu peux développer un peu sur la complexification apportée par Spring , ton avis m'intèresse sur ce sujet ?

Sinon pour ma part on tourne essentiellement sur Tomcat 6.

Citation:

---

Envoyé par Killing Joke

Tu peux développer un peu sur la complexification apportée par Spring , ton avis m'intèresse sur ce sujet ?

---

Utiliser le concept d'inversion de contrôle pour UN soft fait pour UN client n'a à mon sens pas beaucoup d'intérêt et d'autant moins dans un environnement web.
A ce sujet d'ailleurs, je trouve incroyable l'usage qui en est fait par certains pour déterminer entre autres :
- les paramètres de connexion
- les ressources externes (JMS ou mail...)
- etc...
Là franchement, un fichier de propriété fait la même chose... et JNDI le fait bien mieux encore...
Bref, pour ma part, sans remettre en cause le concept TRES intéressant d'IoC, on peut faire bien mieux avec des EJB.

D'autre part, Spring est entrain de mettre la main sur tout ce qui touche aux développements web avec Spring MVC, Spring Web, Spring machin Spring truc... Donc, s'il s'agit de réécrire à sa sauce propriétaire ce que fait un environnement et/ou des frameworks existants normalisés par JEE... ça devient... :roll:

Je reste ouvert, un jour peut-être on me montrera un usage (intéressant j'entends) qu'on ne peut pas faire simplement autrement...

A l'intention de tous les adorateurs de Spring, ce n'est qu'un avis, pas une attaque en règle, par avance merci... ;)

Serveur Glassfish v2.1 avec EJB, histoire de rester JEE 5 compliant jusqu'au boût !

J'ai voté Servlet( Tomcat ,...)+Spring car j'ai du mal à utiliser d'autre alors que ceci satisfait mes attentes

Serveur GlassFish V2 + JPA + JEE 5

Citation:

---

Utiliser le concept d'inversion de contrôle pour UN soft fait pour UN client n'a à mon sens pas beaucoup d'intérêt et d'autant moins dans un environnement web.

---

Je pense que tu as une vue incomplète de Spring.
Son intérêt n'est pas de la simple injection de propriétés de configuration.
Je l'utilise conjointement avec Hibernate et cela simplifie son utilisation, dont la gestion des transactions, de la gestion de la session, etc...
C'est très pratique en environnement web ou autre.

Citation:

---

Envoyé par fr1man

Je pense que tu as une vue incomplète de Spring.

---

Ça ne fait pas l'ombre d'un doute :mouarf:

Citation:

---

Envoyé par fr1man

Son intérêt n'est pas de la simple injection de propriétés de configuration.
Je l'utilise conjointement avec Hibernate et cela simplifie son utilisation, dont la gestion des transactions, de la gestion de la session, etc...
C'est très pratique en environnement web ou autre.

---

Un conteneur d'EJB fait ça très bien, et bien plus encore...

Je ne te dis pas le contraire, j'essaie juste de te montrer un exemple de ce que l'on peut faire avec, relativement simplement.
Cela peut permettre d'éviter justement l'utilisation des ejbs et d'un serveur d'application, même si l'on doit pouvoir utiliser des ejbs avec un tomcat depuis JEE 5.

Citation:

---

Envoyé par fr1man

Je ne te dis pas le contraire, j'essaie juste de te montrer un exemple de ce que l'on peut faire avec, relativement simplement.
Cela peut permettre d'éviter justement l'utilisation des ejbs et d'un serveur d'application, même si l'on doit pouvoir utiliser des ejbs avec un tomcat depuis JEE 5.

---

Je sais bien, mais le problème n'est pas là...
Pourquoi toujours multiplier les façons de faire quand il existe déjà quelque chose d'abouti...
Et on a le même problème avec les frameworks... struts1, struts2, jsf, etc...
A la fin, on ne sait plus quoi choisir et lequel sera pérenne...
Pour ce qui est de Spring vs EJB, EJB a le gros avantage de faire partie de JEE.