On 03/07/2015 18:55, Fjodor Vershinin wrote: > For example the way how we handle module configurations. What do > you think about my proposal to use Provider based config?
OK. We need the configuration settings in the ServerAuthModule implementations. It is pretty clear from the API that those settings are meant to be passed via the options Map in initialize(). initialize() is called from the constructor of TomcatServerAuthContext. The options Map is an argument that constructor. Question 1 why pass in the module and all the other parameters to the constructor when you coudl configure the module before calling the constructor and just pass in the configured module? That constructor is called from TomcatAuthConfig.getAuthContext() which passes in a properties Map. It looks as if the intention is that that properties map contains the configuration settings for the module(s). It would be reasonable to create a new Map, add those properties, add any internal properties (like the Realm name) and pass the newly created Map to the module. That has the added bonus (hopefully - it depends exactly on the properties) of isolating the module form any later changes the caller may make. TomcatAuthConfig.getAuthContext() is called from JaspicAuthenticator.authenticate(). A quick aside here. How many of the calls in that method might change their return values between different requests? Any that will not would be better placed in start() for better performance. Getting back to configuration, the JaspicAuthenticator has the authProperties Map. If this Map were populated with the necessary configuration settings, we can now see a path to getting this to the ServerAuthModule where they are required. server.xml is processed by the Digester. Understanding how that works can take a little while. The short version is is uses introspection to set properties on objects and we can use this to set configuration settings on the JaspicAuthenticator - in exactly the same way as we currently do for the BasicAuthenticator, DigestAuthenticator etc. This has the added bonus that as long as we keep the attribute names the same, users can migrate their settings to use JASPIC simply by changing the name of the Authenticator class they specify in server.xml / context.xml. For this to work, we need to be able to put all the configuration settings for JaspicAuthenticator in the authProperties Map. Luckily we don;t need to define every possible setting - the digest supports generic methods. If you add setProperty(String, String) and getProperty(String) methods to the JaspicAuthenticator then the Digester will do the rest. With all the information above you should have what you need to get settings from a JaspicAuthenticator in server.xml / context.xml all the way to the ServerAuthModule. If you need any help - particularly around the digester or configuring the authenticator in server.xml / context.xml just ask. Finally, feel free to ignore all of the above and go a different route but be prepared to justify why you think the different route is beter. HTH and have a good weekend, Mark P.S. Congratulations on passing your mid-term. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
