Affichage des résultats du sondage: Pour vos applications Java Entreprise, qu'utilisez vous principalement ?

Votants
137. Vous ne pouvez pas participer à ce sondage.
  • Conteneur de Servlet (Tomcat, Jetty, ..) + Spring

    49 35,77%
  • Serveur JEE 1.4 + EJB

    7 5,11%
  • Serveur JEE 5 + EJB

    37 27,01%
  • Serveur JEE 1.4 + Spring

    10 7,30%
  • Serveur JEE 5 + Spring

    24 17,52%
  • Autre serveur (OSGi, .. )

    10 7,30%
+ Répondre à la discussion Actualité déjà publiée
Page 3 sur 4 PremièrePremière 1234 DernièreDernière
Affichage des résultats 41 à 60 sur 77
  1. #41
    Expert Confirmé
    Avatar de alexismp
    Homme Profil pro Alexis Moussine-Pouchkine
    Inscrit en
    janvier 2005
    Messages
    1 503
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexis Moussine-Pouchkine

    Informations forums :
    Inscription : janvier 2005
    Messages : 1 503
    Points : 2 677
    Points
    2 677

    Par défaut

    Salut Michael,

    Citation Envoyé par michael.isvy Voir le message
    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.

    Citation Envoyé par michael.isvy Voir le message
    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.


    Citation Envoyé par michael.isvy Voir le message
    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

  2. #42
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    5 764
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 764
    Points : 7 231
    Points
    7 231

    Par défaut

    Citation Envoyé par michael.isvy Voir le message
    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...

  3. #43
    Rédacteur
    Avatar de Hikage
    Inscrit en
    mai 2004
    Messages
    1 186
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : mai 2004
    Messages : 1 186
    Points : 5 641
    Points
    5 641

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    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


    Citation Envoyé par OButterlin Voir le message
    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
    Hikage
    SCJP / SCWCD & SCWSJD Certified / Spring Framework Certified
    [Personal Web] [CV]

    F.A.Q Spring Framework - Participez !

  4. #44
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    5 764
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 764
    Points : 7 231
    Points
    7 231

    Par défaut

    Citation Envoyé par Hikage Voir le message
    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 ?

  5. #45
    Rédacteur
    Avatar de Hikage
    Inscrit en
    mai 2004
    Messages
    1 186
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : mai 2004
    Messages : 1 186
    Points : 5 641
    Points
    5 641

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    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.
    Hikage
    SCJP / SCWCD & SCWSJD Certified / Spring Framework Certified
    [Personal Web] [CV]

    F.A.Q Spring Framework - Participez !

  6. #46
    Expert Confirmé
    Avatar de alexismp
    Homme Profil pro Alexis Moussine-Pouchkine
    Inscrit en
    janvier 2005
    Messages
    1 503
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexis Moussine-Pouchkine

    Informations forums :
    Inscription : janvier 2005
    Messages : 1 503
    Points : 2 677
    Points
    2 677

    Par défaut

    Citation Envoyé par Hikage Voir le message
    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.

  7. #47
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    5 764
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 764
    Points : 7 231
    Points
    7 231

    Par défaut

    Citation Envoyé par Hikage Voir le message
    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).

  8. #48
    Rédacteur
    Avatar de Hikage
    Inscrit en
    mai 2004
    Messages
    1 186
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : mai 2004
    Messages : 1 186
    Points : 5 641
    Points
    5 641

    Par défaut

    Citation Envoyé par alexismp Voir le message
    ... 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 ?
    Hikage
    SCJP / SCWCD & SCWSJD Certified / Spring Framework Certified
    [Personal Web] [CV]

    F.A.Q Spring Framework - Participez !

  9. #49
    Expert Confirmé
    Avatar de alexismp
    Homme Profil pro Alexis Moussine-Pouchkine
    Inscrit en
    janvier 2005
    Messages
    1 503
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexis Moussine-Pouchkine

    Informations forums :
    Inscription : janvier 2005
    Messages : 1 503
    Points : 2 677
    Points
    2 677

    Par défaut

    Citation Envoyé par Hikage Voir le message
    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.


    Citation Envoyé par Hikage Voir le message
    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.

  10. #50
    Rédacteur
    Avatar de Hikage
    Inscrit en
    mai 2004
    Messages
    1 186
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : mai 2004
    Messages : 1 186
    Points : 5 641
    Points
    5 641

    Par défaut

    Citation Envoyé par alexismp Voir le message
    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.
    Hikage
    SCJP / SCWCD & SCWSJD Certified / Spring Framework Certified
    [Personal Web] [CV]

    F.A.Q Spring Framework - Participez !

  11. #51
    Expert Confirmé
    Avatar de alexismp
    Homme Profil pro Alexis Moussine-Pouchkine
    Inscrit en
    janvier 2005
    Messages
    1 503
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexis Moussine-Pouchkine

    Informations forums :
    Inscription : janvier 2005
    Messages : 1 503
    Points : 2 677
    Points
    2 677

    Par défaut

    Citation Envoyé par Hikage Voir le message
    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"

  12. #52
    Rédacteur
    Avatar de Hikage
    Inscrit en
    mai 2004
    Messages
    1 186
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : mai 2004
    Messages : 1 186
    Points : 5 641
    Points
    5 641

    Par défaut

    Citation Envoyé par alexismp Voir le message
    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/
    Hikage
    SCJP / SCWCD & SCWSJD Certified / Spring Framework Certified
    [Personal Web] [CV]

    F.A.Q Spring Framework - Participez !

  13. #53
    Expert Confirmé
    Avatar de alexismp
    Homme Profil pro Alexis Moussine-Pouchkine
    Inscrit en
    janvier 2005
    Messages
    1 503
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexis Moussine-Pouchkine

    Informations forums :
    Inscription : janvier 2005
    Messages : 1 503
    Points : 2 677
    Points
    2 677

    Par défaut

    Citation Envoyé par Hikage Voir le message
    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.

  14. #54
    Rédacteur
    Avatar de Hikage
    Inscrit en
    mai 2004
    Messages
    1 186
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : mai 2004
    Messages : 1 186
    Points : 5 641
    Points
    5 641

    Par défaut

    Citation Envoyé par alexismp Voir le message
    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.
    Hikage
    SCJP / SCWCD & SCWSJD Certified / Spring Framework Certified
    [Personal Web] [CV]

    F.A.Q Spring Framework - Participez !

  15. #55
    Expert Confirmé
    Avatar de alexismp
    Homme Profil pro Alexis Moussine-Pouchkine
    Inscrit en
    janvier 2005
    Messages
    1 503
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexis Moussine-Pouchkine

    Informations forums :
    Inscription : janvier 2005
    Messages : 1 503
    Points : 2 677
    Points
    2 677

    Par défaut

    Citation Envoyé par Hikage Voir le message
    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:

    Citation 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.

  16. #56
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    5 764
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 764
    Points : 7 231
    Points
    7 231

    Par défaut

    Citation Envoyé par alexismp Voir le message
    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...

  17. #57
    Rédacteur
    Avatar de Hikage
    Inscrit en
    mai 2004
    Messages
    1 186
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : mai 2004
    Messages : 1 186
    Points : 5 641
    Points
    5 641

    Par défaut

    Citation Envoyé par alexismp Voir le message
    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.
    Hikage
    SCJP / SCWCD & SCWSJD Certified / Spring Framework Certified
    [Personal Web] [CV]

    F.A.Q Spring Framework - Participez !

  18. #58
    Invité régulier

    Profil pro
    Inscrit en
    mars 2008
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2008
    Messages : 6
    Points : 7
    Points
    7

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    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...

    Citation Envoyé par OButterlin Voir le message
    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).

  19. #59
    Expert Confirmé
    Avatar de alexismp
    Homme Profil pro Alexis Moussine-Pouchkine
    Inscrit en
    janvier 2005
    Messages
    1 503
    Détails du profil
    Informations personnelles :
    Nom : Homme Alexis Moussine-Pouchkine

    Informations forums :
    Inscription : janvier 2005
    Messages : 1 503
    Points : 2 677
    Points
    2 677

    Par défaut

    Citation Envoyé par michael.isvy Voir le message
    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).

  20. #60
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    5 764
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 764
    Points : 7 231
    Points
    7 231

    Par défaut

    Citation Envoyé par alexismp Voir le message
    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...

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •