juin
2008
Un article de Hikage
Avec un peu de retard, la suite de la première journée 
OSGi Programming Model
Petite introduction à OSGi, présentant les différents aspects de celui-ci : Versionning, Chargement/Mise à jour/Suppression d’un module dynamiquement.
Très bonne présentation pour les personnes n’ayant aucunes notions de OSGi
Spring Dynamic Modules for OSGi
N’ayant jamais eu l’occasion de jouer avec Dynamic Modules, j’ai hésité entre cette conférence et celle sur Spring Security 2.
Finalement, je suis plutôt content de mon choix, où j’ai eu l’occasion de voir en action la création et le déploiement de modules OSGi grâce à celui-ci.
J’ai été assez étonné de voir comment il est assez facile de créer une application simplement, sans avoir au niveau du code la moindre dépendance avec le modèle OSGi. Un service OSGi étant un simple Spring Bean.
La gestion de dépendances est particulièrement bien pensée ainsi si un module utilise un service d’un autre module il est simplement injecté. Et si pour une raison ou l’autre le module du service est temporairement indisponible, l’appel d’une méthode de celui-ci sera simplement « en attente » du retour du module.
Mieux, dans le cas de OSGi, un même « service » peut être fourni par plusieurs implémentations, et une application a la possibilité d’avoir soit le « meilleur » des candidats, soit avoir une collection des différentes implémentation et lors de l’arrivée ou l’arrêt d’une de celles-ci, la collection est mise à jour directement.
Five Aspects You Don’t Know About
La programmation orienté aspect est un sujet qui m’intéresse énormenent, c’est donc sans hésitation que j’ai suivi cette conférence.
Beaucoup plus oriénté pratique, elle présente trois ( et non pas 5 ) aspects pratiques :
Gestion des Flush de session Hibernate lors d’appel JDBC suivant un appel Hibernate : en effet, lors d’une même « transaction », si l’on effectue un appel sur les mêmes données que celle ajoutées/modifiées par Hibernate, les informations n’auront pas été mises à jour.
La cause, les requêtes Hibernate ne sont effectuées que sur le flush de la session Hibernate, qui est effectuée automatiquement lors du commit de la transaction. Il est donc nécessaire de faire le flush manuellement pour que les données soit accessible en JDBC.
Et c’est via un aspect que Alef Arendsen propose la solution.
Un autre aspect présenté permet quand à lui de récupérer la cause réelle d’une exception. N’est-ce pas possible via la stacktrace ? Non pas forcement.
Si vous avez dans le code ceci :
try {
unAppel():
}
catch(MonExceptionSpecifique e) {
throw new RuntimeException("Impossible d'effectuer l'appel");
}
}
MonExceptionSpecifique est une exception portant la cause de l’erreur. Mais le code de gestion ne remonte qu’une erreur sans encapsuler l’erreur originale. Résultat impossible d’avoir l’information.
Or, il est possible de récupérere cette information via un aspect
Enterprise Integration Patterns with Spring
Pour commencer, Mark Fisher à fait un rappel des possibilité d’intégration possible grace à Spring Core : Remoting, JMS, Scheduling.
Ensuite, il a présenter les apports fournit par Spring Integration, qui implémente certains pattern d’intégration décrit dans l’excellent livre Enterprise Integration Patterns de Gregor Hohpe et Bobby Woolf.
PS : Il est fort probable que des fautes de français et de frappe soit présente, mais j’écrit rapidement ces posts lors des breaks voir lors des sessions, donc rapidement et en écoutant en même temps les sessions. Veuillez m’en excuser
1 Commentaire + Ajouter un commentaire
Commentaires récents
- dans SpringSource acquiert Hyperic
- dans Sortie de la huitième béta de SpringSource Application Platform (S2AP)
- dans Sortie de la huitième béta de SpringSource Application Platform (S2AP)
- dans Sortie de la huitième béta de SpringSource Application Platform (S2AP)
- dans Spring One 2008 en direct – Jour 1
Alors, tu as salué Costin de ma part comme je te l’ai demandé :p ?