DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10897>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10897 PropertyMessageResources loading resources from the wrong ClassLoader Summary: PropertyMessageResources loading resources from the wrong ClassLoader Product: Struts Version: 1.1 Beta 1 Platform: All OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] At my company, we have decided to deploy the Struts JAR into Tomcat's shared classloader (the lib/ directory in the 4.0.x series) due to a number of classes that we will be sharing. Everything works fine *except* for the loading of the application's resource file. The reason is this: the PropertyMessageResources source explicitly attempts to load the resources via the ClassLoader associated with the class, not the thread. This means if your ApplicationResources are deployed in a webapp, but the struts.jar is in the shared directory, the code will *not* be able to find the properties file. The fix is to use the context ClassLoader associated with the current thread of execution. This way, the struts.jar will be able to find the resources file whether it is deployed in a WAR or is shared globally in an application server. The patch is attached to the bug. (As an aside - why does the PropertyMessageResources go through all the explicit trouble of loading the file itself, when it could just use the ResourceBundle.getBundle() method?) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
