01 juin 2009

container's hell

JEE n'a pas vraiment la cote auprès des développeurs qui lui préfèrent des modèles plus léger. Dernière expérience en date pour ma part : j'ai une application Hibernate, j'y ai mis la toute dernière version GA du framework, et je la "déploie"sur un JBoss un peu ancien - prérequis client oblige.

NoSuchMethodError

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.

1 commentaires:

Unknown a dit…

Peut être pour fidéliser les développeurs, car sinon on pourrait changer de serveur comme de chemise (doux rêve). Etant sur un vieux JBoss, la mutation vers une version plus récente est un travail a part entière :o(