Re: TC 3.3: Form authentication vs. Application reloading
[EMAIL PROTECTED] wrote: My understanding is that ContextXmlReader actually produces 'fresh' instances every time. True. Do you think it would be better ( or simpler ) to just change ContextXmlReader to create a new set of per/context interceptors ? My thinking was that the interceptors should be 'smart' about reloading, maybe they need to save/restore some state ( like a session interceptor ), or do some other actions. Sorry about the late reply. Came down with a flu on the weekend... Wouldn't really know about the simplicity of ContextXmlReader change. It looks complicated to me, especially with the involvement of all the XML machinery below it. When I think about the whole thing a bit more, (apart from my headache getting worse) it seems that your idea is much better and more consistent with what Tomcat does now. Currently, there is no re-reading of configuration files while Tomcat is running, so introducing that would mean breaking that rule. And then we might end up with something like this: - Tomcat starts, ContextXmlReader does its job and user expects this to be a one time occurrence - there is a need for a context reload, so (changed) ContextXmlReader runs again to pick up the config, but the configuration file was changed and totally different local interceptors get loaded or even worse, the old context doesn't exist any more - user gets seriously frustrated and starts using swear words intermixed with names from tomcat-dev list ;-) Once I feel a bit better, I think I'll attempt your approach. Seems more consistent and in line with what Tomcat does now. Plus it's probably easier to do. Thanks for pointing me in the right direction. Bojan
Re: TC 3.3: Form authentication vs. Application reloading
On Fri, 21 Sep 2001, Bojan Smojver wrote: A simpler solution is to fix ReloadInterceptor - and save the current list of interceptors before removing the context, then add all per/context interceptors after the context is added back ( those having getContext() != null ). Just to be clear on what you meant here, if there was, for instance this JDBCRealm local interceptor object, you'd just store its reference ,somewhere else while context is being reloaded and then attach the same object back as an interceptor after the reload is done. I was thinking about that but what if that old instance of the interceptor object relied on something in the old context? That would screw things up. But if that's not the case (ie. there can't be any relationship with the context), it should be fine. Still don't know enough to tell. You should call setContext() and reload() on the interceptor to let it know the new context, and the module should be able to handle this - you may need to do additional fixes in the module. In general I think each module should be able to deal with: - dynamic context add/remove - context reloading - module reloading ( in future ) My understanding is that ContextXmlReader actually produces 'fresh' instances every time. True. Do you think it would be better ( or simpler ) to just change ContextXmlReader to create a new set of per/context interceptors ? My thinking was that the interceptors should be 'smart' about reloading, maybe they need to save/restore some state ( like a session interceptor ), or do some other actions. Costin
Re: TC 3.3: Form authentication vs. Application reloading
Bojan Smojver wrote: Just playing with Form authentication in TC 3.3. Have two Velocity pages that are doing the authentication with a JDBC Realm (for that context only). When Tomcat starts, all is fine. I get authenticated (or not) depending on username/password combination I supply. Subsequent visits to the same page do not require additional authentication. Excellent! If I update the application (automatic reloading is enabled) and attempt to hit the same page again, I get prompted for new authentication. Cool. But although I specify the correct username/password combination, I can't log in. Is this something that happens by design or am I looking at a possible bug? It seems that context's JDBCRealm does not get hooked into Interceptors when the context reloads. These are the relevant interceptors first time around (first three from server.xml, fourth from apps-*.xml): -- Auth interceptor is: org.apache.tomcat.modules.config.PathSetter@ed8b59e Auth interceptor is: org.apache.tomcat.modules.config.ServerXmlReader@2c72759e Auth interceptor is: org.apache.tomcat.modules.aaa.CredentialsInterceptor@5393359e Auth interceptor is: org.apache.tomcat.modules.aaa.JDBCRealm@7b08b59d -- and this is after the reload (only the ones from server.xml, the stuff from apps-*xml didn't show up this time): -- Auth interceptor is: org.apache.tomcat.modules.config.PathSetter@ed8b59e Auth interceptor is: org.apache.tomcat.modules.config.ServerXmlReader@2c72759e Auth interceptor is: org.apache.tomcat.modules.aaa.CredentialsInterceptor@5393359e -- These things are printed out by me from getRemoteUser() method in Request.java. Just need to find where those things get hooked and we'll be laughing... Just to bounce the validity of it against someone with more experience, this is my apps-*.xml file: -- ?xml version=1.0 encoding=ISO-8859-1? Server Host name=www.dev.dev Context path=/ docBase=/home/httpd/html/dev.dev JDBCRealm debug=99 driverName=org.postgresql.Driver connectionURL=jdbc:postgresql:dev connectionName=dev connectionPassword=developer digest=MD5 userTable=users userNameCol=username userCredCol=password userRoleTable=usersroles roleNameCol=rolename / /Context /Host /Server -- Back to trenches now... Bojan
Re: TC 3.3: Form authentication vs. Application reloading
Hi Bojan, A simpler solution is to fix ReloadInterceptor - and save the current list of interceptors before removing the context, then add all per/context interceptors after the context is added back ( those having getContext() != null ). This would deal with other configuration mechanisms as well - ContextXmlReader is not the only way to add contexts, applications embeding tomcat may use API calls as well. Dealing with changes in app.xml is a bit more difficult - and I think the right long-term solution is to consolidate all config modules and create a smart 'deploy tool' module that can take care of all the issues. Costin On Thu, 20 Sep 2001, Bojan Smojver wrote: Bojan Smojver wrote: Is this something that happens by design or am I looking at a possible bug? By following what happens when TC starts and when it reloads the context, it seems that there should be contextInit() method in ContextXmlReader. This interceptor is responsible for calling the ServerXmlReader.loadConfigFile() which in turn (after a series of XML related calls on the stack) calls Context.addInterceptor(), which is responsible for adding all local (to the context) interceptors. If ContextXmlReader had contextInit() method, this would happen every time the context is reloaded and all local interceptors (including my JDBCRealm :-) would be picked up. Swt! Now that's all cool, but I wouldn't have a clue how to write that method. If you guys can point me in the right direction... Thanks, Bojan
Re: TC 3.3: Form authentication vs. Application reloading
[EMAIL PROTECTED] wrote: Hi Bojan, A simpler solution is to fix ReloadInterceptor - and save the current list of interceptors before removing the context, then add all per/context interceptors after the context is added back ( those having getContext() != null ). OK. I'll look into producing a patch along those lines. Just to be clear on what you meant here, if there was, for instance this JDBCRealm local interceptor object, you'd just store its reference ,somewhere else while context is being reloaded and then attach the same object back as an interceptor after the reload is done. I was thinking about that but what if that old instance of the interceptor object relied on something in the old context? That would screw things up. But if that's not the case (ie. there can't be any relationship with the context), it should be fine. Still don't know enough to tell. My understanding is that ContextXmlReader actually produces 'fresh' instances every time. This would deal with other configuration mechanisms as well - ContextXmlReader is not the only way to add contexts, applications embeding tomcat may use API calls as well. Dealing with changes in app.xml is a bit more difficult - and I think the right long-term solution is to consolidate all config modules and create a smart 'deploy tool' module that can take care of all the issues. Sounds good. Bojan
TC 3.3: Form authentication vs. Application reloading
Just playing with Form authentication in TC 3.3. Have two Velocity pages that are doing the authentication with a JDBC Realm (for that context only). When Tomcat starts, all is fine. I get authenticated (or not) depending on username/password combination I supply. Subsequent visits to the same page do not require additional authentication. Excellent! If I update the application (automatic reloading is enabled) and attempt to hit the same page again, I get prompted for new authentication. Cool. But although I specify the correct username/password combination, I can't log in. Is this something that happens by design or am I looking at a possible bug? Bojan
