Publicité

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 2 sur 4 PremièrePremière 1234 DernièreDernière
Affichage des résultats 21 à 40 sur 77
  1. #21
    Rédacteur
    Avatar de Hikage
    Inscrit en
    mai 2004
    Messages
    1 190
    Détails du profil
    Informations personnelles :
    Âge : 30

    Informations forums :
    Inscription : mai 2004
    Messages : 1 190
    Points : 5 293
    Points
    5 293

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    Ça ne fait pas l'ombre d'un doute

    Un conteneur d'EJB fait ça très bien, et bien plus encore...
    Je ne nie pas que Spring et JEE propose des fonctionnalités similaires

    - Gestion des transaction : Si maintenant il est tout aussi simple de le faire en JEE qu'en Spring, au début de Spring ce n'était pas forcement le cas.
    De plus, Spring permettant l'utilisation de transaction déclarative en déhors mêne d'une application JEE. Ce qui était tout de même fort pratique.
    Notons par ailleurs que Spring gèrent aussi les annotations de JEE pour les transactions.

    - l'AOP : Je ne connais pas trop les fonctionnalités de JEE 6, mais jusqu'ici, l'AOP de Spring est tout de même bien simple et souple

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

    Je viens mal en quoi Spring MVC est une réécriture propriétaire de ce qui existe en JEE. Le seul framework JEE pour le Web est JSF. Qui est complètement différent de Spring MVC.

    Spring MVC serait eventuellement au départ une réécriture de Struts .. mais cela n'a rien a voir avec JEE.
    Il y a bien Spring Face ? Ce n'est pas une réécriture, juste une extension.
    Hikage
    SCJP / SCWCD & SCWSJD Certified / Spring Framework Certified
    [Personal Web] [CV]

    F.A.Q Spring Framework - Participez !

  2. #22
    Modérateur

    Inscrit en
    août 2006
    Messages
    3 091
    Détails du profil
    Informations forums :
    Inscription : août 2006
    Messages : 3 091
    Points : 3 380
    Points
    3 380

    Par défaut

    Je comprends bien ton point de vue et je le partage également.
    Ce qu'il faut voir, c'est que Spring a proposé des concepts absents à l'époque des EJB 2. Donc à cette époque, l'intérêt était bien réel.
    Actuellement, c'est moins le cas, mais Spring a l'avantage d'évoluer plus vite que la "norme". Donc son utilisation ne me dérange pas, s'il y a une valeur ajoutée derrière.

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

    Informations forums :
    Inscription : mai 2004
    Messages : 1 190
    Points : 5 293
    Points
    5 293

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    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.
    Je suis d'accord, le fait que cela soit standard peu être perçu comme un plus.
    JEE 6 à l'air super intéressant, je te l'accorde. Il faut avouer aussi qu'il y a eu une inflence de Spring derrière ..


    Cependant, est-ce qu'être standard est toujours aussi important ?
    Solution perenne ? Certes .. si tu utilise Glassfish et qu'il devait etre sacrifié, tu pourrais passer sur Websphere ?
    En théorie, peut être, en pratique pas forcemment aussi facilement.

    Tu veux passer de JEE 5 à JEE 6 ? Il faut changer de serveur, et donc cela impose des couts.

    Spring n'est pas parfait, mais il à l'avantage d'etre léger, tu peux passer de Spring 2.5 à Spring 3.0 sans devoir revoir ton parc de serveur.

    De plus, un standard n'évolue pas aussi rapidement qu'un produit comme Spring, qui reste OpenSource et donc évoluera plus vite si la communauté suit derrière.

    Tu vas dire que Glassfish ou JBoss sont OpenSource aussi .. Oui d'accord !
    Mais si tu utilise une fonctionnalité propre à un de ses serveurs, tu perds ton fameux standard...
    Hikage
    SCJP / SCWCD & SCWSJD Certified / Spring Framework Certified
    [Personal Web] [CV]

    F.A.Q Spring Framework - Participez !

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

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 590
    Points : 6 210
    Points
    6 210

    Par défaut

    Citation Envoyé par Hikage Voir le message
    Je viens mal en quoi Spring MVC est une réécriture propriétaire de ce qui existe en JEE. Le seul framework JEE pour le Web est JSF. Qui est complètement différent de Spring MVC.

    Spring MVC serait eventuellement au départ une réécriture de Struts .. mais cela n'a rien a voir avec JEE.
    Il y a bien Spring Face ? Ce n'est pas une réécriture, juste une extension.
    Euh là d'accord, je me suis mal exprimé... je ne mettais pas cet aspect particulier en face de JEE, c'était plus une réflexion globale... désolé...

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

    Informations forums :
    Inscription : mai 2004
    Messages : 1 190
    Points : 5 293
    Points
    5 293

    Par défaut

    Attention, je ne décrie pas JEE ou les EJBs.

    Pour l'instant, il n'y a pas d'équivalent Spring au EJB Statefulll ( et donc des WebService statefull ).

    JEE 6 est très intéressant aussi, et est une alternative à Spring (ou le contraire).
    Mais pour moi, le fait de se cacher derrière le mot standard me fait un peu sourire, car c'est du pure marketing ou une utopie en pratique
    Hikage
    SCJP / SCWCD & SCWSJD Certified / Spring Framework Certified
    [Personal Web] [CV]

    F.A.Q Spring Framework - Participez !

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

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 590
    Points : 6 210
    Points
    6 210

    Par défaut

    Citation Envoyé par Hikage Voir le message
    De plus, un standard n'évolue pas aussi rapidement qu'un produit comme Spring, qui reste OpenSource et donc évoluera plus vite si la communauté suit derrière.
    Moi je rêve que tout le monde s'unisse autour d'UNE excellente idée et la fasse évoluer (ah utopie quand tu nous tiens )
    Il y a du bon partout, mais trop de choix tue java (au sens large, jee, jse...) au profit de solutions propriétaires payantes (Microsoft par exemple)
    A la fin, on s'y perd... et ça devient casse pied de toujours se former au nouveau standard du moment qui apporte UN petit plus dans UN domaine par rapport à ce qui existait... pourquoi ne pas avoir fait évolué cela...
    Citation Envoyé par Hikage Voir le message
    Tu vas dire que Glassfish ou JBoss sont OpenSource aussi .. Oui d'accord !
    Mais si tu utilise une fonctionnalité propre à un de ses serveurs, tu perds ton fameux standard...
    C'est l'intérêt de certaines des api de jee comme JPA par exemple dans un domaine particulier... on s'y plie, on peut faire énormément de choses... et on passe d'une implémentation de JPA à une autre sans modification de code (Hibernate -> TopLink par exemple)

  7. #27
    Membre à l'essai
    Inscrit en
    novembre 2008
    Messages
    24
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : novembre 2008
    Messages : 24
    Points : 20
    Points
    20

    Par défaut

    Dans nos projets, nous avons testé java ee 5 et du 6. Nous testons en ce moment Spring avec son conteneur léger.

    Nous allons sans doute prendre des EJB version 3.1 avec jndi pour l'acces au EJB entity. Nous avons deja tout fait sur glassfish.

    Bref Spring peut tres bien utilisé EJB à coté.

    Nous allons utilisé Spring MVC pour la partie MVC et testé sur un tomcat par la suite.

    Bref les deux poids lourds pour les applications entreprises se completent bien.

  8. #28
    Membre Expert

    Inscrit en
    décembre 2004
    Messages
    584
    Détails du profil
    Informations forums :
    Inscription : décembre 2004
    Messages : 584
    Points : 1 207
    Points
    1 207

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    Moi je rêve que tout le monde s'unisse autour d'UNE excellente idée et la fasse évoluer (ah utopie quand tu nous tiens )
    Il y a du bon partout, mais trop de choix tue java (au sens large, jee, jse...) au profit de solutions propriétaires payantes (Microsoft par exemple)
    A la fin, on s'y perd... et ça devient casse pied de toujours se former au nouveau standard du moment qui apporte UN petit plus dans UN domaine par rapport à ce qui existait... pourquoi ne pas avoir fait évolué cela...
    hum... je ne partage pas ton avis : le choix est justement une des forces de Java. Sans la communauté open source (ou plutot les communautés), où en serait java aujourd'hui ? Certes, cela fait du choix. Certes, cela est plus compliqué de choisir. Mais quelle liberté, quelles marges de manœuvres ! Des expérimentations dans tous les sens qui finissent par intégrer les standards "officiels" et débordent ensuite sur les autres langages !

    De plus, perso, je cherche plus la meilleure "pile" technologique possible, celle qui me rendra productif tout en étant robuste à souhait, plutôt que le standard du moment. Et là encore, si on sait ce qu'on veut au delà des buzz, la richesse de java ouvre des horizons insoupçonnés.

    J'ai eu l'occasion de bosser avec des produits propriétaires... ah la la, toutes ces rengaines à 2 sous : "c'est dans la prochaine version", "on n'a pas ça mais on a ça qui s'en approche" (la bonne blague !) et autres "ça viendra".

    Alors oui c'est plus dur de choisir, mais être à même de comprendre et de choisir est l'essentiel du métier non ? Quand à "devoir" apprendre de nouveaux standards, ouarf, l'informatique tourne entièrement autour de la notion d'apprentissage permanent, alors que ce soit un standard ou le framework xyz... Surtout que le dit framework peut sacrément te faciliter la vie (pour le standard, ouarf, je sais moins, peut etre que oui mais généralement avec un décalage de quelques années).

    Par exemple, au boulot, on évalue en ce moment le framework lombok (http://projectlombok.org/features/index.html)... Encore des gains d'efficacité en perspective ! On avance, la vie est belle
    Merci d'utiliser le bouton [Résolu] pour les sujets qui le sont.
    [pub]mon blog franco anglais, article du moment: Wicket: fournir des données JSON via Ajax[/pub]

  9. #29
    Invité régulier
    Homme Profil pro Karim Matrah
    Ingénieur développement logiciels
    Inscrit en
    septembre 2008
    Messages
    9
    Détails du profil
    Informations personnelles :
    Nom : Homme Karim Matrah
    Âge : 27
    Localisation : France, Alpes Maritimes (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : septembre 2008
    Messages : 9
    Points : 9
    Points
    9

    Par défaut

    Au boulot, c'est plutôt JBoss/EJB/JSF/RichFaces,

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

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 590
    Points : 6 210
    Points
    6 210

    Par défaut

    Citation Envoyé par ZedroS Voir le message
    Alors oui c'est plus dur de choisir, mais être à même de comprendre et de choisir est l'essentiel du métier non ? Quand à "devoir" apprendre de nouveaux standards, ouarf, l'informatique tourne entièrement autour de la notion d'apprentissage permanent, alors que ce soit un standard ou le framework xyz... Surtout que le dit framework peut sacrément te faciliter la vie (pour le standard, ouarf, je sais moins, peut etre que oui mais généralement avec un décalage de quelques années).
    Ce n'était pas vraiment le sens de mon propos... je me suis (encore) mal exprimé...
    Évidemment, l'informatique est une discipline où il faut sens cesse renouveler ses connaissances, personnellement, c'est même ce qui m'attire... ce qui me gêne le plus était résumé dans "...se former au nouveau standard du moment qui apporte UN petit plus dans UN domaine par rapport à ce qui existait...", l'effet buzz, l'effet DSI, on l'appelle comme on veut...

    Sinon, je suis d'accord avec toi sur la notion de recherche de "la meilleure pile technologique possible". Là, on n'a pas tous les mêmes besoins ni les même contraintes, ce qui fait qu'on n'aura pas forcément les mêmes choix... de là à dire que le choix des autres est nul est un raccourci que je ne ferai pas...

  11. #31
    Rédacteur
    Avatar de lunatix
    Homme Profil pro julien
    Architecte technique
    Inscrit en
    novembre 2002
    Messages
    1 946
    Détails du profil
    Informations personnelles :
    Nom : Homme julien
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : novembre 2002
    Messages : 1 946
    Points : 3 072
    Points
    3 072

    Par défaut

    Perso, je pense que JEE6 réussi enfin a arriver au niveau qui pourrait m'intéresser niveau back, mais quand je vois les commentaires sur la partie web, je me dis que je ne suis pas pret a refaire confiance.

    par exemple : JSP ne va plus évoluer et tout est basculé vers JSF... ces gens ne comprennent rien au web : je bosse sur des sites web et portails a forte charge : jsf est totalement inutilisable dans ce cas, et j'aurais grand besoin d'une evolution des jsp (pour améliorer les perfs, la capacité a faire du cache, le templating etc....)

    la ou spring mvc3 va dans le bon sens (approche restful, view switchables etc...) jsf c'est juste n'importe quoi.

  12. #32
    Membre à l'essai
    Inscrit en
    août 2004
    Messages
    34
    Détails du profil
    Informations personnelles :
    Âge : 29

    Informations forums :
    Inscription : août 2004
    Messages : 34
    Points : 22
    Points
    22

    Par défaut

    Bonjour , j'ai voté tout de même J2EE 5 + spring dans le sens ou il est vrai il est assez simple et rapide de developper une application web grâce à Spring en se rebassant sur des fichiers de configurations déjà existant. La première fois , je dois bien avouer que ca été un peu galère pour moi de faire les choses correctement. Cependant dans mes anciennes missions je n'ai pas eu l'occasion de mettre ce profil en action dans une cadre "entreprise" , celle-ci préférant rester au maximum dans les standards J2EE "officiel" pour ne pas être victime de la mode du moment, Spring étant souvent déprécié.

    Citation Envoyé par lunatix Voir le message
    Perso, je pense que JEE6 réussi enfin a arriver au niveau qui pourrait m'intéresser niveau back, mais quand je vois les commentaires sur la partie web, je me dis que je ne suis pas pret a refaire confiance.

    par exemple : JSP ne va plus évoluer et tout est basculé vers JSF... ces gens ne comprennent rien au web : je bosse sur des sites web et portails a forte charge : jsf est totalement inutilisable dans ce cas, et j'aurais grand besoin d'une evolution des jsp (pour améliorer les perfs, la capacité a faire du cache, le templating etc....)

    la ou spring mvc3 va dans le bon sens (approche restful, view switchables etc...) jsf c'est juste n'importe quoi.
    Je suis tout à fait d'accord avec toi ! Au niveau performance "front-end" JSF et consort sont des gouffres à process . J'ai fait quelques benchmark sur la génération d'une page en JSP / JSF / MyFaces / IceFaces & RichFaces et c'est hallucinant les différences que l'on peut avoir pour afficher la même chose ! Ok , chacun apporte des fonctionnalités et des facilités qui ont un cout mais quand même !

    Pour ma part dans des dev personnelles , j'opte souvent pour RichFaces qui est à mon gout très beau, skinnable et pour lequel ajouter des fonctionnalités ajax en plus de celle de base n'est pas compliquer ( comparé à JSP + DWR par exemple) je sais que derrière tout ca , j'ai un cout en process qui ne serait pas négligeable .

  13. #33
    Membre Expert

    Inscrit en
    décembre 2004
    Messages
    584
    Détails du profil
    Informations forums :
    Inscription : décembre 2004
    Messages : 584
    Points : 1 207
    Points
    1 207

    Par défaut

    A propos de comparaison, petit topo dispo ici :
    http://ptrthomas.wordpress.com/2009/...-5-and-grails/
    ++
    Merci d'utiliser le bouton [Résolu] pour les sujets qui le sont.
    [pub]mon blog franco anglais, article du moment: Wicket: fournir des données JSON via Ajax[/pub]

  14. #34
    Membre Expert
    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 412
    Points
    2 412

    Par défaut

    Citation Envoyé par Hikage Voir le message
    Mais pour moi, le fait de se cacher derrière le mot standard me fait un peu sourire, car c'est du pure marketing ou une utopie en pratique
    Je pense que mes clients qui utilisent maintenant GlassFish et qui utilisaient d'autres platformes j2ee/javaee avant ne seront pas d'accord avec toi. Le standard est ce qui leur a permit de changer de crémerie à moindre frais.

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

    Informations forums :
    Inscription : mai 2004
    Messages : 1 190
    Points : 5 293
    Points
    5 293

    Par défaut

    Citation Envoyé par alexismp Voir le message
    Je pense que mes clients qui utilisent maintenant GlassFish et qui utilisaient d'autres platformes j2ee/javaee avant ne seront pas d'accord avec toi. Le standard est ce qui leur a permit de changer de crémerie à moindre frais.
    C'est clairement plus facile de passer d'un Weblogic à un Glassfish que d'un Weblogic à un Spring. Je ne dis pas le contraire.

    Mais c'est pas non plus complètement transparent, et indolore. C'est pas simplement "je prends mon ear et je le place de l'un à l'autre".
    Et c'est malheureusement souvent comme cela qu'on essaie de le vendre

    "Si tu choisi JEE, tu n'es pas du tout lié à un produit".
    En pratique, c'est pas forcement le cas. si le code est à 95% portable d'un serveur à l'autre, le 5% te bloque parfois pas mal non plus.

    La philosophie de JEE est super intéressante, de vouloir s'abstraire de tout fournisseur. C'est une bonne chose, que j'applaudis.

    En pratique, le problème est que chaque fournisseur doit se distinguer d'un autre serveur pour se "vendre", et fournir d'autre services supplémentaires, non standards . Et on est toujours tenté un jour ou l'autre de s'en servir. Et la, fini la portabilité (aussi) facile.
    Hikage
    SCJP / SCWCD & SCWSJD Certified / Spring Framework Certified
    [Personal Web] [CV]

    F.A.Q Spring Framework - Participez !

  16. #36
    Membre Expert
    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 412
    Points
    2 412

    Par défaut

    Citation Envoyé par Hikage Voir le message
    C'est clairement plus facile de passer d'un Weblogic à un Glassfish que d'un Weblogic à un Spring.
    Je pensais plus à passer de Spring à Java EE

    Citation Envoyé par Hikage
    Mais c'est pas non plus complètement transparent, et indolore.
    Non, mais dans cette industrie on n'a jamais eu un tel niveau de portabilité et rares sont les cas ou les clients qui sont passés sur GlassFish avaient prémédité le changement avec un respect scrupuleux de J2EE/JavaEE. Preuve que la portabilité est bien réelle. Je n'ai qu'un cas (plutôt extreme) de client ou la migration a échoué (dans le temps imparti très court).

    Citation Envoyé par Hikage
    En pratique, le problème est que chaque fournisseur doit se distinguer d'un autre serveur pour se "vendre", et fournir d'autre services supplémentaires, non standards . Et on est toujours tenté un jour ou l'autre de s'en servir. Et la, fini la portabilité (aussi) facile.
    Je ne suis pas d'accord. Il y a plein de façon de se différencier sans proposer des API propriétaires. En tout cas, rien de qui est mis en avant pour GlassFish v3 n'implique un modèle de programmation non standard et je ne vois pas ce genre de discours ailleurs non plus.

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

    Informations forums :
    Inscription : mai 2004
    Messages : 1 190
    Points : 5 293
    Points
    5 293

    Par défaut

    Citation Envoyé par alexismp Voir le message
    Je pensais plus à passer de Spring à Java EE
    Je me doute bien ;-)
    Ma question, pourquoi migrer ?

    Spring est venu à l'époque car il y avait un gros soucis dans JEE : sa complexité.
    Il est donc devenu intéressant de passer sur Spring car plus simple et plus souple.

    Depuis, JEE s'est grandement simplifié, et est redevenue intéressante.
    Aussi simple ? Certainement :-)
    Aussi complète ? Certainement plus sur certains sujet, peut être moins sur d'autres ( c'est discutable ;-) )

    Mais est-ce qu'il est aussi intéressant de revenir vers JEE alors que Spring s'est super bien implanté? Depuis le temps, Spring est plutot bien compris par les équipes, pas mal de framework "home made" sont basés sur Spring.

    Et même si JEE 6 à l'air génial, le seul avantage qu'il m'apporte est ce coté Standard .. Je suis pas sur que les développements seront simplifiés, ou plus rapides. Il faudra réapprendre un modèlè de développement .. et donc investir du temps et du budget sans avoir un gain "réel".

    Du moins, c'est mon avis pour l'heure, je changerai peut être d'avis en m'y mettant plus à sa sortie.

    Citation Envoyé par alexismp Voir le message
    Non, mais dans cette industrie on n'a jamais eu un tel niveau de portabilité et rares sont les cas ou les clients qui sont passés sur GlassFish avaient prémédité le changement avec un respect scrupuleux de J2EE/JavaEE. Preuve que la portabilité est bien réelle. Je n'ai qu'un cas (plutôt extreme) de client ou la migration a échoué (dans le temps imparti très court).



    Je ne suis pas d'accord. Il y a plein de façon de se différencier sans proposer des API propriétaires. En tout cas, rien de qui est mis en avant pour GlassFish v3 n'implique un modèle de programmation non standard et je ne vois pas ce genre de discours ailleurs non plus.
    Je vais essaye de te trouver un cas particulier ;-)


    Dans le même style de soucis : JPA.
    J'ai vu plusieurs projets qui utilisait JPA 1.0. Mais il n'était pas rare de les voir utiliser des fonctions propres à leur implémentation de JPA (Hibernate) car plus puissante.
    Bon depuis, je crois qu'il y a pas mal de nouveauté qui sont dans JPA 2.0. Donc "standardisé". C'est mieux d'accord.
    Hikage
    SCJP / SCWCD & SCWSJD Certified / Spring Framework Certified
    [Personal Web] [CV]

    F.A.Q Spring Framework - Participez !

  18. #38
    Membre Expert
    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 412
    Points
    2 412

    Par défaut

    Citation Envoyé par Hikage Voir le message
    Je me doute bien ;-)
    Ma question, pourquoi migrer ?
    Facile! Parce qu'après on pourra passer d'un conteneur à un autre.

    Citation Envoyé par Hikage
    Spring est venu à l'époque car il y avait un gros soucis dans JEE : sa complexité.
    Il est donc devenu intéressant de passer sur Spring car plus simple et plus souple.
    Spring est la meilleure chose qui soit arrivée à Java EE.

    Citation Envoyé par Hikage
    Mais est-ce qu'il est aussi intéressant de revenir vers JEE alors que Spring s'est super bien implanté? Depuis le temps, Spring est plutot bien compris par les équipes, pas mal de framework "home made" sont basés sur Spring.

    Et même si JEE 6 à l'air génial, le seul avantage qu'il m'apporte est ce coté Standard .. Je suis pas sur que les développements seront simplifiés, ou plus rapides. Il faudra réapprendre un modèlè de développement .. et donc investir du temps et du budget sans avoir un gain "réel".
    Pas très utile de toucher aux applications existentes, c'est sûr. Il y a d'ailleurs encore pas mal d'applications EJB CMP dans la nature

  19. #39
    Membre Expert

    Inscrit en
    décembre 2004
    Messages
    584
    Détails du profil
    Informations forums :
    Inscription : décembre 2004
    Messages : 584
    Points : 1 207
    Points
    1 207

    Par défaut

    Je pense qu'il y a aussi un avantage fondamental avec un standard avec de nombreuses implémentations (dans la misère où elles ne diffèrent pas trop) : la garantie vis à vis de l'avenir.

    Si jamais Glassfish n'est pas repris correctement par Oracle, ou bien si tel ou tel fournisseur décide de passer à une stratégie qui ne convient pas, les options sont assez aisément envisageables.

    A l'inverse, un framework qui n'est pas un standard, avec un seul fournisseur, nous lie à son égard. Et la dépendance augmente au fur et à mesure que le framework englobe de plus en plus d'aspects.

    J'ai toujours le cas d'ext js en tête dans cas cas là : si jamais springsource décidait de faire ainsi, les difficultés pour ses utilisateurs seraient bien plus grandes que si un fournisseur de conteneur d'EJB fesait de même.
    Merci d'utiliser le bouton [Résolu] pour les sujets qui le sont.
    [pub]mon blog franco anglais, article du moment: Wicket: fournir des données JSON via Ajax[/pub]

  20. #40
    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 : 6
    Points
    6

    Par défaut

    Pour commencer, je retiendrai cette citation d'Alexis que j'aime beaucoup:
    "Spring est la meilleure chose qui soit arrivée à Java EE."

    Je vais me mettre du côté Spring, mais c'est mon boulot après tout . Certes Java EE6 a fait un très gros buzz à Devoxx et c'est très bien.
    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).

    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.

    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 .

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
  •