2015-07-03 15:31 GMT+03:00 Mark Thomas <ma...@apache.org>: > On 03/07/2015 07:37, Fjodor Vershinin wrote: > > Hi! > > Unfortunately, commit rearrangement requires some more effort from me, > so I > > haven't finished it yesterday. > > I need some more time to fix checkstyle errors and so on. > > OK.
I have prepared patchset in https://github.com/fjodorver/tomcat/commits/feature/form_auth branch, some commits are squashed. However I think it's reasonable to save refactoring commits in order to have possibility for tracing code changes and discuss about them. > >> We can change the way users have to configure it. For example, we could > >> say they have to use programmatic configuration via the standard JASPIC > >> interfaces if they want to use non-default settings. > > > > > > I see your point. The best option in my opinion is is to pass this > options > > through LoginConfig/Context in ContextConfig. > > We can figure out how to set these options in a programmatic way and then > > refresh the context provider in order to reinitialize authenitcation > > modules. > > Why do you say reinitialize? I'd expect a new instance of the module to > be created when the web application starts and that instance to be used > until it stops (requiring a stop/start to update config happens a lot in > Tomcat - not that much configuration is configurable dynamically). Here is the thing: currently we initialize our embedded provider on application startup, if application has login-config in web.xml. So, we need to invent some mechanism to detect, if person wants to use custom provider or embedded one. I have an idea, that login-config is for embedded provider only, so, in case users want to use their custom provider, and do not want to use embedded one, they should avoid using login-config in application config. Another option is unregister Tomcat's default provider, and register custom one. Thanks, Fjodor
