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 4 sur 4 PremièrePremière 1234
Affichage des résultats 61 à 77 sur 77
  1. #61
    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

    Ok, je me suis un peu plongé dans la spec EJB 3.1, et je vois que pour les méthodes non-transactionnelles la syntaxe est :
    Code :
    @TransactionAttribute(NOT_SUPPORTED)
    .

    Je pense qu'on est tous d'accord pour dire que le comportement par défaut doit être redéfinissable au cas par cas via des annotations. C'est ce que font les EJB3.1 et Spring, pas d'élément différentiateur là-dessus.

    En revanche, pour te répondre OButterlin, on sera toujours au moins obligés de se reposer un peu sur le comportement par défaut, à moins de redéfinir pour chaque méthode transactionnelle :
    - le niveau d'isolation
    - la propagation
    - le timeout
    - readOnly ou pas
    - ...

    Donc 2 possibilités:
    - Soit on est d'accord avec le comportement par défaut des EJBs qui est d'ouvrir une transaction en écriture pour chaque méthode y compris pour les méthodes find, get etc (Alexis, STP corrige moi si je me trompe).
    - Soit il va y avoir un peu de configuration à écrire, et c'est là que Spring apporte un outillage intéressant.

    Par exemple, les annotations héritées:
    Code :
    1
    2
    3
    @Transactional(readOnly="true",propagation=PROPAGATION.REQUIRED, timeout="20")
    public @interface ReadOnlyTransactional {
    }
    et par la suite, je peux annoter mes méthodes comme suit:

    Code :
    1
    2
    3
    @ReadOnlyTransactional
    public Client findClient(...) {
    }

    J'aurais également pu aller plus loin et regrouper un ensemble d'annotations que j'utilise beaucoup comme suit:
    Code :
    1
    2
    3
    4
    @Transactional(...)
    @RolesAllowed("ROLE_MEMBER")
    public @interface ReadOnlyServiceMethod {
    }

    Encore une fois, ça c'est pour le cas où l'on souhaite placer des annotations dans le code. Nous avons aussi beaucoup de clients qui ont fait le choix de gérer la politique transactionnelle de leurs applis de manière générique par configuration xml comme suit:

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    <aop:pointcut id=“txMethods”
                    expression=“execution(public * com.springsource..*Service.*(..))”/>  …
     
    <tx:advice id=“txAdvice”>
       <tx:attributes>
    	<tx:method name="find*" read-only="true"/>
    	<tx:method name="update*"/>
       </tx:attributes>
    </tx:advice>
    Si vous souhaitez mettre en place ce type de gestion globale, il me semble bien que le seul moyen est d'utiliser Spring.

    Il y a aussi un 3è cas intéressant: par défaut, la mise en place des transactions nécessite un surcoût au démarrage de l'application. C'est le cas pour les EJB 3.1 comme pour Spring. Chez certains de nos gros clients, sur de très grosses applications, il peut arriver que le temps de démarrage en patisse. Avec Spring (et AspectJ), on peut passer très facilement à un enrichissement du bytecode en phase de compilation. Ca veut dire que ça compile un poil plus lentement, par contre ça démarre plus vite.

    Encore une fois, je suis très heureux que nous ayons maintenant un standard de qualité. Mais il est important de comprendre que le choix Spring vs Java EE n'est pas seulement une question de philosophie. Il y a des différences techniques importantes.

  2. #62
    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 434
    Points
    2 434

    Par défaut

    C'est un peu plus fin que ça les attributs de TX d'EJBs, en particulier on ne créé pas nécessairement une nouvelle transaction à chaque invocation (propagation des TX). Même l'enrichissement du bytecode en phase de compilation reste un détail d'implémentation qu'un conteneur EJB sait fournir. Au passage les transactions read-only je trouve ça quand même bizarre, ça sent le "corner case"...

    Quoi qu'il en soit je pense que les TX c'est vraiment pas un élément différentiateur. Pas au niveau modèle de programmation en tout cas (coté implémentation on pourra apprécier d'avoir un conteneur EJB qui propose API de programmation et implémentation JTA intégrées et supportées par un seul fournisseur).

    Tout au plus on voit la différence d'approche entre le Spring "tout-doit-être-explicitement-spécifié" (plutôt en XML) et le Java EE "intégré-mais-redéfinissable" (plutôt avec annotations).

  3. #63
    Rédacteur
    Avatar de lunatix
    Homme Profil pro julien
    Architecte technique
    Inscrit en
    novembre 2002
    Messages
    1 945
    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 945
    Points : 3 396
    Points
    3 396

    Par défaut

    au dela des differences d'utilisation de spring et de JEE, une grosse difference que je fais c'est la gestion du versionning.

    en entreprise, il est TRES difficile de faire evoluer une version de serveur d'appli (surtout quand celui-ci tourne sous la forme de nombreuses instances, et fait tourner de nombreuses applications). (j'ai vu du websphere faire tourner des dizaines voir centaines d'appllications...) Le simple fait d'envisager une non regression empeche toute montée de version.

    coté spring : l'equipe de developpement choisi une version (en général la derniere) et zou ! (ou peu gerer simplement une montée de version de spring)
    cote J22 : ben on encaisse la frilosité des equipes de production vis a vis d'une montée de version.

    ce n'est pas un point noir 'technique' de Java EE, mais un point noir quand meme que l'on a j'imagine tous rencontrés des qu'on a pas le choix de la plate forme. le Lag des montés de versions de serveurs (faut deja qu'il soit disponible, tous ne sont pas aussi exemplaires que glassfish), ajouté au lag de monté reelle de version. De ce coté, le coté embarqué de spring le rends beaucoup plus flexible.

    peut etre que la solution se trouvera via l'ulitasion d'osgi dans les serveurs d'appli ?

  4. #64
    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 alexismp Voir le message
    Même l'enrichissement du bytecode en phase de compilation reste un détail d'implémentation qu'un conteneur EJB sait fournir.
    Intéressant, je ne savais pas que c'était possible. Ca veut dire que vous avez intégré AspectJ? (Parce que par défaut je ne crois pas qu'il y ait d'Aspects qui génèrent des proxies type EJB3). Et tu parles de qqch qui serait proposé par un serveur d'app ou qui est utilisable sur toutes les marques de serveur d'application ?

    Citation Envoyé par alexismp Voir le message
    Au passage les transactions read-only je trouve ça quand même bizarre, ça sent le "corner case"...
    Au contraire, c'est loin d'être un corner case. Il y a eu beaucoup de discussions sur le sujet dernièrement. Quand tu fais plusieurs accès en base à partir du même service et que tu considères que:
    1) Il est trop coûteux d'ouvrir une transaction RW
    2) Tu veux réutiliser la même connexion pour l'ensemble de ton service
    En ce cas, une transaction RO est la meilleure alternative (mais ça peut dépendre des DB). C'est aussi très utile avec Hibernate, parce qu'il optimise son cache et ne compare pas tous les objets avant fermeture de la session. C'est vraiment une bonne pratique.

  5. #65
    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 des transactions read only :
    Citation Envoyé par michael.isvy Voir le message
    Il y a eu beaucoup de discussions sur le sujet dernièrement.
    où peut on lire ces discussions stp ?

    De la bonne lecture en perspective, merci d'avance !

    ++
    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]

  6. #66
    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 434
    Points
    2 434

    Par défaut

    Je croyais avoir répondu...

    Intéressant, je ne savais pas que c'était possible.
    [/QUOTE]

    Les serveurs d'application modernes sont bourrés d'AOP. Simplement ce n'est pas exposé au développeur.

    Citation Envoyé par michael.isvy Voir le message
    Au contraire, c'est loin d'être un corner case. Il y a eu beaucoup de discussions sur le sujet dernièrement. Quand tu fais plusieurs accès en base à partir du même service et que tu considères que:
    1) Il est trop coûteux d'ouvrir une transaction RW
    2) Tu veux réutiliser la même connexion pour l'ensemble de ton service
    En ce cas, une transaction RO est la meilleure alternative (mais ça peut dépendre des DB). C'est aussi très utile avec Hibernate, parce qu'il optimise son cache et ne compare pas tous les objets avant fermeture de la session. C'est vraiment une bonne pratique.
    Je trouve bizarre de mélanger de la sémantique et du tuning dans une même annotation.

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

    @ZedroS, tu peux lire les commentaires de cette thread, c'est assez intéressant :
    http://www.theserverside.com/news/th...hread_id=53529

  8. #68
    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 434
    Points
    2 434

    Par défaut

    Citation Envoyé par michael.isvy Voir le message
    @ZedroS, tu peux lire les commentaires de cette thread, c'est assez intéressant :
    http://www.theserverside.com/news/th...hread_id=53529
    Ah oui, très bon thread effectivement (rare ces temps-ci sur TSS).

  9. #69
    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 michael.isvy Voir le message
    @ZedroS, tu peux lire les commentaires de cette thread, c'est assez intéressant :
    http://www.theserverside.com/news/th...hread_id=53529
    merci bien, y avait en effet de la matière (et je n'ai pas encore attaqué l'ebook sur infoqhttp://www.infoq.com/minibooks/JTDS ).

    Concernant les transactions read only, tant Mike Keith que l'auteur du sujet semblent réservés quant à leur usage.

    En gros, leur argument est, si j'ai bien compris, que passer en read only implique de facto l'utilisation de transactions et que celles ci peuvent tuer le système (si grosses charges ou transactions trop longues).

    Par contre je n'ai pas bien compris si une pile Hibernate + Spring (sans passer par JPA donc) permet d'éviter des transactions s'il y a un flag read only.

    De façon plus générale, d'ailleurs, j'ai un peu de mal à bien me représenter les cas d'usages majoritaires, dixit Mike et Mark, de lecture de BDD sans read only/transactions (et quand, précisément et dans des cas bien moins fréquents, un read only/transaction serait approprié),

    Perso j'aurai tendance à considérer l'aspect transactionnel en lecture dès que les données en dessous ne sont pas read only, histoire de m'assurer de la consistence de ma lecture.

    Peut etre que l'ebook m'éclairera sur le sujet !
    ++
    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]

  10. #70
    Invité régulier
    Profil pro
    Inscrit en
    juin 2008
    Messages
    17
    Détails du profil
    Informations personnelles :
    Âge : 27
    Localisation : Tunisie

    Informations forums :
    Inscription : juin 2008
    Messages : 17
    Points : 7
    Points
    7

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    A la fin, on ne sait plus quoi choisir et lequel sera pérenne...
    Longue vie à ton clavier, j'imagine que dorénavant va falloir standardiser tout ça.. pour un JEE newbie comme moi, on se perd avant même d'avoir commencer à coder, quoi utiliser au juste.. et s'il faut essayer toutes les technologies pour se faire un avis et savoir quel est le meilleur, on est bien partie pour une très longue chevauchée.. et c'est même pas sur que ça va payer

    mais bon.. peut être me trompe-je..

  11. #71
    Membre du Club
    Homme Profil pro François HH
    Développeur Java
    Inscrit en
    septembre 2002
    Messages
    62
    Détails du profil
    Informations personnelles :
    Nom : Homme François HH
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : Service public

    Informations forums :
    Inscription : septembre 2002
    Messages : 62
    Points : 60
    Points
    60

    Par défaut JEE 6 + EJB 3.1 => Glassfish 3.X

    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 ?

  12. #72
    Rédacteur
    Avatar de lunatix
    Homme Profil pro julien
    Architecte technique
    Inscrit en
    novembre 2002
    Messages
    1 945
    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 945
    Points : 3 396
    Points
    3 396

    Par défaut

    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)

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

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 456
    Points : 6 361
    Points
    6 361

    Par défaut

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

  14. #74
    Rédacteur
    Avatar de lunatix
    Homme Profil pro julien
    Architecte technique
    Inscrit en
    novembre 2002
    Messages
    1 945
    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 945
    Points : 3 396
    Points
    3 396

    Par défaut

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

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

    Informations forums :
    Inscription : novembre 2006
    Messages : 5 456
    Points : 6 361
    Points
    6 361

    Par défaut

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

  16. #76
    Modérateur
    Avatar de Nemek
    Homme Profil pro Logan
    Architecte technique
    Inscrit en
    août 2005
    Messages
    1 982
    Détails du profil
    Informations personnelles :
    Nom : Homme Logan
    Âge : 28
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 1 982
    Points : 4 344
    Points
    4 344

    Par défaut

    La partie AJAX est déléguée aux bibliothèques de composant comme RichFaces.

    Côté performance, je suis peu dans le même cas qu'OButterlin. Cependant on a fait une maquette avant de lancer la migration de Struts1 + Framework Ajax maison ultra-simple ver JSF/RichFaces. Et on arrive à des charges similaires.

    Pour la création de composants, un gars tout neuf en dev web a créée une nouvelle Combobox qui répondait à notre ancien framework maison en quelques jours.

    Pour le XML de navigation, tu voudrais un système d'annotation ? Franchement je suis pas fan des annotations à tout va mais pourquoi pas. Ceci étant les règles de navigation de situe au dessus des beans selon moi.

    Concernant les bibliothèques de composant, je te rejoins sur le principe. Quand tu en choisis une, tu ne pourras pas en sortir et il faudra utiliser des composants prévues pour cette bibliothèque.

    Tu peux très bien faire des portlet avec JSF et c'est même prévue pour !
    Tu peux même accéder indépendamment en mode portlet/servlet à une application déployée.

    Pour le CMS, je pense que c'est possible. Mais il te faudra une bibliothèque (pas nécessairement de composant) ou une implémentation orienté dans ce sens.
    D'ailleurs la gestion de contenu n'est clairement pas la cible de JSF qui s'inscrit dans une logique Java EE.

    Pour le côté RESTFUL, comme le CMS ca reste possible. Je vois rien qui l'empêcherait.

    Concernant le HTML générer j'avoue ne pas avoir regardé mais ca doit respecter le XHTML donc au moins ca devrait passer le validateur du W3C.

    JSF n'est pas orienté Ajax à la base. C'est simplement un framework web, l'Ajax est une partie spécifique du web.
    Java : Forum - FAQ - Java SE 7 API - Java EE 7 API
    Articles : Introduction au langage Ceylon

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  17. #77
    Invité de passage
    Homme Profil pro Achref NEFZI
    Étudiant
    Inscrit en
    avril 2011
    Messages
    14
    Détails du profil
    Informations personnelles :
    Nom : Homme Achref NEFZI
    Localisation : Tunisie

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : avril 2011
    Messages : 14
    Points : 1
    Points
    1

    Par défaut

    Bonjour;
    est ce vous avez une tutorial pour une application
    hibernate spring vaadin?
    merci

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
  •