https://bz.apache.org/bugzilla/show_bug.cgi?id=60615
--- Comment #4 from Mark Thomas <ma...@apache.org> --- I've put together a possible patch for this: http://home.apache.org/~markt/patches/2017-01-27-bug60615-tc9-v1.patch It does require a change to the WebResource interface as well as to a number of the resource implementation classes. I'm a little concerned about the impact it may have on any custom resource implementations (although I haven't seen any of those). The patch also assumes that class loader only resources won't be modified. While that is correct for classes in JAR files, it is possible that a custom implementation could use class loader only resources that could be modified. What is really required is "does this resource need to be checked for modifications" flag. There is another argument that if a JAR is updated to replace a class file that has not yet been used, then a reload is unnecessary. The current implementation correctly handles this scenario and only by checking individual classes can it be handled correctly. The requested change would break this behaviour. The more I think about this, the more I am leaning towards WONTFIX as a solution. Keep in mind that if re-loading is required then it may be a simpler option to update the .class file(s) and then touch web.xml to trigger a reload rather than setting reloadable on the Context. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
