On 03/07/2015 18:55, Fjodor Vershinin wrote: >> On 03/07/2015 15:42, Fjodor Vershinin wrote: >>> I am working on polishing FORM authentication module code. I will >> continue >>> with that this evening. >> >> OK. I'm commenting on commits as I apply them. Some of them have >> suggestions for further improvements. These improvements don't need to >> be implemented now (if you have time then great). As a minimum there >> needs to be a TODO comment added to the right place(s) in the code so >> you can come back to them later. > > > Ok, thank you. > > >>> JASPIC modules configuration looks more like architectural stuff, so we >>> need to make some decisions how to proceed forward. >> >> What decisions? If you can define these before the weekend that gives >> folks a few days to think about it before you need answers. >> >> For example the way how we handle module configurations. What do you think > about my proposal to use Provider based config?
I'll start a new thread for that. One topic per thread is easier for other people to follow. Mark > > >>> I think it can be task >>> for next week together SPNEGO authentication module. >> >> SPNEGO is likely to be tricky since setting up a test environment needs >> server machines and some Windows Server licenses. I have a set of VMs I >> use for testing SPNEGO. It probably makes sense if you port it and I >> test it. > > > Let's do that way. > > >>> >>> Thanks, >>> Fjodor >>> >>> 2015-07-03 17:16 GMT+03:00 Fjodor Vershinin <fjo...@vershinin.net>: >>> >>>> >>>>> 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? >>>> >>>> >>>> I think it sounds even better, however I would like to allow security >>>> configuration only on the provider basis. >>>> Provider can be initalized with settings HashMap, which can be passed >>>> directly to modules on initialization. >>>> And then, modules can set own settings using provided information. >>>> >>>> -- >>>> Thanks, >>>> Fjodor >>>> >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
