DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=30424>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30424 possible enhancement on bootup (or proving how little I know)... [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2004-07-31 19:47 ------- Ah, from that perspective it makes sense. (as much as I was trying to avoid another included technolgoy for a 'minor' fix from a specific webapp servlet instantiation perspective. I've used JNDI for ejbs - of course) However, it appears that you aren't supposed to think in that perspective or there is some confusion in the doc, which is probably why I did not consider the "global copy of the codebase" problem in the first place. Exhibit A: in http://struts.apache.org/userGuide/configuration.html#config_add, the Sidebar about Sharing JAR Files Across Web Applications, it specifically states: "...it is possible that sharing the Struts and Commons JAR files might appear to work for you. However, this is NOT a supported configuration." So, as a result of reading that part of the doc, my focus for an app from day 1 has within this "walled garden" approach to where it is self-contained within the webapp, including the duplication of codebases (jar files). From this perspective, bolstered by the doc, I would not have run into scenario you described, which might indeed require a more "global namespace/content" technology such as JNDI. Actually, I still submit that setting up a global lookup technology such as JNDI is still more gyrations to go through for an application-specific servlet-based bootup-sequence when a clean and minor enhancement could keep at the servlet lifecycle level where you would want it in some situations (and yes, I realize you create the same end effect based on your marshalling namespace example). Furthermore, there is a workaround to my original patch proposal: Generate the lookup and list each time from the specific context within the methods instead of caching the results globally like I originally did. Since this approach would retrieve the context and therefore the underlying tokens at invocation time, this implementation would always retrieve the correct results. (sidebar: If you're looking to re-factor to take Struts startup from containers other than servlets down the road, yes could change the landscape. But the idea of Initialization Parameters and a "default context" is present from an assembler viewpoint as well as from a servlet viewpoint, although other containers have a more intrinsic perspective of namespaces via JNDI than servlets traditionally have) In conclusion, it might make sense to at least revise that part of the documentation to avoid what I would still maintain is a reasonable conclusion based on the published scope of the .jar files. At least I hope you can see how I got to the assumption(s) leading up to the original proposal. And why I wanted to bring up these points, even at the risk of 'beating a dead horse'. Thanks for listening! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
