Hi

I have read the http://www.hibernate.org/hib_docs/v3/reference/en/html/events.html documentation about the Interceptors and Listeners. But what are the real differences between them?
Are there any advantages for the Interceptors?

It is not clear for me with reading this article.

Thanks in advance and greets

Well, there are a couple of notable differences. You can pass constructor parameters to interceptors. I do not believe that you can do that with the listeners on a session-by-session basis. If the AuditInterceptor needed a username for the current unit-of-work, you could create a constructor to do so: factory.openSession(new AuditInterceptor('username')) . The detriment to using interceptors: you have to use openSession in some form or another to associate the interceptor with a Session.

Interceptors can be session scoped or session factory scoped. If it's session scoped, every session has a separate instance of the Interceptor.

Listeners, on the other hand is only session factory scoped.

But when I have a ThreadLocal Object which holds some data (password), and I set this password in a filter (in a web app), and then call the threadlocal object from a Listener, then It will not the same password for every user/session?

ThreadLocal variables, as the name implies, is local to the current thread.

Each request is usually executed on a different thread by the web container. So ThreadLocal will have different data on different requests.

But, if you are saving the password to a ThreadLocal in a servlet filter (for every request), then you can access it from everywhere inside the filter chain. I already do this for an AuditInterceptor that requires a user key. Works fine.

Then I could do this also with a Listener?

Absolutely. Anything that runs in the filter chain will have access to this data, since it is in the same thread. If you need some jump start code, let me know.

@Ananasi

Thanks for your help very much (unfortunately I cant give you no more credits, the maximum for this thread is reached).

Then I use the solution with the Listener, I think that this is better for my case (no code change to an existing web app, only via configuration).



Do you know a general way to get the logged in users password in a web app via the HttpServletRequest? (the UserPrincipal sounds right, but could it be that this data is from the web server conditioned?)

Don't worry about the credits, I think I have enough to last a while ;)

The Principal only enforces the getName() method, so that's not going to help you. No well-formed security system (sounds like you are using JAAS) would store unencrypted passwords in the HttpSession or ServletRequest. It really depends on the authentication/authorization scheme, what exactly are you using (BASIC, JAAS, homebrew, etc). You can get the logged on user's name via request.getPrincipal().getName() if the a/a scheme supports it. A few more details could help.

I'm using a form based authentication (via JNDI DataSource) in a Tomcat application server. JAAS says nothing to me.

So, if you have the username, you can obtain the password if needed from the datasource, yes? If so, you should be able to get the username from request.getRemoteUser() if you are using BASIC authentication. Does this help, or do you really need to persist the password across requests?

Im using FORM based authentication. The idea was, that I can use the password from the authentication to encrypt/decrypt some data in the Listener (before saving or loading the data from the DB). But I'm not sure if can get the password directly from the servletrequest (or from somewhere else whithin the reach of the listener)?

Oh, I see what you are doing there! *light bulb over head*

I've got to leave the office now, but I'll ponder this conundrum and get back to you later tonight. Interesting proposition to maintain user encrypted data, at least until they forget their password ;D .

I would be glad to here from you :-)

I saw that I receive an org.apache.catalina.realm.GenericPrincipal (which holds the password) when I call ((HttpServletRequest) request).getUserPrincipal();.

But I think that this is application server conditioned!?