Tag Archives: java

Weblogic 8.1 + Struts

Vous développez avec cette combo?
Marre d’être obligé de redéployer votre webapp à cause d’une ClassCastException à chaque modification dans une action?

1 Tous ce que vous mettez dans la session doit être serializable. Mais ça vous le faites déjà, c’est une bonne pratique.
2 Il y a un bug dans weblogic 8.1 : le problème est décrit ici ainsi que la solution Il existe un patch qui sera intégré dans le futur sp5 à demander au support weblogic.

J’ai été impressionné par la réactivité du support Bea.

ThoughtWorks recrute ?

Je ne cherche  pas à tomber dans la critique facile de Martin Fowler qui avec des ouvrages comme Refactoring ou Uml Distilled est un “guru” du développement. Mais son dernier billet ressemble bel et bien à une pub pour sa compagnie.
En même temps je suis entièrement d’accord avec son point vue. J’y vois même un facteur important de l’échec de pas mal de projet. On ne réussit pas un projet informatique avec une équipe peu chère (car ça veut souvent dire débutant ou peu compétent). A vouloir trop réduire les coûts des projets informatiques, ils finissent par durer bien plus longtemps qu’il ne devrait et le produit final est souvent médiocre et donc peu porteur de valeur ajouté.
L’autre facteur majeur d’échec est bien entendu la difficulté qu’ont les clients à définir leurs besoins, et encore plus à les définir dans une forme qui soit exploitatable par l’équipe projet. D’où la nécessité  des méthodes agiles et des processus itératifs.

EJB design patterns

J’avais besoin de me rafraichir un peu les idées sur le EJB command design pattern et maître google m’a dégôté une très bonne ressource. Un powerpoint de 116 slides qui explique assez en détail les différents design patterns utiles lorsque l’on fait (encore) des EJB:

EJB design patterns par  Vijay Bhatt

Un indispensable si vous devez faire des EJB.
Et oui, ils sont bons ces indiens…

Code et Commentaires

“Un code sans commentaire est un mauvais code,
un bon code n’a pas besoin de commentaire…”

Si je me souviens bien ça doit venir de The Pragmatic Programmer, une lecture hautement recommendable.

Je suis tombé sur ce billet qui illustre assez bien l’idée, plutôt que de mettre de tonne de commentaires dans le code pour respecter “les normes”, mieux vaux passer un peu de temps à refactorer son code pour qu’il n’y ait plus besoin de commentaire. Il est beaucoup plus dur (mais plus efficace aussi) de trouver les 3 mots qui vont former un nom de méthode explicite que de mettre 3 lignes de commentaires au dessus de doStuff().

Attention, je n’ai pas dis qu’il ne fallait pas de commentaires dans le code, mais juste la où il y en a vraiment besoin.

XML <=> javabean = Xstream

Voici le plus court chemin pour aller d’une structure XML à des javabeans et vice-versa: Xstream.

L’outil est impressionnant  de facilité et d’efficacité. Attention il s’agit d’un sérialisateur/désérialisateur => les structures objet et xml  doivent se correspondre. Il sait traiter les types simples tout comme les collections ou les maps. Une limite, il ne reconnait pas les attributs d’un élément mais seulement les sous éléments.

Dans le même genre il y a aussi jox

Si vous voulez faire du “mapping” xml < => objet, du xml databindings, il va falloir se tourner vers des solutions plus lourdes se basant sur un XML schema comme:
– Castor XML
– XMLBeans
– ou Jaxb

Ce ne sont pas les seules solutions, en voici une liste assez complète, selon un sondage sur manageability castor XML serait la solution la plus utilisée.