Re: Open source licensing (was RE: Configuration GUI)

On Wednesday 12 February 2003 22:30, Ceki Gülcü wrote: > Having just looked at the LGPL more closely, it may be almost as viral as > the GPL. > > See also http://marc.theaimsgroup.com/?t=10447722553&r=1&w=2 One of the issues with LGPL that I know the Apache people is "on about" is that it is

Re: Configuration GUI

On Thursday 13 February 2003 03:03, robert burrell donkin wrote: > On Tuesday, February 11, 2003, at 11:35 PM, Richard Bair wrote: > > > > > BTW, Mark, I'm totally wrong. The java.beans package goes all the way > > back to 1.2.2 at least. I think it will work well for what we are doing > > here.

Re: Open source licensing (was RE: Configuration GUI)

On Thursday 13 February 2003 00:32, Matt Munz wrote: > All, > > Perhaps I'm dense for looking for a technological solution to an > ideological problem, but can't this be resolved with an abstraction layer? Java is tricky since (L)GPL didn't consider the nature of Java when it was written/updated,

Re: JDBCAppender memory leak issue

Lutz Michael wrote: I will look at it. From what I've seen, it didn't look overly complicated, but I know how database code can get ... especially when you're trying to be RDBMS neutral. Please give me a few days to get back to you (I'm also busy of course). Also, the CLOB support was another p

RE: Multiple Levels per Category/Logger

Brilliant. Thanks. Richard On Wed, 2003-02-12 at 16:33, Nicko Cadell wrote: > You need to set the root level to debug, because you do want all the debug > and above messages to be logged. Attach the 3 appenders to the root logger, > then set the threshold level on the individual appenders themse

RE: Multiple Levels per Category/Logger

You need to set the root level to debug, because you do want all the debug and above messages to be logged. Attach the 3 appenders to the root logger, then set the threshold level on the individual appenders themselves. > -Original Message- > From: Richard Bair [mailto:[EMAIL PROTECTED]]

Multiple Levels per Category/Logger

>From looking in the code it looks like (with the properties files for sure, but with the xml files as well it appears) we can only assign one level per category/logger. Is this correct? The basic idea is that, say, any warnings received at the root level we'd like to log to 3 different appenders

RE: JDBCAppender memory leak issue

I will look at it. From what I've seen, it didn't look overly complicated, but I know how database code can get ... especially when you're trying to be RDBMS neutral. Please give me a few days to get back to you (I'm also busy of course). Also, the CLOB support was another point of importance,

RE: JDBCAppender memory leak issue

Mike, Have you looked at the code of JDBC Appender? If so, what do you think? At 13:37 12.02.2003 -0500, you wrote: Ceki, Is there anything we can do to help ensure JDBC is supported continuously? It sounds like the JDBC Appender has been a headache for you and you want to focus more on core

RE: JDBCAppender memory leak issue

Ceki, Is there anything we can do to help ensure JDBC is supported continuously? It sounds like the JDBC Appender has been a headache for you and you want to focus more on core Log4j functionality (understandable). The database stuff certainly can be time consuming. When you remove the JDBC Ap

RE: Configuration GUI

Yeah, maybe "core" is not the right word here. We need to distinguish between what we are currently calling core (Logger, LoggerRepository, filters, layouts, appenders, etc) and dependent supplemental tools like Chainsaw, LF5, etc. Yes, they are part of log4j, but they are not needed to use the "

RE: Configuration GUI

At 11:55 12.02.2003 -0800, you wrote: > The commons-beanutils package is great. I use it all the time. > Unfortunately, it depends on the commons-logging API which makes it > unsuitable for use within log4j. Ceki, I understand why this is true for the core log4j classes, but is this also true

RE: Configuration GUI

> The commons-beanutils package is great. I use it all the time. > Unfortunately, it depends on the commons-logging API which makes it > unsuitable for use within log4j. Ceki, I understand why this is true for the core log4j classes, but is this also true for stand alone tools like this proposed

Re: Configuration GUI

On Tuesday, February 11, 2003, at 11:35 PM, Richard Bair wrote: BTW, Mark, I'm totally wrong. The java.beans package goes all the way back to 1.2.2 at least. I think it will work well for what we are doing here. if you're using java 1.3 (and maybe some earlier versions), you need to be a b

RE: Property Config order independent?

Duly noted :-) On Wed, 2003-02-12 at 11:30, Shapira, Yoav wrote: > > Howdy, > Please replace someset therefore with subset thereof. Not focused today > ;( > > Yoav Shapira > Millennium ChemInformatics > > > >-Original Message- > >From: Shapira, Yoav > >Sent: Wednesday, February 12, 2

RE: Property Config order independent?

Howdy, Please replace someset therefore with subset thereof. Not focused today ;( Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Shapira, Yoav >Sent: Wednesday, February 12, 2003 1:15 PM >To: Log4J Developers List >Subject: RE: Property Config order independent? > >

RE: Property Config order independent?

Howdy, FYI: this is a common problem. We would appreciate it if you could donate your modified properties class or someset therefore (e.g. PropertiesSerializer), under the Apache license, to the commons-configuration project ;) Yoav Shapira Millennium ChemInformatics >-Original Message--

RE: Property Config order independent?

Even better, if the resulting file had comments! That is another nasty side effect of using java.util.Properties to do the work - it strips out the comments. :-( Most likely, I'll have to write my own Properties class that does the same basic thing as the java.util.Properties to avoid some of th

RE: Configuration GUI

> Many parts of the java.beans package are JDK 1.4 specific other parts are > date back to JDK 1.1. What do you need to do exactly? By the way, log4j has > its own beans processing tools in o.a.log4j.config package. They are not as > complete as > commons-beanutils but they get the job done (at

RE: Open source licensing (was RE: Configuration GUI)

All, Perhaps I'm dense for looking for a technological solution to an ideological problem, but can't this be resolved with an abstraction layer? For example, Apache doesn't seem to mind the dependency on javax.xml.*. Nevertheless, this allows one to use GNU-licensed libraries with Apache produ

RE: JDBCAppender memory leak issue

No - but doesn't say anything about when is to be removed and replacements. -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 11:13 AM To: Log4J Developers List Subject: RE: JDBCAppender memory leak issue Have you missed this? http://jak

RE: JDBCAppender memory leak issue

Have you missed this? http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/jdbc/JDBCAppender.html At 10:21 12.02.2003 -0500, you wrote: We are already using JDBCAppender Could you please elaborate more on the plans for JDBCAppender ? When is to be removed ? Any replacement ? Thanks, Ema

Re: Open source licensing (was RE: Configuration GUI)

I guess I'll have to take a closer look myself and digest some of these issues before commenting further. thanks for the pointer to the discussion. Jake At 03:30 PM 2/12/2003 +0100, you wrote: Having just looked at the LGPL more closely, it may be almost as viral as the GPL. See also http:/

RE: JDBCAppender memory leak issue

We are already using JDBCAppender Could you please elaborate more on the plans for JDBCAppender ? When is to be removed ? Any replacement ? Thanks, Ema -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 10:11 AM To: Log4J Developers List Su

Re: JDBCAppender memory leak issue

JDBCAppender is likely to be removed. At 10:04 12.02.2003 -0500, you wrote: How long does something like this typically take to resolve? ... and does it mean going to a version greater than 1.2.7? I apologize for my newness to this process. We're intended to use the JDBC appender and this co

JDBCAppender memory leak issue

How long does something like this typically take to resolve? ... and does it mean going to a version greater than 1.2.7? I apologize for my newness to this process. We're intended to use the JDBC appender and this could obviously be problematic. Mike -Original Message- From: [EMAIL

RE: Property Config order independent?

The PropertyConfigurator does not depend on the order of directives in the property file. Why should an non-existent restriction be introduced? By the way, the DOMConfigurator part of log4j.dtd might disappear in the future as DOMConfigurator might be allowing things so rich that cannot be ex

DO NOT REPLY [Bug 16998] New: - JDBCAppender leaks memory

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://nagoya.apache.org/bugzilla/show_bu

RE: Property Config order independent?

Why not follow the (implied) order that the XML DOMConfigurator follows, as determined by the associated DTD? If nothing else, it would establish a consistency if ordering/dependency issues come to light. -d At 02:08 PM 2/11/2003 -0800, Mark Womack wrote: It would be nice if the properties we

Re: Open source licensing (was RE: Configuration GUI)

Having just looked at the LGPL more closely, it may be almost as viral as the GPL. See also http://marc.theaimsgroup.com/?t=10447722553&r=1&w=2 At 08:14 12.02.2003 -0600, you wrote: Hi Ceki, I concur with your sentiments. I don't know the details of Apache's dislike for the LGPL licence

SV: SV: Configuration GUI

Hi Jake I guess this could be an issue - However Log4J already relies on other libraries as far as I can see (not the core stuff - but utilities like this). JAXB is an javax. library (java API extention). Just my 2c :) Hermod -Opprinnelig melding- Fra: Jacob Kjome [mailto:[EMAIL PROTE

Open source licensing (was RE: Configuration GUI)

Hi Ceki, I concur with your sentiments. I don't know the details of Apache's dislike for the LGPL licence but, on the face of it, it seems just silly. It is obvious to anyone and everyone what intent an author has when he/she puts their library under LGPL. It is meant to be freely useable a

Re: SV: Configuration GUI

Hi Hermod, JAXB would be somewhat undesirable, IMHO, because the JAXB libraries would be required at runtime in order for the generated classes to work. If a DTD is all that is required, then a much better solution is Zeus. http://zeus.enhydra.org/index.html The generated classes are totally

SV: Configuration GUI

Hi Make it open ended - Meaning that the actual serialization/deserialization of the properties is plugable. If someone could send me the DTD/XSD for the XML configuration file, I'll be happy to create the java stuff (using JAXB). regards HErmod -Opprinnelig melding- Fra: Richard Bair [m

RE: Configuration GUI

At 16:28 11.02.2003 -0700, Richard Bair wrote: I initially tried to use beanutils for the project, and to some extent it worked well. I just found after 3 or 4 refactorings that the stuff that was bundled with Java was much better suited to what I was trying to do. I can look at it again for thi

RE: Configuration GUI

My suggestion would be to use BSD or MIT. Obviously, Apache license is more than fine. Also check out the Open Software License. http://opensource.org is a good source of further information. LPGL is apparently not acceptable although I would not be able to explain the reasons with a straight