If you have your own HibernateSessionFactory-Impl, you create the "core-Proxy" yourself, which has access to an unproxied hibernate session.
So, I'd write an interface that extends org.hibernate.Session and adds the method Criteria reattachCriteria( DetachedCriteria dc ); which is implemented in your core-service-implementation-proxy and returns "dc.getExecutableCriteria(session);", where session is the real hibernate session, because you're inside the core service-impl. Marcus > -----Original Message----- > From: Alan Chaney [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 04, 2007 11:27 PM > To: [email protected] > Subject: Hivemind creates proxy Hibernate Session > > Hi > > I've based my Hivemind/Hibernate code on James Carman's > excellent example. I am using this in a new project in > preference to the Spring Hibernate framework because its > simpler and easier to understand IMHO. > However, I've hit one slight snag. In part of my code I use a > Hibernate DetachedCriteria object which gets associated with > a session by a Hibernate call such as DetachedCriteria dc = > DetachedCriteria.forClass(MyClass.class); > > (and then, much later inside the DAO) > > Criteria cc = dc.getExecutableCriteria(Session session); > > where session has been injected by Hivemind. However, it > seems that Hivemind injects a proxy and getExecutableCriteria > casts to a SessionImplementor and cannot cast the Hivemind > created proxy giving me: > > java.lang.ClassCastException: $Session_111be7b3773 > at > org.hibernate.criterion.DetachedCriteria.getExecutableCriteria > (DetachedCriteria.java:51) > ... > > Is there any way to obtain the 'real' Session object from the > proxy? Or can anyone suggest another way to solve this > problem. I looked at the Spring equivalent which uses a > special method within the Spring HibernateTemplate class but > I got lost trying to understand how the HibernateCallback > overcame this problem. > > Thanks > > Alan Chaney > >
