There seems to be a catch-22 when trying to setup a custom interceptor that needs arguments in it's constructor while also participating in JBoss transactions. I hope I'm wrong. :) Here's what I want to do:

Get a Session from HibernateContext.getSession(), specifying an interceptor in the hibernate-service.xml file using SessionFactoryInterceptor.

However, that interceptor needs to be passed an argument to it's constructor for each Session created.

It'd be great if there was a getSession() that took an interceptor, similar to SessionFactory.openSession().

Oh, yeah. I need to specify the JDBC connection programmatically as well.

Is this possible? :)

One way out might be to specify the hibernate.transaction.factory_class property in hibernate-service.xml, but there's no MBean property for that according to this page: http://docs.jboss.org/jbossas/jboss4guide/r2/html/ch13.html#ch13.config.table

Help?

HibernateContext.getSession( inteceptor ) would be nice, but slightly awkward because you need to either cache your session/intercetor or keep recreating the intercetor.

How about something like this

Interceptor interceptor = ...
InitialContext ctx = new InitialContext();
String ctxName = "java:/hibernate/MyHibernateSessionFactory";
SessionFactory factory = (SessionFactory) ctx.lookup(ctxName);
Session session = factory.openSession( interceptor );
HibernateContext.prepareSession( ctxName, session );
HibernateContext.bind( ctxName, session );

I recreate the Interceptor every time I create a Session, so that's OK.

Yeah, I saw those methods (prepareSession and bind) but do they handle the JBoss transaction? I couldn't find docs that mentioned that specifically. If so, that'd be keen. :)

Ah. Found it: http://docs.jboss.org/jbossas/javadoc/4.0.1-sp1/hibernate/org/jboss/hibernate/session/HibernateContext.html#bind(java.lang.String,%20net.sf.hibernate.Session)

It does say that you must have a current trasnaction to perform the bind, so I assume that means it attaches the Session to it.

Now we'll see if this clobbers any Interceptor I may have already set...

Thanks for pointing me in the right direction.

Another question: Is the name parameter in prepareSession(), bind90, and unbind() the JNDI name of the SessionFactory? From the wording of the javadoc I don't think so.

Here's what I'm doing:



Anyone know if this is correct?

the name parameter should be the jndi name of the SessionFactory. Get rid of that Session.hashCode() stuff at the end.


Why? Why can it not just lookup that information in a contextual fashion?

Done. I assume this is thread safe? Or does that matter?


Why? That, sir, is a dangerous question... :)

Basically, so the interceptor can fill in some fields automatically at save and update time. Each session will be associated with a security context that will determine the contents of those fields. This context could be stored in a threadlocal, but I'm programming under constraints where this probably won't be possible. It's my fallback, though.

Greg,

I would also agree that you should try to make the interceptors 'stateless'. I ran into a similar problem with an auditing interceptor where I needed the current username. What I did was add a method to my UserController session bean called getCurrentUsername() which just returned the ctx.getCallerPrincipal().getName().

In the interceptor I just looked up that bean and got the username.

Maybe your requirements are more complex though.

Ben