Dans l'application sur laquelle je travaille, on se retrouve parfois avec des SerializableProxy d'Hibernate (sans doute au moment où on sérialise nos objets pour les envoyer au client Spring remoting).Et je ne comprend vraiment pas à quoi servent ces objets. On a bien droit à la javadoc de Gavin King qui nous dit (je cite intégralement) Serializable placeholder for CGLIB proxies J'imagine donc (en particulier grâce à la présence d'une méthode readResolve, voir aussi l'implémentation chez koders) que ces objets sont faits pour être remplacés par des HibernateProxy. Seulement voilà, quand on regarde l'implémentation de readResolve, elle utilise un appel à CGLIBLazyInitializer, et en particulier à la méthode

static HibernateProxy getProxy( final Class persistentClass, final Class[] interfaces, final Method getIdentifierMethod, final Method setIdentifierMethod, final Serializable id, final SessionImplementor session)

Seulement voilà, si vous regardez attentivement le code de SerializableProxy, et en particulier la ligne 55, vous constaterez comme moi que la session passée en argument est null. Dans ces conditions, comment Hibernate peut-il recréer un HibernateProxy ? La réponse est simple : il ne peut pas. Du coup, avec un collègue, fatigués de tomber sur ces cochonneries de SerializableProxy, on a trouvé la solution : utiliser l'introspection pour récupérer tous les champs du SerializableProxy, invoquer explicitement la méthode CGLIBLazyInitializer.getProxy et travailler notre HibernateProxy pour le retransformer en objet authentique. Ca marche, mais qu'est-ce que c'est laid ! A mon sens, c'est le signe qu'on a loupé quelque chose, mais quoi ?

via Nicolas Delsaux's posterous import script