Aller au contenu | Aller au menu | Aller à la recherche


Tout ce qui parle de programmation et même un peu plus large que ça...

Fil des billets - Fil des commentaires

lundi 7 octobre 2013

Atelier forge à l'AgileTour : préparez vos machines !

Michäel Pailloncy et moi allons animer un atelier lors de l'AgileTour Toulouse 2013, jeudi 10 octobre (cf. les détails de la session). Oui, c'est dans 3 jours :-).

Quelques informations complémentaires si vous prévoyez de venir à cet atelier :

  • sachez qu'il nécessite absolument un ordinateur. Si vous n'en avez pas, libre à vous de venir avec un ami qui en a un, mais ce sera probablement moins intéressant pour vous.
  • vous devrez aussi disposer d'un client Git fonctionnel (nous clonerons un dépôt local fourni sur la clé USB car nous n'aurons pas accès à Internet).
  • la machine devra posséder un JDK en version 7 installé. Nous en fournirons les binaires sur une clé USB, mais vous gagnerez beaucoup de temps si vous n'avez pas à le faire en début de TP.

Cf. aussi le dépôt GitHub suivant et son README

Si vous avez besoin de précisions, n'hésitez pas à me contacter via Twitter ou dans les commentaires de ce billet.

Merci de votre attention, faites passer le message :-).

mardi 2 août 2011

Want to push your git changes, but no connection on Holiday? No worries, git bundle is here !

I’m currently writing this article offline, since I’m in a place where even phones don’t work fine. Imagine the following situation:

  • Granted, it’s the summer, but outside the weather is more suited to the frogs than to the human beings…;
  • Your laptop is sitting next to you, waiting for you to tackle this long overdue task on a dev project ;
  • You use git, but your Internet connection is between lacky and inexistent. Your only way to receive updates is to regularly take your computer to some place where the network is a bit better (so you can sync your emails, for example).

So, what you would like to do is quite simple: work offline with git (it’s one of its best forces, right?), then push a mail somewhere with your commits. To do that, you have many possibilities:

  • Zip -9 your repository and send it as attachment!
    • Ahem, mine is 400MB. Forget about it.
  • Git request-pull/am/format-patch to send mails and integrate them automatically on the other side
    • Requires too many configurations for what I want.

So what’s left? git bundle. Let’s have a look at the documentation:

git-bundle - Move objects and refs by archive

Ahem, well, not very explicit if you ask me. Let’s look at the description:

Some workflows require that one or more branches of development on one machine be replicated on another machine, but the two machines cannot be directly connected. This command provides support for git fetch and git pull to operate by packaging objects and references in an archive at the originating machine, then importing those into another repository using git fetch and git pull after moving the archive by some means (e.g., by sneakernet).

More interesting.

I’ll rephrase it: we’re going to create a special archive, containing only the commits I want, and finally send it as an attachment. People receiving this mail will be able to just pull from this archive, as from a normal repository! Sounds great, doesn’t it?

So, how to use it? Here’s my use case: I have to do some kind of code review. So I’m gonna create a new branch from the main one “develop”, I’ll call that new one reviewFeatX. Then, that‘s at least the content of this branch I’d like to be able to send.

The principle

For bundling to be efficient and interesting, it’s assumed that both repositories have a common basis. That’s quite obvious anyway: if the repository you’re working on is totally new, then you are likely to have to send it in its entirety. Sending “some commits” only makes sense when there’s in fact commits already present in both places. A Git Tree

Thanks to git’s “everything-is-a-sha” policy + every commit has a parent, it’s quite easy for it to find the link between your work tree and another one.

Creating the archive

Looking at the picture above, what we would like to do is quite obvious: send the blue part as an archive, and not a lot more if possible. Now, how do we do that?

$ git bundle create ../reviewFeatX.gitbundle develop..reviewFeatX

Notice the “develop..reviewFeatX”: this part will be passed through the git rev-list command, which will in fact return all the hashes (sha) corresponding to the blue part above in the diagram. Now you have a reviewFeatX.gitbundle file that you can send by email, dropbox or whatever you want.

Using the archive

On the other end of the pipe, someone is hopefully going to want to retrieve commits from the file. Here’s how to do that:

  • First, you can just check if the bundle contains enough information to apply to your repository (that is: your local repository contains at least the commit basis onto which the bundle was created)
$ git bundle verify ../reviewFeatX.gitbundle
The bundle contains 1 ref
8c7feeb8d13233a466459cffc487ca08334af838 refs/heads/reviewFeatX
The bundle requires these 1 ref
6807f3ac794d72a410ac23fa8e2dc5c0bbd6c422 some log
../reviewFeatX.gitbundle is okay
  • So now, we can just apply it! To do that, just use the bundle as a remote repository.
$ git ls-remote ../reviewFeatX.gitbundle
1fd7         refs/heads/reviewFeatX

$ git fetch ../reviewFeatX.gitbundle reviewFeatX:reviewFeatX
From ../reviewFeatX.gitbundle
 * [new branch]      reviewFeatX -> reviewFeatX

$ git branch
* develop

$ git checkout reviewFeatX
Switched to branch 'reviewFeatX'

$ git log --oneline develop..reviewFeatX
1fd7 log3
df56 log2
abc1 log1

That’s it! You’ve now imported the commits from the bundle you received by mail.

As said in the introduction, you see there’s many ways to exchange commits. I hope you’ll have found this one interesting and that it will be useful to you.

dimanche 16 janvier 2011

Configure Hudson CI Server to automatically disable itself when main SVN repositories become unreachable

Note: I wrote this post some months ago, and just made it public since the problem making it impossible to use was fixed some weeks ago. In the meantime, you should also be aware that Hudson has recently been renamed to Jenkins, and its new house is now

Sometimes, we encounter erratic issues accessing our subversion repositories. Even apart from the server upgrade information that just dont reach the interested people, but only managers who didn't forward (since there're obviously not the ones that use the dev server...), we also have random problems like everyone.

The problem

When SVN becomes unreachable, every one starts receiving mails about it from Hudson... For example, last week-end I received 6000+ emails about that. So, I wrote this small script to update all our jobs to not run during both the night and the week-end.

But sure, this won't solve everything. For example, if the server goes down during a working-day, and you're not in front of your computer for some reason. When coming back to your box, you might discover the big amount of mails from Hudson, or even from the devs if you're in charge of operating the CI server.

So I've been looking for a way to just automatically disable Hudson builds when a problem is detected.

The solution

For some days now, I've been playing with the Hudson script console since I discovered how greatly powerful it can be.

My starting point was the hudson command used to prepare a shutdown. How to do it through the groovy console? I gave it here in one tweet: hudson.model.Hudson.instance.doQuietDown(). Once I found this, I just had to find a way to interact with the SVN inside the groovy/hudson console system and build around it a small groovy script.

After some struggle about how to programmatically use SVNKit (Subversion pure Java API), and then how to use an anonymous class with Groovy, I was done.

Here's the resulting script:

import hudson.model.*
import org.tmatesoft.svn.core.*
import org.tmatesoft.svn.core.wc.*

String[] repoToCheck = ['svn://svn/scle', 'svn://svn:3691/pgih']

class MyHandler implements ISVNDirEntryHandler
  def void handleDirEntry(SVNDirEntry dirEntry)
    // nothing
Map<String, Throwable> problematicRepos = new LinkedHashMap<String, Throwable>();
for(String repo:repoToCheck)
  SVNURL url = SVNURL.parseURIDecoded(repo);

  SVNClientManager clientManager = SVNClientManager.newInstance();

  SVNLogClient c = clientManager.getLogClient();
    // Special groovy anonymous class construct
    def handler = new MyHandler()
    c.doList(url, SVNRevision.UNDEFINED, SVNRevision.HEAD, false, false, handler);
  catch (Exception e)
    problematicRepos.put(repo, e);

  for(Map.Entry<String, Throwable> entry:problematicRepos.entrySet())
    println("Problem accessing \""+entry.getKey()+"\"");
    String s = entry.getValue();
  println("Disabling hudson build")
  return 1
  println("No problems with repos");

How to install and configure it

Install the Groovy Plugin for Hudson. This way, you'll be able to add job directly written in Groovy. Then create a job that will run every minute! ("* * * * *") and put the script above inside an "Execute system Groovy script".

Then, configure the notification you like. It's probably a good idea to target admin email when this jobs fails. That's what I did.

Important note: there used to be a difference of behaviour with classloading between "groovy script console" and "groovy system script" in a job. This made the script above unable to work. The good news if that it was fixed with Hudson 1.352 and HUDSON-6068. So the bad news is that you can't use this technique if you're using an older version (time to upgrade? ;-)).

Possible improvements

Sure the script isn't perfect, here's a few thought of what's currently missing:

  • At the moment, watched repositories are explicitly declared in the script. Maybe it would be more interesting to iterate through the whole list of jobs to find the actual used repositories. But I feel this approach might be a problem: if only one job is failing, maybe the team HAS to be notified. You're not going to disable the whole hudson instance (or even cluster) for only one job failing, right?
  • About svn :
    • this is the only supported scm in the script above
    • Only the "svn" protocol is supposed to be supported. If you want to access http exposed repos, then you might have to also initialize the webdav subsystem by calling DAVRepository.setup() first.
  • Groovify the script a bit. I first wrote it in Java, and then adapted it a bit to be more groovy-like, but my experience in Groovy is only about two weeks, so please be indulgent.

Hope this helps!

mercredi 17 mars 2010

Mon avis sur le livre "Apache Maven" de Nicolas De Loof et Arnaud Héritier

J'ai lu le livre Apache Maven, édité chez Pearson. Pour un premier livre en français sur Maven, on peut dire que l'expérience est globalement très réussie.

Mon expérience de maven

Disons-le tout de suite, je ne suis pas néophyte sur Maven. J'ai été utilisateur de maven 1 un tout petit peu (preuve ici :-)), avant de me plonger dans maven 2 depuis maintenant plusieurs années. Bon, ça c'est fait. J'espère que vous comprendrez que là, je veux pas me la péter hein. Je veux juste dire que nombre de concepts du livre m'étaient déjà connus. Et que, donc, mon analyse ne sera forcément pas celle d'un nouvel arrivant sur Maven.

Le style du livre

J'avoue que j'ai trouvé la lecture très agréable. C'est volontaire de la part des auteurs, et c'est réussi. Ils ont réussi à apporter beaucoup de concepts dans un style facile à lire. Ils ne sont pas tombés dans le piège de la documentation de référence, parfois un peu dure à lire, voire carrément chiante, qu'on n'ouvrirait que pour y faire un grep sur ce qu'on cherche (et ce n'est à mon sens pas le but pour un livre papier).

Le livre se lit un peu comme un roman : un petit projet débute, et rencontre les problèmes classiques du packaging qui devient une usine à gaz, et que seul celui qui l'a développé (et encore) peut lancer. Au fil de l'eau, on explique donc comment fonctionne maven (et pourquoi il a été créé), comment packager simplement, etc. Ensuite, on se rend compte que l'écriture et le lancement de tests est fastidieuse, alors on explique comment ajouter des tests, et ainsi de suite en décrivant la mise en œuvre de choses de plus en plus complexes.

La structure et le contenu du livre

"Premiers pas avec Maven"

La première partie introduit maven, d'où il arrive, qui l'a créé et pourquoi. Exemple : un projet, quel qu'il soit (et dans quelque langage que ce soit), rencontre presque toujours les trois besoins suivants lors de sa construction : préparer la construction (initialisation), compilation, puis assemblage.

Tout y est, "convention-over-configuration", la notion de dépendance, la transitivité, les scopes, les classifiers, etc... Et tout passe comme une lettre à la poste. Vraiment, je le redis : l'exploit de Nicolas et Arnaud réside dans la capacité à nous permettre de lire le livre sans avoir l'impression de lire une documentation technique.

Comme je le disais sur twitter, je pense que ce livre est un outil formidable sur lequel s'appuyer pour préparer des sensibilisations à Maven dans vos boîtes. Mais surtout, CITEZ VOS SOURCES !!! :-)

Dans la première partie, on la jouait petit. En tant qu'utilisateur expérimenté de maven, ça m'a surtout donné envie de voir comment on pourrait déployer Selenium et FitNesse en IC chez nous.

"Maven en entreprise"

Là, on commence à ouvrir les vannes. Le projet est devenu complexe : comment gérer les dépendances proprement avec un repo manager, centraliser les informations dans un pom parent, utiliser Maven dans l'IDE.., et on arrive enfin à "mais diantre, comment on release un projet avec Maven ? On pourrait pas gérer automatiquement ces actions répétitives, rébarbatives qu'on se tape à chaque livraison, et sur lesquelles on se trompe une fois sur deux ?".

"Encore plus loin avec Maven"

On lâche les chevaux : écriture de plugin maison, comment le tester, intégrer de l'assurance qualité (analyse de code, couverture de code), la génération des rapports et enfin on parle de Sonar, la rolls de l'analyse qualité d'un projet.

Une fois la partie "technique" terminée, Arnaud et Nicolas se livrent même à l'exercice périlleux de prédiction : Maven 3 et consorts (Encore bon pour le moment : Maven 3 à attendre plutôt pour fin 2010, d'après le livre imprimé en novembre 2009. On en est à l'alpha-7 à ce jour.).

Les reproches

Il en faut, sinon, vous allez penser que je ne suis pas objectif :-).

  • Tests d'intégration : les mettre dans le projet, ou dans un projet externe ? Le livre dit que les deux approches sont valides, mais sans creuser. J'aurais aimé davantage de retours sur le sujet. Au moins essayer de donner des pistes ou des exemples sur quelle stratégie plutôt adopter qu'une autre dans une situation en particulier. Ou même simplement l'avis d'Arnaud et de Nicolas (je suis sûr que vous en avez un :)) si aucun consensus n'existe effectivement.
  • Problèmes d'impression en N&B : je suppose que quelques captures ou diagrammes (exemple : p.206, un des écrans de sonar) ont dû être envoyés à l'éditeur en couleur. Le passage au noir&blanc les rend peu lisibles (essayez de différencier du bleu et du vert une fois dans des nuances de gris...). Je pense qu'il aurait fallu soit vérifier la conversion au noir&blanc, soit voir avec l'éditeur pour imprimer en couleur au moins ceux-là (je suppose que ça permet de baisser le prix de revient du livre).
  • Évolution de Maven 3 : pouvoir référencer un pom parent sans version. Le problème de la poule et de l'œuf de Maven. Cette évolution me paraît à la fois intéressante, et en même temps pose question. En effet, l'une des forces de Maven est qu'il est actuellement possible de checkouter un seul module (et non tous) et de travailler dessus. Un peu comme SVN, on peut checkouter n'importe quel niveau, et Maven s'y retrouve très bien. Je suppose que si la version parent n'est plus spécifiée, il devient impossible de checkouter de cette façon. Je pense que ce sera comme ça, mais j'aurais aimé quelques détails sur le sujet.

Mon impression générale

Dans la description de ce petit projet devenu gros, j'ai retrouvé une très grande partie des choses que nous avons faites chez nous. Je pense que certains choix n'ont pas toujours été faits immédiatement, et la lecture d'un tel livre nous aurait économisé pas mal de temps et de recherches (le release-plugin marche très bien, une fois qu'il marche. Mais il peut être difficile d'initialiser les premières releases, où il y a toujours un truc qui plante au milieu).

Petit bonus en prime : le style adopté, et la partie à la fin du livre vous donnent l'impression de connaître tout le monde, de faire un peu partie de la famille :). Maintenant on connait l'âge de tous les développeurs francophones de Maven, même celui de Vincent qui a tenté un chiffrement en héxa :-).

Globalement, donc, je recommande chaudement ce livre à toute personne qui utilise maven et qui souhaite maîtriser l'outil. Le livre offre un accès facile à toutes les facettes du projet, des plus simples au plus avancées, sans omettre le côté humain qui est si important dans les projets opensource.

mercredi 13 janvier 2010

Comment connaître la provenance d'une classe programmatiquement en Java

Il est possible par programmation de savoir d'où vient une classe : un jar ? un répertoire ? autre ?

Use case classique : vous pensez (et devez) ne plus avoir les commons-logging nulle part dans votre classpath, parce que vous êtes (intelligemment :-)) passés à SLF4J. Malgré cela, il semble que cette fichue classe soit toujours trouvée, mais vous n'arrivez pas à savoir dans quel jar (ou quel répertoire si vous travaillez directement avec les .class). Résultat, ça vous fout un bazar monstre dans la configuration de vos logs. Certains continuent à apparaitre alors que vous avez demandé à ce qu'ils ne soient pas affichés...

Le code est un peu sioux, alors je le mets ici au cas où ça vous servirait :


MAJ du 15/03/2010

Suite à l'incompréhension ci-dessous, voici quelques exemples pour illustrer ce que fait ce code :

Le code :


Affiche sous Windows :


J'espère que l'utilité est un peu plus claire à présent.

mercredi 23 décembre 2009

Vu aucune différence de performances entre firefox 3.5 et les versions précédentes : vous utiliseriez pas Firebug ?

Par le plus grand hasard, pendant la lecture d'un billet de Pascal sur les performances de firefox au fil des âges, je viens de m'apercevoir que je ne profitais en fait pas de TraceMonkey, le compilateur JIT intégré à Firefox depuis la 3.5 !

C'est vrai que je n'avais pas fait très attention, mais que je n'avais pas non plus remarqué d'amélioration notable sur mon navigateur favori. En fait, c'était à cause du fait que j'avais, comme tout bon développeur qui se respecte :-), installé firebug depuis déjà un bon moment.

Sur le blog de Pascal, la phrase suivante m'a donc fait tilter :

Un petit rappel si vous utilisez Firebug, votre moteur de compilation JIT de javascript est désactivé et vous aurez donc des perfs équivalentes à celles de Firefox 3.0, même si vous êtes en 3.5. La version 1.5beta7 de Firebug sortie hier devrait résoudre ce bug.

Aussitôt dit, aussitôt fait. J'ai installé la version 1.5X.0b8 de firebug et j'ai tout de suite vu effectivement une différence. Gmail, Google Reader, Hudson, tout s'affiche plus vite.

Comme j'avais fait le test SunSpider avant la mise à jour, en gros, je peux vous dire que je suis passé de 3500 à 1500 !

Bref, installez-vite cette mise à jour !

mercredi 18 novembre 2009

Apache Subversion

Tiens, j'avais raté cette news (300 billets en attente dans mon google reader :-/, que je n'arrive à dépiler que 10 par 10. Ça ne suffit pas :-)) : Subversion a intégré l'incubateur d'Apache.

En français, ça veut dire que bientôt, Subversion sera un projet faisant partie entièrement de la fondation Apache. Subversion n'arrête pas son ascension, et c'est logique vu la qualité de l'outil.

vendredi 9 octobre 2009

[Hudson] How to set a private maven repository by job and easily be able to delete them

When building maven projects with hudson, there's some common best practices about maven repositories handling :

  1. isolate maven repositories between jobs
  2. regularly purge repositories

The problem

The basic way to do it is to activate the hudson per-job option : "Use private Maven repository". But the thing is you have to do it for EVERY new job you add. There is no way inside hudson to activate it globally.

Documented solution

If you look at hudson help for this option, you'll see a link to a simple solution that specify the repository directly in the maven settings.xml file. The tip is to redefine the localRepository tag inside settings with this special value :


This way, you're done with the first best practice : isolate maven repositories. But not yet with the regularly purge repositories one. Actually, using this option will put the m2_repo inside each hudson job workspace. So, finding and deleting them could become a bit cumbersome. You'd have to cron something like find . -name m2_repo -exec rm -rf "{}" \;.

Even better

As you might have understood, I was not thoroughly satisfied with this solution. I wanted to be able to really easily delete the repositories. So I just changed the option above to have them all inside the same root directory under ~/.m2/repositories, one per job.

Quite simple in fact, instead, just use :


This way, the only thing you have to put in the cron job is rm -rf /some/path/.m2/repositories/. A bit more straightforward, isn't it? :-)

Hope this helps.

jeudi 10 septembre 2009

Encodages/jeux de caractères : Vincent et Hadrien, un grand merci !

Non, ce billet n'est pas une nouvelle tentative d'explication de ce que sont encodages et jeux de caractères. Je garde toujours dans un coin de ma tête de chercher un jour à écrire moi aussi un billet sur le sujet. Qu'est-ce j'aimerais pouvoir faire comprendre ce sujet à la fois simple et complexe à tous en quelques mots...

Non, ce billet est là pour remercier Vincent et Hadrien pour leurs pages récapitulant les jeux de caractères les plus courants en France. Je viens de m'en servir à l'instant pour expliquer une nouvelle fois le sujet.

Un autre site bien pratique, qui permet notamment d'avoir la valeur hexadécimale du stockage d'un point de code Unicode en UTF-8 : FileFormat.Info. Par exemple, le î (''LATIN SMALL LETTER I WITH CIRCUMFLEX'').

Et encore un rappel d'articles en français que je vous conseille sur le sujet :

vendredi 29 mai 2009

JSR 330 : Dependency Injection for Java

Récemment, SpringSource (Rod Johnson, créateur de Spring) et Google (Bob Lee, coauteur de Guice) lançaient une proposition de JSR visant à standardiser un jeu d'annotations pour gérer l'injection de dépendances.

Cette proposition, « Dependency Injection for Java », est devenue une véritable JSR depuis 3 jours.

Personnellement, j'ai hâte de voir ce qui va ressortir de ce travail. Notamment, je regarderai attentivement en quoi cela complètera ou s'intégrera avec les annotations de common annotations (JSR 250, dont sont notamment issues @PostConstruct, @PreDestroy, @Resource) et éventuellement les annotations de la spécification des EJB3 (@TransactionAttribute, notamment).

Comme la spécification sera développée avec un scm et une liste de diffusion accessibles publiquement, j'essaierai de vous en dire plus à ce sujet dès que possible.

À suivre.

lundi 11 mai 2009

Java User Group Toulouse : première conférence

Pour ceux qui n'auraient pas encore vu passer l'information, demain soir a lieu la première session du JUG toulousain. Vous êtes évidemment les bienvenus !

Au programme, GWT et Java ME.

À demain !

mercredi 25 février 2009

Eclipse Killer Feature (un de plus) : formatage automatique du code modifié

Voilà pourquoi j'utilise Eclipse, pour ce genre d'apports qui peut paraître mineur au premier abord, mais qui en fait nous change la vie.

Lorsqu'on développe dans une équipe, on souhaite généralement appliquer entre autre des normes communes de formatage. Dans Eclipse, le Ctrl-Shift-F permet d'exécuter le formatage sur le fichier (ou sur toute une arborescence) selon le modèle qu'on aura défini et chargé au préalable.

Le Ctrl-Shift-F a cependant un défaut : sans sélection préalable, il va formater le fichier complet. La fois suivante que vous envoyez vos modifications aux gestionnaires de version (commit avec svn, par exemple), les développeurs qui récupèrent votre modification peuvent se demander pourquoi vous êtes allé modifier tout le fichier pour une simple faute de frappe...

Autre cas encore plus problématique : vous faites du développement MDA. Une partie plus ou moins importante de votre code est donc générée. Vous ne devez donc a priori surtout pas toucher au code en dehors de ce qu'on appelle généralement le code utilisateur (on retrouve ce principe avec acceleo il me semble). Du genre

// Ici, le code modifié manuellement sera écrasé par le générateur.
// Là, le code ne sera pas écrasé à la régénération suivante.

Depuis la 3.3 d'Eclipse, dans la partie Java/Editor/Save Actions de Window/Preferences, on peut demander à ce que le code qu'on vient de modifier soit automatiquement formaté... C'est pas formidable, ça ? À chaque Ctrl-S, le code modifié et uniquement celui-ci va subir le formatage adéquat... Via cette fonctionnalité, vous pouvez automatiser tout plein d'autres choses au moment de la sauvegarde, je vous laisse jouer avec :-).


vendredi 30 janvier 2009

Java User Group Toulouse

Via Sami, j'apprends ce matin que ça y est, le JUG Toulouse est né. Je me suis d'ores et déjà inscrit à liste de diffusion.

J'espère que je trouverai le temps de participer à ce groupe malgré les importants travaux à faire dans la maison que nous venons d'acheter.

PS : Sami, merci encore pour la bétonnière :-).

lundi 22 décembre 2008

Drop sequences for Oracle

Adam already showed how to generate all the drop table statements (impossible to trackback):


As I just needed to drop sequences, based on Adam's query, here's the necessary:

SELECT 'drop sequence '||sequence_name||';' FROM USER_SEQUENCES;

Quite straightforward indeed.

Hope this helps.

dimanche 13 juillet 2008

How to retrieve the Hibernate Session from the EntityManager interface

Well, as I myself fell into this stupid gap, I guess I'll try to help. I was quite pushed in this trap by a fallacious part of the jboss documentation :

@PersistenceContext EntityManager entityManager;
public void someMethod();
  org.jboss.ejb3.entity.HibernateSession hs = (HibernateSession)entityManager;
  org.hibernate.Session session = hs.getHibernateSession();

Let's be clear : this is totally WRONG! Yes, it will work under JBoss, but as there's a standard way to do this, this is not the right way to do this.

In fact, there's a dedicated method that lets you retrieve the underlying persistence manager : EntityManager.getDelegate(). If you read this method's javadoc, you'll see the following :

 * Return the underlying provider object for the EntityManager,
 * if available. The result of this method is implementation
 * specific.
 * @throws IllegalStateException if this EntityManager has been closed.

public Object getDelegate();

And the "underlying provider", for Hibernate, is obviously the Hibernate Session instance...

So, the right way to retrieve the Session is something like the following instead :

@PersistenceContext EntityManager entityManager;
public void someMethod();
  org.hibernate.Session session = (Session)entityManager.getDelegate();

Under JBoss, using this code won't make a big difference. But using the standard way will let you run your code under several appservers (namely, it works like a charm[1] under JBoss and Glassfishv2ur1 for example). If you use the bad way above, this will just crash under Glassfish, for example...

I reported the corresponding documentation bug in the JBOSS tracker.

Hope this helps...


[1] ça, c'est pour Seb

- page 1 de 4