On Fri, 11 Feb 2005 18:26:17 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Craig, I have some interest in this discussion because of the direction > we are taking here at work... > > Since you said if you WERE inclined to change Shale's logging, can I > infer from this that you don't feel it needs to be changed, which > further would imply that you don't believe the "problems" that have been > talked about with JCL exist, or that they have been overblown or perhaps > only apply in some very limited circumstances (because otherwise I > assume you WOULD be inclined to change from JCL)?
Although many people had encountered class loader related problems with JCL < version 1.0.4, the bug fixes done there reduced the number of failure scenarios to what has seemed like a pretty small number (anything major remaining would have caused a firestorm on Struts User, for example, because all Struts based apps would be affected). Same thing on apps that run on the JSF reference implementation (which also uses a subset of the same Commons jar files, and therefore depends on JCL. I'm just not seeing or hearing about large numbers of problems. That being said, I don't use Log4J myself (other than the unit tests that are in the JCL workspace), so it's entirely possible that there are bugs that surface only in conjunction with Log4J. But even there, I would have expected there to be rumblings among Log4J+Struts users ... where are the mission critical problems these folks are having? Be that as it may, the right answer to bugs in JCL is to fix JCL, not start a crusade to banish it from the earth :-). If that requires backwards-incompatible changes (as it appears that it might), so be it -- IMHO class loaders are by far and away the most complicated thing about Java (having been invoved in the development of the webapp class loader inside Tomcat, I never want to see the insides of another one :-). And that complexity can lead to corner cases that are broken. If so, the next logical step is to find them and fix them. Ceki's analysis will be tremendously helpful in that endeavor. Now, as to Shale in particular, we have a choice that we didn't in Struts 1.0 - 1.2 ... since it assumes a JDK 1.4 platform, it would be technically feasible to just use standard JDK logging. Indeed, if Shale weren't depending on libraries already depending on JCL, that's possibly what I would have done in the first place (although I must confess that my fingers would have probably just typed "import org.apache.commons.logging.Log" anyway, with no conscious thought :-). But I only use the logging inside Shale to debug Shale; JCL's defaulting rules that pick the JDK logger for me (since I am on 1.4) is plenty good enough for that, so I had no need to decide which enterprise scale logging implementation I want to use. Or even to configure the logging system I'm using, other than tweaking the debug levels for the packages and classes I'm working on at the time. People building apps on top of Shale, on the other hand, might have very specific reasons for preferring one logging implementation over the other, and would still prefer to configure only a single logging implementation. Keeping Shale based on JCL, instead of hard wiring it to JDK logging, gives you that flexibility. Wouldn't converting Shale to UGLI do the same thing? Perhaps ... all I've seen of UGLI is the javadocs, and it says it offers the same benefits. OK, let's assume that is true But, it would mean adding yet another third party dependency to complicate life for everyone, and (at least in the short term, until *all* other JCL-using dependencies were also switched) would lead to two log wrapping abstractions to debug. When you also realize that both JSF implementations people are likely to use (RI and MyFaces) also both use JCL, "short term" starts seeming like it will last a very long time. That doesn't sound like making the world a better place to me. So, the issue of switching just the Shale framework hasn't been something I'd even thought about -- let alone trying to figure out what I would switch to -- until today. From where I sit, it doesn't seem like a wise choice. > > I'm not by any means passing any sort of judgment on your decision, I'm > simply trying to understand the thinking that is going into it because > that thinking could influence what I'm doing as well. > > Thanks Craig! > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
