I've been looking at the relationship between a Context and its Manager and I have identified some inconsistencies in the underlying assumptions on which the code is based.
A. Context is always set In some places the code carefully checks to see if the Context is null. In other places (often in the same method and before the null check) the code assumes that the Context is non-null. B. Context never changes ManagerBase.setContext() is written on the basis that the Context may change at any point. However, pretty much everywhere else assumes that the Context doesn't change (at least while the Manager is in use). Related to B, there are various places where threading issues exist if the Context were to change while the Manager was in use and a few places (e.g. the distributable flag) that aren't updated that should be. Given these issues I see two options. 1. Require that the Context is set before the Manager is first used and disallow any changes once the Manager has been used. 2. Correctly handle the possibility that the Context may change either a) at any time or b) if the Context is stopped (i.e. the Manager is not being used). Option 1 is fairly simple to implement as large parts of the code essentially assume this already and all the current Tomcat code already conforms to this requirement. This option would require documenting the requirement, adding a few lines of code to enforce it and then removing various null checks that would no longer be necessary. Option 2 would require a lot more work, particularly 2a. 2a would create a lot of strange edge cases (e.g. Context changes mid-way through sessions being persisted to the store - where do those sessions get written?) which would require careful definition and implementation. 2b would be manageable but we'd need to carefully define "the Manager not being used" and which methods could only be called in that state. My preference is for 1. It is less work, Tomcat currently never changes the Context and I can't see a viable use case for wanting to do so. Assuming there are no objections, I'll add this to my TODO list. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
