Re: [VOTE] [logging] release plan for 1.0.4 release

+1 On Thu, 27 May 2004 22:52:55 +0100, robert burrell donkin <[EMAIL PROTECTED]> wrote: > > (please note that this is just the VOTE for the release plan, not the > VOTE for the release!) > > the plan is in place for commons-logging 1.0.4 release > (http://wiki.apache.org/jakarta-commons/Logging/

DO NOT REPLY [Bug 29263] New: - Getting error in junit3.8.1 --> Log4JLogger does not implement Log

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: [sandbox] removing/archiving jrcs

Okay, I'll make it so. Hen On Thu, 27 May 2004, Stephen Colebourne wrote: > From: "robert burrell donkin" <[EMAIL PROTECTED]> > > > Can we kill the version in the sandbox somehow, and does anyone have > > > any > > > good ideas on the best way to kill said version? > > > > AFAIK it's against po

Re: [sandbox] removing/archiving jrcs

From: "robert burrell donkin" <[EMAIL PROTECTED]> > > Can we kill the version in the sandbox somehow, and does anyone have > > any > > good ideas on the best way to kill said version? > > AFAIK it's against policy to delete ASF copyright material. > > we could remove the source from cvs (but not de

[Jakarta Commons Wiki] Updated: TheSandbox

Date: 2004-05-27T15:16:56 Editor: 217.42.133.87 <> Wiki: Jakarta Commons Wiki Page: TheSandbox URL: http://wiki.apache.org/jakarta-commons/TheSandbox no comment Change Log: -- @@ -30,3 +30,8 @@ * peri

[VOTE] [logging] release plan for 1.0.4 release

(please note that this is just the VOTE for the release plan, not the VOTE for the release!) the plan is in place for commons-logging 1.0.4 release (http://wiki.apache.org/jakarta-commons/Logging/1_2e0_2e4ReleasePlan). i'd like to propose i act as release manager for the 1.0.4 release and prep

[Jakarta Commons Wiki] Updated: Logging/1.0.4ReleasePlan

Date: 2004-05-27T14:42:40 Editor: 82.38.65.173 <> Wiki: Jakarta Commons Wiki Page: Logging/1.0.4ReleasePlan URL: http://wiki.apache.org/jakarta-commons/Logging/1.0.4ReleasePlan no comment Change Log: --

Re: [sandbox] removing/archiving jrcs

On 27 May 2004, at 21:57, Henri Yandell wrote: JRCS now lives outside of Jakarta and I don't believe we had any interest in maintaining/developing our version at all as the primary (only) developer is with the one outside of Jakarta. Can we kill the version in the sandbox somehow, and does anyone

Re: [logging] ServletContextLogger

On 27 May 2004, at 15:29, Inger, Matthew wrote: Some points: 1. The classloader for any thread in a servlet container is guarnteed to be unique per Web Application (context). Each Web Application has it's own classloader, which is part of the servlet spec. I'm not sure i understand

[Jakarta Commons Wiki] Updated: TheSandbox

Date: 2004-05-27T14:04:07 Editor: 216.26.136.155 <> Wiki: Jakarta Commons Wiki Page: TheSandbox URL: http://wiki.apache.org/jakarta-commons/TheSandbox no comment Change Log: -- @@ -1,6 +1,6 @@ = Publis

[Jakarta Commons Wiki] Updated: TheSandbox

Date: 2004-05-27T13:57:24 Editor: 217.42.133.87 <> Wiki: Jakarta Commons Wiki Page: TheSandbox URL: http://wiki.apache.org/jakarta-commons/TheSandbox no comment Change Log: -- @@ -1,12 +1,14 @@ = Publi

[sandbox] removing/archiving jrcs

JRCS now lives outside of Jakarta and I don't believe we had any interest in maintaining/developing our version at all as the primary (only) developer is with the one outside of Jakarta. Can we kill the version in the sandbox somehow, and does anyone have any good ideas on the best way to kill sa

Re: DBCP Contribution: Replace System.out calls with Commons Logging

On 27 May 2004, at 14:58, Noel J. Bergman wrote: Craig R. McClanahan wrote: Noel J. Bergman wrote: The upcoming version 1.0.4 of commons-logging has an AvalonLogger So we create an AvalonLogger around our component's logger, and pass that to any object that uses commons-logging. I'm travelling and

[Jakarta Commons Wiki] Updated: TheSandbox

Date: 2004-05-27T13:33:19 Editor: 216.26.136.155 <> Wiki: Jakarta Commons Wiki Page: TheSandbox URL: http://wiki.apache.org/jakarta-commons/TheSandbox no comment Change Log: -- @@ -11,7 +11,7 @@ * Fun

[Jakarta Commons Wiki] Updated: TheSandbox

Date: 2004-05-27T13:31:56 Editor: 216.26.136.155 <> Wiki: Jakarta Commons Wiki Page: TheSandbox URL: http://wiki.apache.org/jakarta-commons/TheSandbox no comment Change Log: -- @@ -11,7 +11,7 @@ * Fun

[vfs] ftp and symbolic links

Hello ! I implemented the handlink of symbolic links on an ftp-server. Those links are now transparently handeled: Type: *) content size *) modification date *) and children are automatically fetched from the link destination. My first try was to introduce a new FileType (FileType.LINK), but this

cvs commit: jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/ftp FtpFileObject.java

imario 2004/05/27 13:15:28 Modified:vfs/src/java/org/apache/commons/vfs/provider/ftp FtpFileObject.java Log: transparently handle symbolic links, beside the file-type (which was the case currently) now content size modification date and children

[io] some criticism

some input for further io development. http://www.freeroller.net/page/fate/20040527#commons_io_by_retards_for 4 points I think: 1) Writer doesn't like true/false filters. basically the Null pattern. Nothing bad here I reckon. 2) Writer doesn't like the And/Or lego style of filte

cvs commit: jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/example ShowProperties.java

imario 2004/05/27 13:06:56 Modified:vfs/src/java/org/apache/commons/vfs/example ShowProperties.java Log: show the first 5 children-names of an folder Revision ChangesPath 1.4 +11 -2 jakarta-commons-sandbox/vfs/src/java/org/apache/common

cvs commit: jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/webdav WebdavClientFactory.java WebdavFileObject.java WebdavFileProvider.java WebDavFileSystem.java

imario 2004/05/27 12:09:37 Modified:vfs/src/java/org/apache/commons/vfs/provider/http HttpFileProvider.java HttpFileSystem.java vfs/src/java/org/apache/commons/vfs Resources.properties vfs/src/java/org/apache/commons/vfs/provider/sft

[math] ComplexFormat changes

Has anyone read my latest comment regarding the ComplexFormat issue: http://issues.apache.org/bugzilla/show_bug.cgi?id=29000? I never saw a message come across the mailing list. Anyway, I was waiting for some feedback before I proceeded. Brent Worden http://www.brent.worden.org/ --

DO NOT REPLY [Bug 23229] - File Upload Not Compatible With IE 5.2.3 MacOS X

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: [logging] ServletContextLogger

here's the general idea: public interface LogProvider { Log createLog(String name); Log createLog(Class clazz); } These instances would be discovered the first time a log was asked for. After determining which LogProvider to use, it would simply call the createLog method when a new insta

RE: [logging] ServletContextLogger

As stated in another posting, there would be no dependency. The discovery involves about 2 - 3 methods of small to medium length, and would reside directly in the commons-logging code. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 26, 2004 5:17 PM To

RE: [logging] ServletContextLogger

Some points: 1. The classloader for any thread in a servlet container is guarnteed to be unique per Web Application (context). Each Web Application has it's own classloader, which is part of the servlet spec. I'm not sure i understand what your saying here. 2. I wouldn't be using

Re: RE : RE : RE : [transaction] website -> solution

Thanks for your help! Dirk already pointed me in that direction... Cheers, Oliver Heritier Arnaud wrote: The problem you have is that in your project.properties you have : maven.xdoc.jsl=../../../jakarta-commons/commons-build/commons-site.jsl Maven doesn't find this file. You must have something li

cvs commit: jakarta-commons-sandbox/transaction project.properties

ozeigermann2004/05/27 07:10:18 Modified:transaction project.properties Log: Fixed path Revision ChangesPath 1.2 +1 -1 jakarta-commons-sandbox/transaction/project.properties Index: project.properties ===

Re: RE : [transaction] website

Aaaah, thanks a lot that fixed it... Cheers, Oliver Dirk Verbeeck wrote: Do you have the following directory structure E:/workspace/jakarta-commons/commons-build E:/workspace/jakarta-commons-sandbox/commons-build E:/workspace/jakarta-commons-sandbox/transaction E:/workspace/jakarta-commons-sandbox/

RE : RE : RE : [transaction] website -> solution

The problem you have is that in your project.properties you have : maven.xdoc.jsl=../../../jakarta-commons/commons-build/commons-site.jsl Maven doesn't find this file. You must have something like : maven.xdoc.jsl=../sandbox-build/commons-site.jsl Or maven.xdoc.jsl=${basedir}/../../jakarta-comm

Re: RE : [transaction] website

Do you have the following directory structure E:/workspace/jakarta-commons/commons-build E:/workspace/jakarta-commons-sandbox/commons-build E:/workspace/jakarta-commons-sandbox/transaction E:/workspace/jakarta-commons-sandbox/vfs project.properties refers to maven.xdoc.jsl=../../../jakarta-commons/

RE: DBCP Contribution: Replace System.out calls with Commons Logging

Craig R. McClanahan wrote: > Noel J. Bergman wrote: >>> The upcoming version 1.0.4 of commons-logging has an AvalonLogger >> So we create an AvalonLogger around our component's logger, and pass >> that to any object that uses commons-logging. > I'm travelling and away from my CVS sources for [loggi

RE : RE : [transaction] website

Do you have the same error with RC3 ?? I think that this problem was an known bug resolved in the RC3. http://jira.codehaus.org/browse/MPXDOC-93 http://jira.codehaus.org/browse/MPXDOC-84 Arnaud. > -Message d'origine- > De : Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Envoyé : jeud

Re: RE : [transaction] website

Here it is (this was generated using Maven 1.0-rc1): xdoc:jelly-transform: [echo] Generating E:/workspace/jakarta-commons-sandbox/vfs/target/docs/changelog-report.html from E:\workspace\jakarta-commons-sandbox\vfs\target\generated-xdocs\changelog-report.xml BUILD FAILED File.. file:/C:/

RE : [transaction] website

Can't you send us (maven-users) the log for your problem. We will try to help us. Arnaud > -Message d'origine- > De : Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 27 mai 2004 12:39 > À : Jakarta Commons Developers List > Objet : Re: [transaction] website > > > Sorry, u

Re: [transaction] website

For commons packages everything works fine, but for commons sandbox packages maven site fails... Oliver Zeigermann wrote: Sorry, using rc1 does not help. The script fails at a position where a stylesheet var is accessed which obviously is null. Are there any files missing in the transaction pac

Re: [transaction] website

Sorry, using rc1 does not help. The script fails at a position where a stylesheet var is accessed which obviously is null. Are there any files missing in the transaction package? Oliver Dirk Verbeeck wrote: I'm still using rc1. It works for me and it seems the best release candidate, both rc2 a