Jeff, I think I'm OK with your conclusion, but I am not at all in sync with your logic.
On 10/1/05, Jeff Genender <[EMAIL PROTECTED]> wrote: > I don't agree with you about not removing the hard coded part. What if > I write my own patches to commons-logging to fix some of these issues > and do my own specialized logging. OK, so lets follow this scenario. You create a custom commons-logging. In order to get your app to use it, you have 2 options: 1) Replace the commons-logging that Geronimo uses (just copy over the file in the repository or whatever). Result: Whatever we do with exclusion lists is irrelevant in this case, since there's only 1 version of commons-logging -- your patched one. Your patched one is used. 2) You add your patched version to WEB-INF/lib so your web app will use it, but Geronimo won't. If we have an exclusion list, you remove commons-logging from it. You set the web app class loading flag to load from the WEB-INF/lib before the parent. Result: You get a ClassCastException because your version in WEB-INF/lib has to touch our global logging instances which implement our commons logging interfaces, not yours. Do you disagree? Aaron
