Discussion :

[alexismp]

Salut Michael,

Mais on a des clients qui sont passés à Spring parce qu'ils étaient déçus des précédentes versions de Java EE. Au-delà de ça, Spring a généralement très bonne réputation auprès des développeurs (en terme de stabilité, qualité de code, documentation etc).

Encore une fois l'intérêt de Java EE c'est qu'on si on n'est pas content d'un produit (pb. de qualité par exemple) on peut en changer.
Je ne crois pas à la supériorité de Spring devant tous les autres produits.

Le retour aux EJB est donc loin d'être gagné d'avance. D'autant plus que Java EE6 propose un panel de fonctionnalités plus limité que Spring (notamment sur la Sécurité, les transactions, le Remoting, les Aspects et bien évidemment l'injection de dépendances).

...
Pourtant les aspects sont loin d'être une fonctionnalité gadget: ça permet de gérer ses exceptions proprement, d'injecter des logs à faible coût etc.

La puissance supérieure de Spring est une question de perspective. Je ne suis pas convaincu par les deux exemples d'usage d'aspects (vs. intercepteurs) par exemple.

Donc pour moi, le vrai débat est le suivant : nos clients seront-ils prêts à sacrifier certaines des fonctionnalités dont ils ont besoin aujourd'hui au bénéfice de la standardisation ?

Bref, on en reparlera dans quelques années .

Bien entendu tout ce débat pourrait être caduc si Spring venait à implémenter le profil web de Java EE 6 (tout en fournissant sa qualité, son AOP, etc. comme éléments différentiants). Je n'ose pas encore y croire, mais on en reparlera dans quelques années

[OButterlin]

Le retour aux EJB est donc loin d'être gagné d'avance. D'autant plus que Java EE6 propose un panel de fonctionnalités plus limité que Spring (notamment sur la Sécurité, les transactions, le Remoting, les Aspects et bien évidemment l'injection de dépendances).
Par ailleurs, la carte de l'extensibilité n'est pas forcément jouable. Certes ça serait idéal d'utiliser une syntaxe Java EE6 quand c'est possible et de rajouter des annotations Spring pour enrichir en cas de besoin. Dans la pratique les annotations Java EE ne sont pas héritables (aka. @Inherited). Par ailleurs, je n'ai pas trouvé non plus de façon exploitable de rajouter une couche d'aspects aux EJBs (à moins d'utiliser AspectJ en Compile-Time-Weaving, ce qui est loin d'être à la portée de tout le monde). Pourtant les aspects sont loin d'être une fonctionnalité gadget: ça permet de gérer ses exceptions proprement, d'injecter des logs à faible coût etc.

Je ne connais pas suffisamment Spring pour la comparaison, mais au niveau EJB, la puissance des Transactions JTA me paraît remarquable, je ne vois pas ce qu'on pourrait ajouter sauf bien sûr la possibilité de faire une transaction multi-base/multi-système... Ça, ce serait le pied !
L'injection de dépendance se fait déjà avec les EJB, l'annotation @EJB est très similaire dans la fonctionnalité... non ?
Sinon, qu'entends-tu par "couche d'aspect" ? Peux-tu préciser ?

Pour Spring, c'est peut-être par méconnaissance, mais j'aurais imaginé un système plus typé "classLoader". On aurait fait "new" et hop, c'est Spring qui charge l'objet en se basant sur la conf... à moins que ce ne soit déjà possible... j'suis plutôt newbie avec Spring...

[Hikage]

Je ne connais pas suffisamment Spring pour la comparaison, mais au niveau EJB, la puissance des Transactions JTA me paraît remarquable, je ne vois pas ce qu'on pourrait ajouter sauf bien sûr la possibilité de faire une transaction multi-base/multi-système... Ça, ce serait le pied !
L'injection de dépendance se fait déjà avec les EJB, l'annotation @EJB est très similaire dans la fonctionnalité... non ?

Si tu es dans un serveur JEE, tu peux très bien récupérer aussi le TransactionManager JTA et gérer les transations avec Spring.

Si tu es dans un Tomcat ou autre, il y a des intégration de gestionnaires tel que Atomikkos

Pour Spring, c'est peut-être par méconnaissance, mais j'aurais imaginé un système plus typé "classLoader". On aurait fait "new" et hop, c'est Spring qui charge l'objet en se basant sur la conf... à moins que ce ne soit déjà possible... j'suis plutôt newbie avec Spring...

Il y a effectivement moyen de faire cela avec une configuration spéciale.

Le seul soucis, c'est que c'est un peu trop transparent, et que les developpeur risque de croire que c'est de la magie ..

Sans parler que ca peut avoir des cas speciaux :

MonDao dao = new MonDao();

// dao
<bean class="MonDao" scope="request"/>

C'est un peu ambigu, et je t'avoue que je n'ai jamais trop joue avec cela

[OButterlin]

Si tu es dans un serveur JEE, tu peux très bien récupérer aussi le TransactionManager JTA et gérer les transations avec Spring.

Euh... que veux-tu dire ? J'ai l'impression qu'on s'est mal compris...

Pour ce que tu appelles "une configuration spéciale", peux-tu m'en dire plus et/ou m'aiguiller vers la documentation svp ?

[Hikage]

Euh... que veux-tu dire ? J'ai l'impression qu'on s'est mal compris...

Pour ce que tu appelles "une configuration spéciale", peux-tu m'en dire plus et/ou m'aiguiller vers la documentation svp ?

Ce que je veux dire, c'est que la modèle Spring permet de gérer aussi les transactions JTA, de manière aussi simple que les EJB (Annotation @Transactional, ou directement @TransactionAttribut de JEE).

Mais ce n'est pas Spring qui 'implémente' le gestionnaire de transaction.
Donc si tu es dans un conteneur JEE, tu peux simplement récupérer le transaction manager de celui-ci (Doc Spring).


Si tu n'es pas dans serveur JEE, mais un simple conteneur de servlet ( et donc qui ne comprends pas un gestionnaire JTA), il existe des solutions comme atomikos (doc atomikos + spring ou JOTM.

[alexismp]

Ce que je veux dire, c'est que la modèle Spring permet de gérer aussi les transactions JTA, de manière aussi simple que les EJB (Annotation @Transactional, ou directement @TransactionAttribut de JEE).

... au détail près que c'est explicite en Spring et implicite avec les EJB qui sont transactionnels et thread-safe par défaut.

[OButterlin]

Ce que je veux dire, c'est que la modèle Spring permet de gérer aussi les transactions JTA, de manière aussi simple que les EJB (Annotation @Transactional, ou directement @TransactionAttribut de JEE).

D'accord, c'est bien ce qu'il me semblait... J'étais plutôt dans un comparatif Spring / EJB et de ce point de vue, mettre les Transactions comme un plus de Spring me semblait déplacé...
Il y a certains avantages à la mode Spring et d'autres pour le conteneur EJB, là encore, c'est plus une question de "que développe-t-on" que de Spring c'est nul et EJB c'est génial (ou inversement).

[Hikage]

... au détail près que c'est explicite en Spring et implicite avec les EJB qui sont transactionnels et thread-safe par défaut.

Concernant le fait que cela soit explicite, pour ma part cela ne me choque pas.
Vu qu'au départ, Spring est utilisable dans un serveur JEE, un tomcat ou dans une application standalone, il ne peut pas partir du fait qu'il y a un transactionManager JTA, ou même que chaque Beans est transactionnel par défaut.

En ce qui concerne le fait qu'un EJB soit thread safe, tu veux parler d'un EJB vide de code ?
Car bon, on est pas à l'abris d'un code utilisateur foireux non ?

Bon, dans Spring vu que par defaut, tout est singleton, il y a plus de risque que d'avoir un pool par defaut. Mais le risque est toujours présent non ?

[alexismp]

Concernant le fait que cela soit explicite, pour ma part cela ne me choque pas.

C'est juste plus difficile de faire des erreurs quand il n'y a rien à faire.

En ce qui concerne le fait qu'un EJB soit thread safe, tu veux parler d'un EJB vide de code ?
Car bon, on est pas à l'abris d'un code utilisateur foireux non ?

Prenons un exemple:
Avec une servlet (qui n'est pas thread-safe), il faut passer par un EntityManagerFactory, avec un EJB tu injectes directement un EntityManager.

[Hikage]

Prenons un exemple:
Avec une servlet (qui n'est pas thread-safe), il faut passer par un EntityManagerFactory, avec un EJB tu injectes directement un EntityManager.

En même temps, si tu utilise Spring, c'est Spring qui va t'injecter l'EntityManager directement aussi.

[alexismp]

En même temps, si tu utilise Spring, c'est Spring qui va t'injecter l'EntityManager directement aussi.

Avec une API propre à Spring... Retour à la discussion sur le "standard"

[Hikage]

Avec une API propre à Spring... Retour à la discussion sur le "standard"

De quel API propre parles-tu ? Spring utilise directement le système de JPA (@PersistenceContext).

cf :
http://blog.springsource.com/2006/08...encing-spring/

[alexismp]

De quel API propre parles-tu ? Spring utilise directement le système de JPA (@PersistenceContext).

cf :
http://blog.springsource.com/2006/08...encing-spring/

org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessorreste une dépendance sur Spring.

[Hikage]

org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessorreste une dépendance sur Spring.

Sur cela on est d'accord. Il y a une dépendance au niveau 'configuration'.
Pareil, tu auras à un moment donné un ApplicationContext.

Ca, je vois mal comment cela pourrait changer, du moins sans que Spring s'intègre complètement dans le mécanisme JEE WebProfile.

Mais cela voudrait dire que Spring se restreindrait aux fonction standard, ce qui le limiterait beaucoup je crois.

[alexismp]

Ca, je vois mal comment cela pourrait changer, du moins sans que Spring s'intègre complètement dans le mécanisme JEE WebProfile.

Mais cela voudrait dire que Spring se restreindrait aux fonction standard, ce qui le limiterait beaucoup je crois.

Comme je l'ai dis dans un message précédent:

Bien entendu tout ce débat pourrait être caduc si Spring venait à implémenter le profil web de Java EE 6 (tout en fournissant sa qualité, son AOP, etc. comme éléments différentiants).

et là je ne vois pas pourquoi implémenter un standard serait restreindre les capacités de Spring. Rien de ce qui existe aujourd'hui n'a besoin de disparaître.

[OButterlin]

et là je ne vois pas pourquoi implémenter un standard serait restreindre les capacités de Spring. Rien de ce qui existe aujourd'hui n'a besoin de disparaître.

C'est bien vrai...

[Hikage]

Envoyé par alexismp Voir le message
Bien entendu tout ce débat pourrait être caduc si Spring venait à implémenter le profil web de Java EE 6 (tout en fournissant sa qualité, son AOP, etc. comme éléments différentiants).

et là je ne vois pas pourquoi implémenter un standard serait restreindre les capacités de Spring. Rien de ce qui existe aujourd'hui n'a besoin de disparaître.

Parce que, de la manière dont je le comprends, si tu Spring implémente le Web Profile avec Spring de manière rigoureuse, cela veut dire que Spring n'est plus directement accessible, que ce n'est plus le développeur qui va créer l'applicationContext etc. Mais que c'est le conteneur qui va inspecteur les classes pour y trouver des EJB-Lite, des PostContruct, etc .

Donc tout ce qui est hors Web Profile ne sera plus accessible directement.
Par exemple tout ce qui utilise des annotations specifiques, et qui nécessite la configuration de l'ApplicationContext : Exportation des services Flex par exemple.

Enfin c'est comme cela que je vois les choses, j'ai peut etre une vision erronée.

[michael.isvy]

Je ne connais pas suffisamment Spring pour la comparaison, mais au niveau EJB, la puissance des Transactions JTA me paraît remarquable, je ne vois pas ce qu'on pourrait ajouter sauf bien sûr la possibilité de faire une transaction multi-base/multi-système... Ça, ce serait le pied !

Techniquement, tu pourras faire la même chose avec les 2 solutions. La question, c'est plutôt le nombre de lignes de code nécessaire. En EJB 3.1, d'après ce que j'ai compris, toutes les méthodes métier d'un EJB session sont transactionnelles par défaut.
Moi j'aime bien avoir plus de souplesse. Par exemple :
- les méthodes préfixées par get/find en transactionnel read-only ou pas transactionnelles du tout
- les méthodes préfixées par create/update en transactionnel "classique"

En Spring, ça prend 7 lignes de configuration. Le paramétrage par défaut est redéfinissable. En EJB, tu vas devoir poser une annotation sur chacune des méthodes get/find pour obtenir le comportement désiré. En plus, du vas devoir utiliser des méthodes @NotTransactional à chaque fois que tu ne veux pas de transaction. C'est pas idéal...

L'injection de dépendance se fait déjà avec les EJB, l'annotation @EJB est très similaire dans la fonctionnalité... non ?
Sinon, qu'entends-tu par "couche d'aspect" ? Peux-tu préciser ?

Pour Spring, c'est peut-être par méconnaissance, mais j'aurais imaginé un système plus typé "classLoader". On aurait fait "new" et hop, c'est Spring qui charge l'objet en se basant sur la conf... à moins que ce ne soit déjà possible... j'suis plutôt newbie avec Spring...

Bah je te conseille de faire un tutoriel un peu poussé sur Spring pour l'injection de dépendances et l'AOP. C'est un peu difficile d'expliquer ça en quelques lignes sur un forum sans employer de mots "barbares" .
Pour ta question sur les ClassLoaders: Intercepter un "new" nécessite de "truquer" ton compilateur ou ton classloader.
On n'a pas mis ça par défaut dans Spring parce qu'on considère que c'est beaucoup trop dangereux. Le seul moyen de faire ça est d'utiliser Spring conjointement avec AspectJ (ce qui est un cas assez avancé, pas à la portée de tout le monde).

[alexismp]

Moi j'aime bien avoir plus de souplesse. Par exemple :
- les méthodes préfixées par get/find en transactionnel read-only ou pas transactionnelles du tout
- les méthodes préfixées par create/update en transactionnel "classique"

En Spring, ça prend 7 lignes de configuration. Le paramétrage par défaut est redéfinissable. En EJB, tu vas devoir poser une annotation sur chacune des méthodes get/find pour obtenir le comportement désiré. En plus, du vas devoir utiliser des méthodes @NotTransactional à chaque fois que tu ne veux pas de transaction. C'est pas idéal...

En EJB le comportement par défaut est également re-définissable et ça prend une annotation pour chaque méthode (plutôt succinct et lisible...). On pourra aussi préférer déléguer à un Managed Bean les méthodes non transactionnelles (@NotTransactional c'est pas du standard au passage).

[OButterlin]

En EJB le comportement par défaut est également re-définissable et ça prend une annotation pour chaque méthode (plutôt succinct et lisible...). On pourra aussi préférer déléguer à un Managed Bean les méthodes non transactionnelles (@NotTransactional c'est pas du standard au passage).

D'autant qu'il est toujours préférable (à mon sens) d'avoir explicitement une annotation que de se baser sur un "défaut". Le jour où celui-ci changera, le comportement de l'application sera modifié (à titre d'exemple, Hibernate a changer ça façon de traiter le lazy-loading entre la version 2 et 3)...
Mais c'est un autre débat...