Commentaires sur : JMS/ActiveMQ : Spring vs Grails

Par : Blog de Gildas Cuisinier » Blog Archive » Liens de la semaine

Blog de Gildas Cuisinier » Blog Archive » Liens de la semaine — Sun, 11 Apr 2010 08:15:29 +0000

[...] JMS : Spring versus Groovy Share and Enjoy: [...]

Par : Stéphane Maldini

Stéphane Maldini — Tue, 06 Apr 2010 15:37:23 +0000

La comparaison n’est pas tirée par les cheveux, l’expression que donnent Groovy et Grails change complètement la donne. Je pense que c’est ce qu’a voulu appuyer l’auteur ici.

Quant aux plugins, ce sont des initiatives généralement dérivée de travaux internes et ils sont gentiment proposés en tant que tels, à la manière d’un SDK. Il n’est pas interdit de retoucher un plugin voire de partager ses améliorations si on lui trouve des manques. Même si on rêve de ça (http://bit.ly/amceaS , mon stupide poisson d’avril) , que des amis chez spring parlent d’un futur repo gold maintenu, un développeur plugin est un développeur d’applications grails. Dés lors, tous les développeurs sont invités à contribuer à faciliter la vie des autres

Par : Piwaï

Piwaï — Tue, 06 Apr 2010 15:03:46 +0000

Intéressant, mais la comparaison Spring vs Grails est un peu tirée par les cheveux :

– Grails, c’est du Spring emballé, donc à priori on aurait pu prendre la conf Spring et la copier tel quel dans l’appli Grails.

– Ce n’est pas tant Grails en soit que le plugin associé qui facilite la configuration. En réalisant un plugin équivalent en Java, on y gagnerait aussi pour la version Spring, non ?

– Les plugins Grails, c’est bien, quand ils sont bien réalisés et bien maintenus. Si l’on prend l’exemple du plugin Acegi Security (présenté sur ce blog dans un article précédent), il est intéressant, mais dès qu’on rentre dans certains cas spécifiques de configuration il montre ses limites, et les développeurs du plugin sont aux abonnés absents.

Par : Stéphane Maldini

Stéphane Maldini — Fri, 02 Apr 2010 15:55:28 +0000

Pas mieux que le monsieur au dessus !

Par : Antoine

Antoine — Fri, 02 Apr 2010 15:34:12 +0000

De mon côté, je retiens plutôt la solution d’utiliser le plug-in JMS et de configurer à la main ActiveMQ. Il suffit de configurer un bean jmsConnectionFactory et le broker (que ce soit ActiveMQ ou un autre, embarqué dans l’application ou séparé). Je pense que le plug-in ActiveMQ n’est pas marqué comme production-ready car il ne fournit aucun moyen de configurer ActiveMQ. En configurant ActiveMQ via Spring, on retrouve la flexibilité sans perdre le bénéfice de la simplicité de configuration.

Par : Olivier Ribardière

Olivier Ribardière — Fri, 02 Apr 2010 09:43:16 +0000

Bonjour,
Je trouve cet article un peu biaisé dans la forme : on voit 200 lignes de code XML/Java d’un côté, 20 de l’autre, évidemment vu comme ça c’est tentant. Malheureusement il doit manquer des choses côté Grails : où est configuré l’URL du JMS, la taille du pool de consumer, la gestion des exceptions…
Est-on bien en train de comparer 2 choses à périmètre équivalent ?

Par : Stéphane Maldini

Stéphane Maldini — Thu, 01 Apr 2010 17:58:30 +0000

Mea culpa je parlais du plugin JMS en particulier car je n’ai pas souvent vu activeMQ embedded effectivement en prod !

Par : Amin Fathallah

Amin Fathallah — Thu, 01 Apr 2010 13:08:02 +0000

L’auteur a indiqué sur la page de documentation du plugin : http://www.grails.org/ActiveMQ+Plugin qu’il n’est toujours pas production ready.

This plugin at the moment is not production ready. Use at your risk for rapid prototyping with JMS without installing anymore.

Par : Stéphane Maldini

Stéphane Maldini — Thu, 01 Apr 2010 08:06:43 +0000

Bonjour,
Je lisais l’article sur grails activemq et jms. Je me permets juste de demander en quoi ces plugins ne sont pas production ready surtout pour grails-jms qui est le fruit d’un effort particulier de Luke Daley, un grails comitter. J’ai vu des applications en prod avec ce plugin sans soucis particulier, quelques échanges sur la mailing liste confirmeront je pense.