> 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 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 > > -- Thanks, Fjodor
