Discussion :

[michael.isvy]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[alexismp]

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

[lunatix]

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 ?

[michael.isvy]

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 ?

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.

[joseph_p]

A propos des transactions read only :

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 !

++

[alexismp]

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.

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.

[michael.isvy]

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

[alexismp]

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

[joseph_p]

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

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

[NaZeF]

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

[hhfr]

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 ?

[lunatix]

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)

[OButterlin]

(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 ?

[lunatix]

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

[OButterlin]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Logan Mauzaize]

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.

[achref05]

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