Re: Avalon Logging Toolkit

ct that what became logkit was actually a part of an apache codebase before log4j ever was, and you get the current state. While I'm not exactly thrilled with duplication, I certainly prefer it over blocking other people's work. - Sam Ruby -- To unsubscribe, e-mail: <mailto:[E

[GUMP] Build Failure - Poi

FYI - Sam Ruby -- Forwarded by Sam Ruby/Raleigh/IBM on 02/13/2002 12:39 PM --- Sam Ruby/Raleigh/IBM@IBMUS on 02/12/2002 09:04:46 AM Please respond to [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: Subject:[GUMP] Build Failure - Poi

cvs checkout permission errors

I'm getting permission errors obtaining a lock: /home/cvs/jakarta-log4j/src/xdocs/stylesheets/#cvs.lock ceki, if you could chmod g+w /home/cvs/jakarta-log4j/src/xdocs/stylesheets I would appreciate it. - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For

Re: [GUMP] Build Failure - jakarta-avalon-logkit

umerate the ones you want. cheers, - Leo Thanks! - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP] Build Failure - Log4j

This email is autogenerated from the output from: Buildfile: build/build.xml init: build.core: [mkdir] Created dir:

Re: [GUMP] Build Failure - Log4j

successfully from CVS. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP] Build Failure - Log4j

This email is autogenerated from the output from: Buildfile: build/build.xml init: build.core: [mkdir] Created dir:

Re: log4j changes impacting velocity

Ceki Gülcü wrote: > > Sam is a pain in the butt but he also happens to be right. ;-) - Sam Ruby

log4j changes impacting velocity

efined in class org.apache.log4j.net.SMTPAppender. [javac] appender.setOption(SMTPAppender.BUFFER_SIZE_OPTION, bufferSize); [javac]^ [javac] Note: 2 files use or override a deprecated API. Recompile with "-deprecation" for details. [javac] 6

[PATCH] build failure

this case. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: log4j changes impacting velocity

best course of action is the one that Anders Kristensen has outlined. Thanks Anders! - Sam Ruby

[GUMP] Build Failure - Velocity

Still a problem? - Sam Ruby -- Forwarded by Sam Ruby/Raleigh/IBM on 03/21/2001 01:58 PM --- Sam Ruby/Raleigh/IBM@IBMUS on 03/21/2001 11:25:36 AM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: [GUMP] Build Failure

No more setMaxFileSize?

duces at: http://jakarta.apache.org/builds/gump/2001-04-18/jakarta-velocity.html - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: [GUMP] Build Failure - Velocity]

Ceki - here's a thought. Add logic to org.apache.log4j.config.PropertySetter.getArg to understand the various units. Would mean that you could specify 3M (or perhaps 3MB) to *ANY* property which accepts a long... - Sam

build.unitTests is failing for me

Example: UnitTestDRFA doesn't import org.apache.log4j.*, and even if it did, computeCheckPeriod() is not public. I'm building with JDK 1.3. I'm not sure, but I think that prior versions may have been lax in this ar

[GUMP] Various log4j related breakages

/jakarta-slide.html - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: [GUMP] Various log4j related breakages

Ceki Gülcü wrote: > > The recent fixes should fix velocity and taglibs but not jakarta-slide. As you predicted, velocity and taglibs now compile cleanly. No longer held up by a pre-req, I'm now seeing: http://nagoya.apache.org/~rubys/gump/jakarta-turbine-3.html

Re: [GUMP] Various log4j related breakages

[javac] symbol : method getCurrentCategories () [javac] location: class org.apache.log4j.Hierarchy and Explicit cast needed to convert org.apache.log4j.Priority to org.apache.log4j.Level. - Sam Ruby - To unsubscribe,

Re: [GUMP] Various log4j related breakages

[javac] Category.getDefaultHierarchy().getCurrentCategories(); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 1 error

Are Category methods prematurely deprecated?

(collectively) feel is the right time for log4j customers to evaluate their usage of these messages. Below is an example of some of the methods that I'm concerned about. - Sam Ruby >> compile: >> [javac] Compiling 180 source files to >> D:\jakarta\xml-axis\java\buil

Re: Are Category methods prematurely deprecated?

ntually, however Category will be deprecated and ultimately removed. Is this a fair assessment of the current situation? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: Are Category methods prematurely deprecated?

e to now. I asked you privately if I should code to Logger now, and you discouraged me. Now I am confused. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

[PATCH] build failure: JMSSink.java

org.apache.log4j.PropertyConfigurator; import org.apache.log4j.helpers.LogLog; - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Category.getDefaultHierarchy().enableAll();

is is not a very backwards compatible change... Question: What should the tyrex development team use at the present time? Is there an API that works with 1.1.3 that will continue to work in the next release of log4j - deprecated or otherwise? - Sam

Re: [tyrex-dev] Tomcat 4.0 Tyrex configuration

this code, I will vote against the release. - Sam Ruby -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: [GUMP] Build Failure - Security

Is there a reason the DOMConfigurator.configure(org.w3c.dom.Element) method was commented out? See http://cvs.apache.org/viewcvs/jakarta-log4j/src/java/org/apache/log4j/xml/DOMConfigurator.java?rev=1.40&content-type=text/vnd.viewcvs-markup - Sam Ruby -- Forwarded by

RE: Folding log4j-cvs into log4j-dev

My feeling, for what it is worth: merging the -dev and -cvs mailing lists has two effects: (1) cvs commits get a larger audience, and (2) non-developers flee to the -user mailing list. I consider both effects positive. This being said, I view the choice of mailing list structure are subproject

RE: cvs commit: jakarta-alexandria/proposal/gump/project jakarta-log4j.xml

Currently the log4j dist tag does not produce javadocs. Can either this be corrected, or alternately can a new target be created which does both what the current distribution does and creates the javadocs? Thanks! - Sam Ruby > -Original Message- > From: [EMAIL PROTECTED] [