On 17/06/2015 08:32, Fjodor Vershinin wrote: > Could you provide me your eclipse config files for this project? I think it > would be most convenient way to fix such kind issues.
This is something that would have been covered during community bonding. http://svn.apache.org/viewvc/tomcat/trunk/res/ide-support/ > I added some Javadocs, however current implementation is not that stable, > so I'll continue commenting code when code will be more solid. Comments in the code are just as importantas the Javadoc. I'm not too bothered about ensuring every public method is fully documented with Javadoc. The important thing is that there are enough comments for someone to understand the code. >> All user messages, exception messages etc. should use i18n (StringManager). > Fixed. Only "not implemented" exceptions had left, but they will be > removed after some time, so I think it's not mandatory to translate them. Yes, that is fine. No need to use i18n for temporary code. Do make sure there is a TODO marker there so nothing gets missed. >> In JaspicAuthenticator.authenticate() request.getLocalName() is not the > way to get a unique name for the web application (assuming that is what is > required). > > Has been fixed. Now I get unique name in JASPIC 1.1 style. That is better but it is still not unique. It is rare but Tomcat instances can be configured with multiple services and those services may have host names and contexts paths duplicated between them. You really need to find a way to include the engine name as well. You can't use the address:port since there may be multiple connectors with different addresses and/or ports. I'd ignore the request and use the fact that Valves have a Container and that that Container will have a reference to its ancestors. The > All ThreadLocal logic has been replaced with creation of a new instance > every time. I'm not sure about performance, but for now it's more > convenient. I'm not sure about performance either. My general approach is to focus on functional correctness and worry about performance once I have something that is working. Tuning a working implementation is a lot easier than fixing a tuned but broken implementation. I do try to avoid any obvious performance pitfalls as I go along but the bulk of tuning will happen latter. Premature optimisation nearly always causes more problems than it solves. >> In JaspicCallbackHandler how is the PrincipalGroupCallback associated > with the authenticated Principal? > > What do you mean under authenticated Principal? Currently, I merge two > callback's info into tomcat GenericPrincipal, which contains user > principal, user name and roles. Then this GenericPrincipal can be used in > Tomcat's internals. I am not sure how to deal with already authenticated > Principal's, I need to do some research. What I mean is how is this linked in to the Realm (which is currently unused) since it is the Realm that creates the Pincipal. I am encouraged by the most recent round of patches. Progress is being made and I can see the direction development is heading in. I look forward to the next set of patches. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
