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=41939>. 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=41939 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From [EMAIL PROTECTED] 2007-03-26 03:42 ------- Then: Why does the very same package deploy on 5.5.9? And: Yes there are duplicate classes in the packages, but in the end you will never be able to avoid it. And: There is the, mabe even written law, that it is definitely good practice that one should package all required classes inside the web-app\lib path, besides native lib adapters. If this is suddenly not true any more, then how do you deploy different independent applications with incompatible commons-logging implementations? The answer may be easy for you, but I think that I have done valid packaging and that the classloader is in fact mixing packages from /common/lib with packages from my application web-inf/lib on application reload. It looks like it is preferring the common/lib instance of the jar on reloading, not recognizing, that there is a jar in WEB-IN/lib carrying the same class. Following the rules of classloading, the Web-App's jar should be used. But you are free to correct me if I am wrong. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
