Le coin du développeur

Lorsqu’on souhaite lancer une WebApp avec le plugin Jetty sous Maven 2 depuis un PC sous windows on obtient une erreur référencée sous JIRA #JETTY-1063 :

java.net.URISyntaxException: Illegal character in path at index 18: file:/C:/Documents and Settings/USER/.m2/repository/org/mortbay/jetty/jetty-maven-plugin/7.0.0.1beta2/jetty-maven-plugin-7.0.0.1beta2.jar

Ce problème n’est résolu que sous Maven 3. Pour ceux qui souhaitent rester sous Maven 2 (Maven 3 est encore en version alpha), il faut modifier l’emplacement de la repository pour éviter le souci du caractère ESPACE présent dans le chemin C:\Documents and settings\USER\.m2\repository (chemin par défaut).

Il est fortement recommandé de déplacer le répertoire repository dans c:\maven2\repository par exemple et modifier ensuite le fichier settings.xml qui se trouve normalement dans C:\Documents and settings\USER\.m2 ou (moins bien) dans votre répertoire d’installation de maven sous /conf.

<localRepository>/c:/maven2/repository</localRepository>

Ainsi, Maven ira chercher les libs dans un répertoire sans espaces…

Lorsqu’on utilise Hibernate pour déléguer la gestion de la persistence, se pose alors le classique problème de l’exception LazyInitialisationException.

En effet, dans une modélisation assez classique, imaginons le cas suivant :

Couche Modèle (ou DAO)

Classe POJO contenant un attribut x et une collection cols

@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
public class Dossier {
	@Id
	@GeneratedValue
	private Long id;
	private String x;

	@OneToMany(cascade=CascadeType.ALL)
	private Collections<String> cols;
	// Getter et setters
}

Classe DAO

Voir le blog pour l’utilisation des generics de Java5 afin d’éviter d’avoir à coder toujours les mêmes méthodes CRUD.

@Repository
@Transactional
public class DossierDAO {
	@Autowired
	protected SessionFactory factory;

	public Dossier getOne (Long id) {
		Session session = factory.getCurrentSession();
		return (Dossier)(session.get(Dossier.class,id));
	}
}

Couche Métier (ou Service)

Classe Service contenant l’injection du DAO

@Transactional
public class DossierServiceImpl implements DossierService {
	@Autowired
	@Qualifier("dossierDao")
	private DossierDAO dossierDao;

	public Dossier read(Long id) {
		return dossierDao.getOne(Dossier.class.getName(), id);
	}
}

On voit ici que la transaction peut démarrer au niveau du service et que par défaut, en mode Lazy, seul l’attribut x de Dossier sera chargé.

Pour que l’application Web appelante puisse faire une itération sur la collection, il faudrait que celle-ci soit chargée.
Il est possible de changer le mode LAZY pour dire à Hibernate de tout récupérer mais pour un arbre de données assez profond, cela peut devenir désastreux.
Il est également de modifier la méthode read du service DossierService ainsi :

public Dossier read(Long id) {
	Dossier d = dossierDao.getOne(Dossier.class.getName(), id);
	d.getCols();
	return d;
}

Dans ce cas, on a déclenché manuellement la recherche du contenu de la collection…

Autre possibilité, garder la connexion avec Hibernate pendant tout le temps du traitement de la requête Web de l’utilisateur.
Pour se faire, on doit ouvrir la transaction au début du traitement de la requête pour ne la restituer qu’à la fin de la génération de la vue.

On modifie le web.xml :

	<filter>
		<filter-name>OpenSessionInViewFilter</filter-name>
		<filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>
	</filter>
	<filter-mapping>
		<filter-name>OpenSessionInViewFilter</filter-name>
		<url-pattern>*.do</url-pattern>
	</filter-mapping>

Dans cette configuration, le filtre OpenSessionInViewFilter mis sur tous les appels *.do va déclencher une ouverture de session hibernate jusqu’à la restitution de la vue.
Ainsi, si dans la JSP, on trouve une itération de l’attribut cols du bean Dossier, un appel à la base de données via Hibernate sera déclenché à ce moment là (et seulement à ce moment là).
Autrement dit, si pour une autre JSP vous n’avez pas besoin d’afficher la collection, l’appel à la base ne sera pas réalisé.

En lisant le magazine de développez.com (Décembre 2009 – Janvier 2010), j’ai découvert l’ouverture du service Google App Engine au monde Java.

De quoi s’agit-il ?

Ni plus, ni moins que ce que tout développeur Java cherche : un hébergement gratuit d’applications Java. Bon, il ne s’agit pas d’un serveur J2EE du type JBoss, Glassfish ou autre mais il permet de faire tourner des applications Web (des Webapps Java)  et de pouvoir y intégrer les outils Google.

Je viens juste de créer mon compte, de diriger mon domaine vers ce site et de faire tourner une application de base générée avec le plugin Eclipse pour google.

Je vais compléter cet article au fur et à mesure de découvertes…

Stay tuned !