Aaron Mulder wrote:
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.
IMHO, this seems almost as bad as forcing the user to remove their own commons-logging from web-inf/lib.
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?
Yes. Lets make a more real scenario. Lets say I write...not my own logging, but my own factory to do whatever, that needs package access to the o.a.c.l because something is protect in there. With our hard code, I cannot use my class. By creating an exclusionary list, I can exclude packages and classes, but allow my new class through.
Jeff
Aaron
