If your problem is that a webapp using hibernate loaded it's
configuration from webappclassloader and then stored the hibernate
loaded configuration in hibernate at common/ level, the problem is
probably that you have put hibernate in common classloader (so common
configuration, first webapp to configure it wins) instead of server
level (that is, not reacheable by webapps).
Putting your hibernate realm stuff in server/lib should make it
invisible to webapps and then not influenceable by webapps.
Andrew R Feller a écrit :
While developing a custom JAAS module to use Hibernate for users'
authorization profiles on a new application, we found that the Hibernate
login module was being initialized not by the server's classloader but
the webapp's classloader! As we want to have different Realms declared
for each web application, we don't want to set a realm and security
constraints at the server level.
This issue came up while stepping through Tomcat's log. Whenever the
application was being initialized, then its hibernate.cfg.xml was loaded
up from /WEB-INF/classes by the webappClassLoader. Later on whenever
the protected resource was requested and the JAAS login module was
invoked, the login module was ALSO loaded by the webappClassLoader and
the hibernate.cfg.xml it requested was loaded from the
webappClassLoader's cache instead of searching for the one in
server/classes.
Questions:
1. Why is the webapp's classloader loading classes for the login
module? Is this the intended behavior?
2. How is it possible to make Tomcat initialize the login module
without the login module being declared for the entire server?
Sincerely,
Andrew
Andrew R Feller, Analyst
Subversion Administrator
University Information Systems
Louisiana State University
[EMAIL PROTECTED]
(office) 225.578.3737
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
