Mark, On 1/8/16 7:33 AM, Mark Thomas wrote: > 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.
+1 for the easy option. If someone wants to play games with context-switching, they ought to be able to use the parallel-deployment features to achieve the same goal without all the danger involved in lobotomizing a running context. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
