Toujours un plaisir de te revoir au hasard des évènements Java middleware. Et merci pour montrer toujours autant d’enthousiasme pour nos produits et notre vision

Je voudrais juste préciser quelques points de ton article:

>>> »et le support basé à Neuchâtel »

En effet je suis base en Suisse mais on ne peut pas dire que l’infrastructure Support de RHT pour la division Middleware soit basée a Neuchâtel.
Les centres officiels de Support des trois divisions de RHT (Systems, Middleware, Infrastructure) qui consistent le backbone sont bases aux Etats-Unis, en Angleterre et en Australie. Ces centres possèdent une infrastructure téléphone et informatique haute disponibilité pour garantir un support en 24/7 toute l’année. Pour assurer des temps de réponse les plus courts et pour répondre a la demande de pays avec des besoins localises spécifiques, nous avons également développe un réseau de compétences depuis certains autres bureaux RHT comme Tokyo ou Beijing par exemple. L’ensemble offre un maillage mondial extrêmement puissant et agile.

>>> « Il est utopique de penser qu’aujourd’hui un client final met en production une version sans prendre du support. Ceci non pas pour des raisons techniques, mais avant tout pour des raisons… légales »

Absolument. La couverture légale est un des nombreux avantages de notre offre de support, au cote de la fourniture de corrections de bug en quelques heures en cas d’urgence, l’accès aux binaires officiels et bien sur des mises a jour régulières via les CPs (Cumulative Patches).
Je recommande la lecture de: http://www.redhat.fr/products/jboss/benefits/

>>> « La version Enterprise Application Platform (EAP) est strictement identique à la version open-source de JBoss, JBoss Application Server. »
Oui et non. Pour comprendre la valeur de nos produits et nos offres Enterprise, il faut rappeler qu’il y a une séparation tres nette entre les projets communautaires JBoss disponibles sur http://www.jboss.org et les Platforms et Frameworks Enterprise supportes et accessibles seulement aux clients RHT/JBoss. Autrement dit, comme son nom l’indique, Enterprise Application Platform est une plateforme de production et de developpement basée sur plusieurs projets JBoss dont AS, Hibernate, Seam, etc…
Pour illustrer mon propos je recommande de jeter un œil au diagramme « community-vs-enterprise » visible ici: http://www.jboss.org/projects/community-enterprise.html

Et voici d’autres pages qui donnent plus de détails sur nos offres Enterprise:
http://www.redhat.fr/products/jboss/platforms/
http://www.redhat.fr/products/jboss/frameworks/

Au plaisir,

Luc Texier
Manager JBoss Support

(et desole pour les accents, je suis sur un clavier qwerty la…)

Une remarque néanmoins : je ne suis pas d’accord sur l’importance de créditer Gavin King de la paternité de Seam.
Même le créateur d’Hibernate peut se tromper, et un framework génrial peut être créé par un parfait inconnu.

Comme le disait Stephen King (qui a écrit autant d’excellents romans que de mauvais bouquins) :  » ce qui compte c’est l’histoire, pas celui qui la raconte ».

Je vous laisse transposer la citation au monde informatique

Bruno

Je ne suis pas complètement d’accord sur le retour fait sur la formation Seam donnée. La présentation de Malik était une présentation très courte. Il faut souligner qu’il a bien expliqué les principes d’unification apportées par Seam pour
l’intégration entre JSF et EJB. Couplé a la démonstration du concept de conversation, cela suffit pour comprendre l’intérêt de Seam. Ajouté avec la présentation de la possible intégration ave l’éventuel des composants de type Wicket, GWT, iText, …
ela suffit pour présenter Seam et se faire une idée de son fonctionnement.
De plus, si on est resté à la troisième mitant, on a eu l’occasion de discuter avec lui des différentes problématiques.

Et donc en conclusion, une très bonne soirée JBoss Seam pour ma part.

Quant à la présentation de code sur les slides, ou de démo « live » avec écriture et exécution de code :
- peut-être faudrait-il imposer un format pour le code Eclipse, qui permette de lire le code à la projection (taille des caractères notamment, mais aussi probablement limiter le nombre de colonnes sur lequel on écrit le code)
- il faudrait trouver le moyen, à côté des slides, de publier le code source présenté. C’est un peu frustrant de ne pas les avoir.

Sinon je regrette que Malik ait commencé sa présentation par « je viens de découvrir le truc mais vous allez voir c’est génial », ça tue un peu le reste, surtout si on fait une présentation très technique.

Enfin c’est vrai que le fait que Seam soit une invention de Gavin King est important. Ca veut dire que l’on va se faire insulter à chaque question posée sur le forum Seam. (ok c’était mon rant…)

Coté buffet j’ai mis au point une stratégie qui marche bien : derrière la grande table
Merci à Redhat pour le buffet.

Le débat est ouvert sinon : comment faire pour gérer 200 geeks passionnés en respectant les consignes de sécu ? et sans se faire jeter de l’ISEP ?

Ravi de t’avoir rencontré hier soir ! Ce fut bref, j’espère avoir l’occasion d’échanger à nouveau avec toi.

Ton CR de la soirée est excellent ! Je me permet de relever un point néanmoins OSGi a bien un lifecycle ! Celui des bundles:
– INSTALLED
– RESOLVED
– STARTING
– ACTIVE
– STOPPING
– UNINSTALLED

Sacha Labourey a surtout évoqué le fait qu’OSGi dans sa version actuelle, la 4, ne fourni pas de hooks permettant d’intercepter le fonctionnement du framework comme la recherche ou la publication d’un service.

Et bien, la prochaine version de la spec OSGi, la 4.2, qui en est aujourd’hui à son 2e draft traitera et incluera des SPI permettant non seulement d’écouter mais aussi d’influer sur le fonctionnement du framework. Il sera alors beaucoup plus simple de proxier des services ou encore d’intercepter les invocations des méthodes de services.

Aujourd’hui, un framework comme Newton par exemple, un framework OSGi distribué, est obligé de jongler pour pouvoir intercepter les invocations de services et les transformer en invocations distantes. Demain, il pourra simplement implémenter l’écouteur FindHook OSGi 4.2 pour renvoyer un proxy distant.

A la prochaine,

Cédric Vidal
http://www.linkedin.com/in/cedricvidal

PS: Le diagramme complet du lifecycle des bundles OSGi:
http://t-templier.developpez.com/tutoriel/java/osgi/osgi1/images/cycle-vie-bundle.png

Newton:
http://newton.codecauldron.org/

En tant que JUG Leader, la soirée d’hier a été mitigée :

* Déjà, ça commençait mal avec le vidéo projecteur. Ensuite, les télés qui ne fonctionnaient pas, puis une engueulade avec la sécurité pour qu’ils nous laisse 15 minutes de plus (quitter à 22h45 au lieu de 22h30)
* Une salle trop pleine. Ormis les pb de sécurité que commence à nous rappeler l’ISEP (la salle est taillée pour 180 personnes), ce n’est pas agréable de voir des gens debout ou mal assis.
* Pas assez de temps pour pauser les questions
* Pas le temps de distribuer nos goodies
* Tout ce stress nous a fait oublier de faire passer qques messages
* La salle buffet trop petite pour tout ce monde
…

Sinon, que du bonheur d’avoir un Sacha nous parler de JBoss et de papoter au Fastaff une bière à la main

Le JUG est-il victime de son succès ? 2009 nous le dira.