One of the things that concerns me is that my organization has decided to go with JCL all-around, but we are also using Websphere exclusively. Because Websphere has one of the most complex classloaders in existence, that decision concerns me a bit. Your comment about classloaders really struck home with me because of my experience with Websphere :(
Especially in light of the fact that at least for the next few months we are going to be using Log4J underneath (switching to JDK1.4 logging later), and my impression of the JCL problems, which I think echoes yours, is that the problems seem to only come up when Log4J is involved... In fact, one article I read about the JCL issues actually stated that the problems go away when using JDK1.4 logging. That knowledge has taken some of my anxiety away because it means we should be OK after the switch, but I'm still left with some, at least short-term.
And at the end of the day, I very much agree with your reasons for sticking with JCL in Shale, the idea of not being tied to a specific logging implementation. Sometimes I think people go too crazy with abstractions and just wind up making things more complicated than they need to be, but in the case of JCL I don't think that's true, I think it's thin enough to serve a valuable purpose without making life much more difficult, if at all. All this went into my being on board with the usage of JCL at work too.
Thanks again for taking the time to write such a good response Craig!
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Craig McClanahan wrote:
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]
