Merci.

je viens de découvrir cet article suite à une discussion sur le forum concernant la gestion du lazy loading par spring [1].
J’en profite pour rebondir sur ce que proposait N!co (même si ça date pas mal tout ça…) avec l’utilisation de JpaDaoSupport. C’est justement ce que j’utilisais et j’ai pas réussi à mettre en place le lazy loading puisqu’on utilise plus directement l’Entity Manager, où mettre l’annotation @PersistenceContext(type = PersistenceContextType.EXTENDED) qui va bien?
J’ai ensuite trouvée une discussion[2] sur le forum Spring source Community qui cite la doc Spring déconseillant l’utilisation de JpaDaoSupport…
Je m’apprête donc à refactoriser mon code (ça va que j’en suis au début du projet avec seulement 3 DAO et 5 Services…) pour ne plus utiliser JpaDaoSupport, mais bien l’entityManager et les annotations explicites à la place.
Cet article me sera fort utile dans ce sens, en espérant qu’il n’est pas trop « out-of-date »

Désolée, je sais pas comment faire un jolie lien dans les commentaires :/
Voici le lien vers le sujet du forum qui m’a menée jusqu’ici :
[1] http://www.developpez.net/forums/d1089614/java/general-java/spring/gerer-lazy-loading/

et le lien vers la discussion sur le forum spring :
[2] http://forum.springsource.org/showthread.php?45578-How-to-inject-EntityManager-in-JpaDaoSupport-with-annotations&p=158581#post158581

Voici un article en français pour commencer en SCALA avec Idea et Simple Build Tool :
http://geek-du-soir.blogspot.com/2010/12/commencer-un-nouveau-projet-en-scala.html

je suis un utilisateur quotidien de JSF. Je ne suis pas tout à fait d’accord avec le billet ci-dessus. Je m’explique : JSF ne peut-être juger dans le cadre d’une prestation ponctuelle et commandée. JSF est conçu pour une utilisation à long terme. J’entends par là la conception d’un Framework d’entreprise avec des composants réutilisables spécifiques.
RichFaces, c’est beau, c’est bien. Mais ça ne répond pas forcément aux nécessités des projets informatiques (ou en tout cas pas en totalité).
Aussi, il peut-être intéressant de perdre du temps sur un projet en développant ses propres composants et pouvoir les réutiliser plus tard sur des projets similaires. J’avouerai quand même que l’aspect composant, même si c’est génial niveau réutilisabilité (comme dit avant), cela comporte également de nombreux défauts et désagréments (lisibilité du code, beaucoup plus aisée quand on pense au niveau de l’action… bugs récurrents et semi-aléatoires de JSF etc.).
Je pense qu’on ne peut pas juger pleinement JSF si l’on utilise essentiellement des librairies externes. Il faut développer ses propres librairies pour pouvoir réellement toucher au coeur du Framework, j’entends par là le cycle de vie de la requête. Un Framework doit, selon moi, être essentiellement jugé par rapport à son cycle de vie. En ce sens, je préfère Struts2 à JSF (l’aspect très simple et totalement paramétrable de la stack d’appel du cycle de vie de Struts2 est un vrai bonheur), mais JSF reste un Framework hautement productif dans le cadre d’un maintien et d’une réutilisation de composants pour des prestations métier proches.
Autre point de désaccord : les Facelets. Oui, il est certain qu’il s’agit d’un sacré piège au début en terme de récupération des erreurs, mais c’est paramétrable. Facelet amène en revanche une sacré performance comparé aux JSP et à leur phase de pré-compilation. On retrouve là les avantages que l’on peut trouver dans les différents moteurs de template (velocity etc…). En revanche, Facelets n’est pas là pour faciliter la conception de composants puisque cela se fait essentiellement au travers de la classe Renderer de JSF. Facelet améliore essentiellement les performances, puisque l’aspect composant est géré directement par le Framework. Je considère Facelet comme une manière d’améliorer les performances du Framework.
Concernant la scope request, j’en ai eu très peu l’utilité, mais certains cas que nous avons rencontré au sein de mon équipe n’auraient put-être réalisé sans l’utilisation du scope Request. Donc il est rarement utilisé mais peut parfois s’avérer salvateur pour répondre à certains besoins.
Enfin, en ce qui concerne le CPU, je suis en partie d’accord. C’est clair que JSF est gourmand, mais la lenteur, avant même le CPU, est du à la taille de la pile d’appel par laquelle passe la requête. Pour chaque composant, nous avons le schéma (simplifié) suivant : decode de tous les composants du dernier fils au premier père – action du managed bean – encode begin – encode children (donc du première père au dernier fils) – encode end. Je passe bien entendu outre les classes de tags et les classes UI qui rajoutent encore de nouveaux process. Et bien sûr, je ne parle pas des traitements accessoires qui pourraient survenir : validateur (au niveau du composant), listener (au niveau de la requête… ouille), intercepteur etc… Donc là dessus, c’est un sacré labeur. D’autant que le renderer peut-être exécuté plusieurs fois (un comportement dont je n’ai toujours pas compris l’intérêt même s’il n’a pas d’impact sur le résultat final puisque le résultat des parcours annexes n’est pas validé).

Enfin, voilà. Il s’agit de mon avis sur ce Framework que j’apprécie bien que je conçois tout à fait qu’il n’est ni le plus performant, ni le plus productif sur des prestations spécifiques.

j’ai lu votre article , j’ai téléchargé le projet et je l’ai decompréssé dans les plugins d’eclipse puis j’ai lancé eclipse pour testé le plugin mais j’ai rien remarqué !
en fait j’ai pas compris où va apparaitre la modification apporté par le plugin .

ce que je vais faire dans ma tâche c’est un plugin qui me permettra d’ajouter un nouveau type de projet lors de la création tout comme les projet java . Meme objectif que hodac

merci de m’aider je débute avec les plug ins java et pour le moment je trouve pas de solutions