new Blog( perso );

Hibernate tente de détecter la présence de Hibernate-validator, et si c'est le cas active ses fonctions optionnelles. JBoss a eu la bonne idée de nous coller d'office un Hibernate dans son serveur d'appli, comme si nous n'étions pas capable de choisir nous même nos outils. Le Hibernate-validator détécté au runtime est celui de JBoss et évidement incompatible avec la version d'Hibernate que j'utilise.

Autrement dit, le "conteneur" me rend là un magnifique service en m'obligeant à intégrer une version plus récente d'Hibernate-validator que je n'utilise pas. Je vous passe les problèmes de parser et d'API XML et les diverses Error associées. Même si après tout c'est ce qui me fait gagner ma croute vu que peu de gens comprennent de quoi il s'agit, je me passerais bien de perdre des heures sur ce genre de sotises.

Question 1 : pourquoi le serveur d'appli devrait-il nous fournir des frameworks, nous privant ainsi du choix d'une version précise ? Il est difficile de faire une mise à jour de serveur sur des machines mutualisées, je me suis coltiné un Websphère 5.0 pendant des années pour cette raison. 

Question 2 : Pourquoi le classloader isolé (parent-last) n'est-il pas le mode de fonctionnement par défaut ? Tous ceux qui ont galérés avec commons-logging savent de quoi je parle

Question plus fine : pourquoi le serveur d'appli héberge t-il l'application et pas l'inverse ?

Dans la majorité de mes applis, en dehors de l'API servelt et d'une DataSource le serveur d'appli ne sert pas à grand chose (je suppose que ces fonctions d'exploitation sont mise à profit par mon client). Pour la DataSource, un bon commons-dbcp fait très bien l'affaire et économise les raffinements de la configuration des liens JNDI. Pour l'API servelt, je préférerais autant démarer au sein de mon application un service d'écoute HTTP, un Jetty embedded ou équivalent, quitte à ce que la classe associée soit configurable.

Spring DM Server de ce point de vue me décoit un peu car il ne remet pas en cause cette structuration des applications dans un conteneur (et je reste perplexe sur l'intérêt d'OSGi). J'attendrais du serveur d'application idéal de fournir des services à la carte, mais surtout rien de plus. En gros une JVM++, pas une de ces usines à gaz auxquelles JEE nous a habitués.