Well I've had a few days to cool off, and my head feels better too. I acknowledge that there are problems with the discovery process in JCL. We aim to fix that, it is one of the tenants of what is being proposed for JCL version 'next'.
I wish it were as simple to resolve these issues in the more difficult environments [of which J2EE is a prime example], so the bottom line is that the UGLI solution doesn't *solve* the problems, it just doesn't complain as much... which admittedly might be considered a step forward depending on your point of view [silently operate in an unexpected manner vs. loudly proclaiming that a problem exists]. For JCL 'next' I'm looking for something of a middle ground that really solves the problems... all of them [alternate notes have/will discuss this]. I'm thrilled that Log4J mapped their interface to an independent interface. I'm sorry we couldn't coordinate that better between Log4J and JCL "way back" before JCL 1.0. What concerns me is that we have competing "abstractions" that are intended to be layered above interfaces. I also recognize the value of an interface not "tied" to Log4J, that we can grow forward and continue to layer above the implementations. So... let me toss out a not-so-random thought, and let's see how we all feel about this after some discussion: Can we bring these two together? Ceki, would your team be willing to make some concessions in the UGLI implementation, in the interest of supporting a common abstraction? Thoughts include: - Leaving JCL 1.0.x alone... and retiring it altogether in favor of an UGLI based approach. - Adopting the UGLI "style" interface as the base interface. - Layering in the JCL Log methods [support backwards compatibility] as "deprecated" methods where they differ from the UGLI interface? - We proposed a "separate jar file per impl" approach, in line with yours, to help minimize the JCL problems for JCL 'next'... so we're in sync with the fundamental advantages that offers - Adopting a more sophisticated discovery that allows the "separate jar file per impl" approach to work in a defined way for class hierarchies [such as J2EE] that might include multiple/different UGLI jar files [and yes, I'm talking about a *FIXED* process, not the current broken process]. - Log4J MUST be willing to accept extentions to UGLI [via interfaces that extend] that might go over and beyond the Log4J native supported methods [i.e., open to the types of discussions that are occuring now with JCL]. If I'm out of line here, set me straight.. but Ceki I still see Log4J as being under your thumb, and there are others in the community with valid differences of opinions that are looking for a voice. I'd like to point out that the JCL interface has been rigid, we've resisted change, and are only recently proposing any new change as extensions... I don't see this being a common occurance. <dream on> In short, can we merge these two in one fashion or another, and still accomplish our goals? <dream off> <ras> news <[EMAIL PROTECTED]> wrote on 01/25/2005 03:43:54 PM: > I'm sorry, I didn't mean for my post to sound angry, and I'm sorry if > anyone took offense. I was just asking :) > > Ceki, thanks for that link. You have many excellent points, and I may > migrate my projects away from commons-logging. > > Matt > > Vic wrote: > > Matt Sgarlata wrote: > > > >> You've spent a lot of time discussing commons-logging on this list, > >> while at the same time supporting development of UGLI. Which component > >> is your favorite? How come you're working on 2? > >> > > Simmer down now. Lets act intelligent. Many people work on many things > > and share code across projectsâ itâs a friendly license. > > > > Look at Struts, it has JSF subprojects under it, or lets play how many > > duplicate projects we can name under ASF. Itâs all good. Much > > duplication in Apache, all of it good. > > > > Choice = = good. What was that platform where they have the ONE true way? > > > > ..V > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ******************************************* Richard A. Sitze IBM WebSphere WebServices Development
