kuranikaran commented on PR #1890: URL: https://github.com/apache/struts/pull/1890#issuecomment-5536043362
Thanks for the detailed review. Your shared-classloader concerns make sense, especially the possibility of one application’s Dispatcher lifecycle or legacy setting affecting another application. I agree that the current DispatcherListener wiring should be removed. Before rewriting it, I propose this approach: - Restore StrutsTilesListener and the normal Tiles bootstrap lifecycle to their existing main-branch behavior, with no DispatcherListener registration. - Keep OGNL: registered with a lazy gating evaluator. - At evaluation time, derive the ServletContext from the current Tiles Request/ApplicationContext and resolve only that context’s Dispatcher. - If its struts.tiles.ognl.legacy.enabled value is absent or false, throw EvaluationException before constructing the raw evaluator or changing the global Request property accessor. - If it is explicitly true, construct/cache the legacy evaluator and emit the migration warning once. - Continue checking the flag against the current request’s ServletContext so another webapp cannot opt this one into legacy behavior. - If no Dispatcher exists, fail closed by default. - Make the explicit boolean constructors public for applications using their own StrutsTilesInitializer or StrutsTilesContainerFactory, including direct Tiles setups without a Dispatcher. This should preserve the original bootstrap behavior, remove the static cross-application lifecycle dependency, and ensure raw OGNL construction remains reachable only through an explicit application-local opt-in. Would this direction address your concerns before I revise the patch? I’m also happy to prepare the support/struts-6-x-x backport as a separate PR after we settle and merge the main-line design, using plain @Deprecated as noted. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
