Re: JDJ - log4j vs java.util.logging

On Friday 25 March 2005 00:15, Jacob Kjome wrote: > ALAPI" (Apache Logging API) +1 Make a proposal to the JCL guys to that effect under a new subproject in Apache LS, and transfer their karma here. Get rid of the "we vs them" and create a "we" atmosphere. By dropping the existing names, we get

RE: JDJ - log4j vs java.util.logging

> I think it is more interesting to open existing solutions (aka > backends) for other frontends and to improve the way to > lookup/bind/manage the backend. > (See also threads discussing classloader issues and dynamic/static > binding) > In my opinion there should be no overwhelming frontend

DO NOT REPLY [Bug 34162] New: - Small build.xml fix

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

RE: JDJ - log4j vs java.util.logging

Hi, > Perception is not everything. Reality is at least as important as > perception. Moreover, not all recognition is good. For example, > take McDonalds as a widely recognized brand which is not associated > with quality. Few volunteer developers want to spend their time > creating crappy produc

RE: JDJ - log4j vs java.util.logging

At 08:03 PM 3/24/2005, you wrote: Hey, > the name being an advantage, to someone like me, it is a severe > disadvantage. > But I suppose I'm in the minority. It's hard to tell if you're in a minority of hating the JCL name. Others might, I totally believe it. But they *recognize* it, and that's

RE: JDJ - log4j vs java.util.logging

> I think it is more interesting to open existing solutions (aka backends) > for > other frontends and to improve the way to lookup/bind/manage the backend. > (See also threads discussing classloader issues and dynamic/static > binding) > In my opinion there should be no overwhelming frontend f

RE: JDJ - log4j vs java.util.logging

Hey, > the name being an advantage, to someone like me, it is a severe > disadvantage. > But I suppose I'm in the minority. It's hard to tell if you're in a minority of hating the JCL name. Others might, I totally believe it. But they *recognize* it, and that's important. > I actually like th

RE: Parameterized directory FileAppender

Nevermind, I found the docs. Thanks. Gary -Original Message- From: Gary Gregory Sent: Thursday, March 24, 2005 10:53 AM To: 'Log4J Developers List' Subject: RE: Parameterized directory FileAppender Great, is this documented in 1.2.9 or 1.3.alpha6? Thanks, Gary -Original Message---

RE: Parameterized directory FileAppender

Great, is this documented in 1.2.9 or 1.3.alpha6? Thanks, Gary -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Thursday, March 24, 2005 10:24 AM To: Log4J Developers List; Log4J Developers List Subject: Re: Parameterized directory FileAppender At 07:03 PM 3/24/2005,

Re: Parameterized directory FileAppender

At 07:03 PM 3/24/2005, Gary Gregory wrote: Hello: Let me prefix this note by saying that I am willing to do provide code and test patches for such a feature. I want to ask if this is too off-beat to consider for log4j or if should hack something up on the side. We have fat server and test environme

RE: JDJ - log4j vs java.util.logging

At 06:04 PM 3/24/2005, Jacob Kjome wrote: We for me, the brand name "JCL" carries a lot of baggage with it and if JCL 2.0 is supposed to be the new official logging API, it will take some time get over my nauseous aversion to the name even if it finally works properly. So far from the name bei

Parameterized directory FileAppender

Hello: Let me prefix this note by saying that I am willing to do provide code and test patches for such a feature. I want to ask if this is too off-beat to consider for log4j or if should hack something up on the side. We have fat server and test environment where settings like the ones below ca

RE: JDJ - log4j vs java.util.logging

It has been a while since I developed in C++, but couldn't a commons-logging project under Logging Services also develop generic logging interfaces for other languages than just Java? That would fall under the LS umbrella, and might be pretty cool. -Mark > -Original Message- > From: Mark

RE: JDJ - log4j vs java.util.logging

I like the idea of moving commons logging out of Jakarta and into Logging Services. I have to admit that I have always been a little perplexed that it was done in Jakarta Commons, but at the time logging within Apache was very log4j focused. Now that log4j lives in Logging Services, with other cr

RE: JDJ - log4j vs java.util.logging

At 04:01 PM 3/24/2005, Boris Unckel wrote: I think it is more interesting to open existing solutions (aka backends) for other frontends and to improve the way to lookup/bind/manage the backend. (See also threads discussing classloader issues and dynamic/static binding) +1 In my opinion there sh

RE: JDJ - log4j vs java.util.logging

Quoting Yoav Shapira <[EMAIL PROTECTED]>: > Hi, > > > So, is the only concern the brand name "JCL"? It seems to be. > > Yup. We for me, the brand name "JCL" carries a lot of baggage with it and if JCL 2.0 is supposed to be the new official logging API, it will take some time get over my nauseous

RE: JDJ - log4j vs java.util.logging

At 05:25 PM 3/24/2005, Yoav Shapira wrote: Hi, > So, is the only concern the brand name "JCL"? It seems to be. Yup. > If the > code is > going to be completely different and not backwards compatible with the > existing > "JCL" it isn't really "JCL", so why call it "JCL"? Because the brand name is

RE: JDJ - log4j vs java.util.logging

Hi, > So, is the only concern the brand name "JCL"? It seems to be. Yup. > If the > code is > going to be completely different and not backwards compatible with the > existing > "JCL" it isn't really "JCL", so why call it "JCL"? Because the brand name is powerful and will lead to rapid adoptio

RE: JDJ - log4j vs java.util.logging

Quoting Yoav Shapira <[EMAIL PROTECTED]>: > Hola, > > > How can we have confidence when the existing JCL causes so many > > problems for log4j users, especially when even the mere existence of > > these problems have been denied for so long? It seems unrealistic, > > doesn't it? > > I have confide

RE: JDJ - log4j vs java.util.logging

Hi, > >I have confidence in the people (mentioned earlier, including us, the > other > >Tomcat folks, etc.) and the Apache brand. The JCL code itself will be > gone, > >replaced with our new creation, called JCL 2.0 for branding and adoption > >purposes. > > Sounds nice, but can it be done? I t

RE: JDJ - log4j vs java.util.logging

At 04:38 PM 3/24/2005, Yoav Shapira wrote: I have confidence in the people (mentioned earlier, including us, the other Tomcat folks, etc.) and the Apache brand. The JCL code itself will be gone, replaced with our new creation, called JCL 2.0 for branding and adoption purposes. Sounds nice, but can

RE: JDJ - log4j vs java.util.logging

Hola, > How can we have confidence when the existing JCL causes so many > problems for log4j users, especially when even the mere existence of > these problems have been denied for so long? It seems unrealistic, > doesn't it? I have confidence in the people (mentioned earlier, including us, the o

RE: JDJ - log4j vs java.util.logging

Hi Yoav, On 2005-03-24 13:55:37 GMT, Yoav Shapira wrote: > I'd prefer a fixed Jakarta commons-logging over a brand new project. > I see a dead-end in the current JCL 1.x tree, and a new JCL 2.0 that > is a combined effort from logging services, Jakarta, Tomcat, and other > interested parties. It'l

RE: JDJ - log4j vs java.util.logging

> > JUL was probably never designed to be a front end but rather as the > Yup. JUL is neither open to be a front end, neither is the backend open for other ways to use it without a wrapper. > > Maybe we should consider an independent project acting as a facade for > > the existing alogging APIs. C

RE: JDJ - log4j vs java.util.logging

Hola, > JUL was probably never designed to be a front end but rather as the Yup. > Maybe we should consider an independent project acting as a facade for the > existing alogging APIs. Comments? I'd prefer a fixed Jakarta commons-logging over a brand new project. I see a dead-end in the current

DO NOT REPLY [Bug 34163] New: - Please update the install-chainsaw.xml

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: JDJ - log4j vs java.util.logging

At 05:15 AM 3/24/2005, you wrote: On Thursday 24 March 2005 07:00, Ceki Gülcü wrote: > Thanks Mark. Just finished reading it. As you said, it does not go into > terrible but otherwise a pretty decent article. Didn't we discuss before the possibility to make JUL the application API, and Log4J the ba