I've got a situation where I'd like to be able to register an Interceptor at runtime in some - but not all - cases. I'm using a ThreadLocal Session, so I figured I'd just tweak my API to allow someone to pass in an Interceptor when they requested the Session, but low and behold, there's no way to register an Interceptor after the Session has been created.

Is my best option to always create the Session with the Interceptor (through the configuration) and then do some sort of instance checking in the Interceptor to see if it "really" should fire? Am I missing something?

I haven't looked too deeply into SessionImpl, but what was the architectural thinking around why post-open registration of Interceptors wasn't allowed? I suppose it might get sloppy if some registers one and then doesn't clear it when they're finished...

Thanks for the feedback.

-ep

It should not be too difficult to create an interceptor which acts as a wrapper for interceptors you add dynamically and delegates all calls to the dynamically added ones. There is a more mature event api on the roadmap, so you might see some additional possibilitys in that area.

Thanks for the reply.

The issue with your approach is that there isn't a hook on the Session to get at the Interceptor. So if I registered some sort of InterceptorProxy at the time of config or session open, I'd have no way to get at it later in order to 'stuff it' with actual Interceptor Impls.

-ep

Have a look at http://www.hibernate.org/Documentation/ChainedInterceptor.
Adding some kind of ChainedInterceptor manager to plug / unplug concrete interceptors shouldn't be difficult.

Again, thanks for the help.

I understand the concept of an aggregated Interceptor. It is undoubtably the pattern I would look to implement. But it still doesn't answer my question.

Lets say I configure the Session to use ChainedInterceptor as its Interceptor. How do I get a handle to the ChainedInterceptor to add new Interceptors to the chain at runtime?

I'm sorry if I'm missing something obvious here. And if I should move this out of the Architecture forum, I can do that. It feels architectural to me.

-ep

Too late, Wrong site is better than dup post.

For Interceptor management, you will have to do the management way by yourself (maneger implementing singleton/local session pattern...), and thus independant from session lifecycle (unless you wrap hibernate session to add an activateIncerceptor() method).

Thanks for the reply. I still assert this is an architectural issue.

Wrapping the Session won't solve the problem, either. Too much of the interceptor callback stuff is private. I also don't feel that is the appropriate pattern.

I will fine an enhancement request in JIRA. Maybe it'll get shot down, but hey, it's worth a shot.

-dc