On 03/07/2015 13:56, Fjodor Vershinin wrote: > 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.
OK. I'll hopefully start reviewing and merging those this afternoon. >>>> 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. Not quite. If the user has defined an authenticator Valve in context.xml or server.xml then that is used and any login-config in web.xml is ignored. > So, we need to invent some mechanism to detect, if person wants to use > custom provider or embedded one. Or, as currently, simply define an order of preference. > 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. Another option would be to define a jaspic element for server.xml / context.xml that is nested in a Context and if present takes precedence for JASPIC config. For that to work modules would have to: - have zero arg constructors - be fully configurable via setters - use simple types for their property setters How feasible is that? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
