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

2004-05-27 Thread Dion Gillard 
+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/1_2e0_2e4ReleasePlan).
> i'd like to propose i act as release manager for the 1.0.4 release and
> prepared the release (according to the plan) ready for a release vote
> early next week. note that if this plan is approved, no release branch
> will be taken so please consider the code frozen (except for those
> changes outlined in the plan).
> 
> people have until 11pm GMT saturday 29th to cast their votes.
> 
> here my +1
> 
> - robert
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

2004-05-27 Thread bugzilla 
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_bug.cgi?id=29263

Getting error in junit3.8.1 --> Log4JLogger does not implement Log

   Summary: Getting error in junit3.8.1 --> Log4JLogger does not
implement Log
   Product: Commons
   Version: 1.0.3
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Logging
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


While running the Swing test runner from junit and using the commons_logging 
1.0.3, I get and logger configuration error. The error in effect says 
Log4JLogger does not implement Log. I recompiled commons_logging to see if I 
still get the error and it still came back with the same error. It appears that 
the there are two different class loaders conflicting with each other that is 
causing this problem. Apparently at startup, Log is loaded by one class loader 
while the Log4JLogger is loaded by another which then causes 
class.isAssignableFrom to return false.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sandbox] removing/archiving jrcs

2004-05-27 Thread Henri Yandell 

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 policy to delete ASF copyright material.
> >
> > we could remove the source from cvs (but not delete) but it might be a
> > good idea to tag before so that any who's interested can easily recover
> > it and maybe leave a README in the old directory.
>
> This seems to be the best solution for sandbox projects. (util and pattern
> have gone this way, as have promoted projects)
>
> Stephen
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sandbox] removing/archiving jrcs

2004-05-27 Thread Stephen Colebourne 
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 delete) but it might be a
> good idea to tag before so that any who's interested can easily recover
> it and maybe leave a README in the old directory.

This seems to be the best solution for sandbox projects. (util and pattern
have gone this way, as have promoted projects)

Stephen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta Commons Wiki] Updated: TheSandbox

2004-05-27 Thread commons-dev 
   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 @@
  * periodicity
  * reflect - extracted from BeanUtils, but unfinished and in a coma.
  * transaction - extracted from Slide, ready for promotion.
+
+= Superseded =
+
+ * jjar - superseded by [http://incubator.apache.org/depot/ Apache Depot] (currently 
in the incubator)
+ * Apache cjan - superseded by [http://incubator.apache.org/depot/ Apache Depot] 
(currently in the incubator)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[VOTE] [logging] release plan for 1.0.4 release

2004-05-27 Thread robert burrell donkin 
(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 
prepared the release (according to the plan) ready for a release vote 
early next week. note that if this plan is approved, no release branch 
will be taken so please consider the code frozen (except for those 
changes outlined in the plan).

people have until 11pm GMT saturday 29th to cast their votes.
here my +1
- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta Commons Wiki] Updated: Logging/1.0.4ReleasePlan

2004-05-27 Thread commons-dev 
   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:

--
@@ -34,11 +34,11 @@
  1. close and document craig's comments in FAQ
  1. inclined to support this enhancement (robert burrell donkin)
  1. need more time to think about this one (see comments). probably one to mark LATER
- 1. inclined to support this enhancement (robert burrell donkin)
+ 1. inclined to support this enhancement (robert burrell donkin) but am inclined to 
mark LATER
 
 == Bug Fix ==
 
-Fix any bugs highlighted by the review.
+Work required on issues 2 and 3 in this list
 
 == Test Compatibility ==
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [sandbox] removing/archiving jrcs

2004-05-27 Thread robert burrell donkin 
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 have 
any
good ideas on the best way to kill said version?
AFAIK it's against policy to delete ASF copyright material.
i'd say that the best policy might be to remove the links to the 
website and redirect the jrcs (add a .htaccess) to a simple page saying 
something like "JRCS is no longer under active development here at 
Jakarta. The source is still available from CVS. A fork is under active 
development at codehaus."

we could remove the source from cvs (but not delete) but it might be a 
good idea to tag before so that any who's interested can easily recover 
it and maybe leave a README in the old directory.

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [logging] ServletContextLogger

2004-05-27 Thread robert burrell donkin 
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
what your saying here.
it's not quite as simple as that :)
each class has a classloader. the class classloader is the loader that 
loads the class. the classloader is not necessarily the same as the 
context classloader attached to the thread in a container environment. 
for example, the class classloader is the root classloader if the class 
is on the root classpath. therefore, for some classes, the class 
classloader may be shared between web applications. the context 
classloader is unique (between web applications).

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta Commons Wiki] Updated: TheSandbox

2004-05-27 Thread commons-dev 
   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 @@
 = Published =
 
-What does ''published'' mean?
+(Published means that the sandbox project is on the Jakarta Commons website)
 
  * Attributes - stable codebase, small community, ready for promotion.
  * Cache

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta Commons Wiki] Updated: TheSandbox

2004-05-27 Thread commons-dev 
   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 @@
 = Published =
 
+What does ''published'' mean?
+
  * Attributes - stable codebase, small community, ready for promotion.
  * Cache
  * Chain - needed for Struts 1.3.x, ready for promotion?
  * Clazz - no community, code stable.
  * Compress - code extracted from Ant, currently dormant.
  * Convert - various conversion ideas extracted from BeanUtils, currently in 
development.
- * Email - lacking developer community, has users, stable codebase.
+ * Email - The code (mainly from Turbine) is stable and has a user base but is 
unreleased. Currently lacking maintainers.
  * Events - currently in slow development.
  * Functor
  * Id - parts from Lang, parts new, currently in-development.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[sandbox] removing/archiving jrcs

2004-05-27 Thread Henri Yandell 

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 said version?

Hen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

2004-05-27 Thread robert burrell donkin 
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 away from my CVS sources for [logging], but I'm
pretty sure that the 1.0.4 code even auto-recognizes the availability
of the Avalon logger like it does Log4J and JDK 1.4 logging.  If it
doesn't, I'd be happy to implement that before a [logging] 1.0.4 
release.
Craig, how does that work?  By that, I mean, Avalon uses an IoC model, 
so
how does the Commons Logger know which logger to use?  For example, I 
would
want DBCP to be using the logger defined for the database connection
component.  At present, we create an adapter between what DBCP expects
(PrintWriter) and the Avalon logger, but I'd very much like to see
full-fledged logging with levels.
hi noel
the current avalon logger implementation allows a default logger to be 
set by a static method call. the implementation then gets a child 
logger (by name) from that logger.

i was looking at this a little while ago and thinking to myself: this 
isn't too clever. at the very least, it should allow default loggers to 
be set per context classloader (to provide isolation in a container 
environment). i may refactor the logger (once the 1.0.4 release is 
done).

a while ago, leo was talking about IoC and logging. he points was that 
it's not really the design of the commons-logging API but the use of 
that API that allows it to be used (or not) in an IoC environment. the 
key is that it should be possible to set the log implementations used 
by the component.

- robert
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta Commons Wiki] Updated: TheSandbox

2004-05-27 Thread commons-dev 
   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 @@
  * Functor
  * Id - parts from Lang, parts new, currently in-development.
  * JJar
- * JRCS - No longer really hosted by Jakarta. It has moved to Codehaus (need to find 
URL of their CVS module)
+ * JRCS - No longer really hosted by Jakarta. It has moved to Codehaus 
(http://cvs.codehaus.org/viewcvs.cgi/jrcs/?root=codehaus)
  * Mapper
  * Messenger
  * Resources - needed for Struts 1.3.x, ready for promotion?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Jakarta Commons Wiki] Updated: TheSandbox

2004-05-27 Thread commons-dev 
   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 @@
  * Functor
  * Id - parts from Lang, parts new, currently in-development.
  * JJar
- * JRCS - the main version may no longer be hosted at Jakarta, ?
+ * JRCS - No longer really hosted by Jakarta. It has moved to Codehaus (need to find 
URL of their CVS module)
  * Mapper
  * Messenger
  * Resources - needed for Struts 1.3.x, ready for promotion?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[vfs] ftp and symbolic links

2004-05-27 Thread Mario Ivankovits 
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 
might break some existing implementation as. FileType.LINK !=  
FileType.FILE != FileType.FOLDER
I thought this is bad, and maybe the vfs user wont be bothered with 
links too much, other filesystems (http, webdav) handles links 
(redirects) automatically and so i thought doing this in ftp too might 
be a good thing.

However, comments are welcome.
-- Mario
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

2004-05-27 Thread imario 
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

  are automatically fetched from the link destination.
  
  Revision  ChangesPath
  1.25  +59 -13
jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java
  
  Index: FtpFileObject.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/ftp/FtpFileObject.java,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- FtpFileObject.java25 May 2004 14:43:01 -  1.24
  +++ FtpFileObject.java27 May 2004 20:15:28 -  1.25
  @@ -50,6 +50,7 @@
   // Cached info
   private FTPFile fileInfo;
   private FTPFile[] children;
  +private FileObject linkDestination;
   
   public FtpFileObject(final FileName name,
final FtpFileSystem fileSystem,
  @@ -215,15 +216,39 @@
   }
   else if (fileInfo.isSymbolicLink())
   {
  -// TODO - add generic support for links
  -final String path = fileInfo.getLink();
  -final FileObject target = getParent().resolveFile(path);
  -return target.getType();
  +return getLinkDestination().getType();
   }
   
   throw new FileSystemException("vfs.provider.ftp/get-type.error", getName());
   }
   
  +private FileObject getLinkDestination() throws FileSystemException
  +{
  +if (linkDestination == null)
  +{
  +final String path = fileInfo.getLink();
  +FileName relativeTo = getName().getParent();
  +if (relativeTo == null)
  +{
  +relativeTo = getName();
  +}
  +FileName linkDestinationName = relativeTo.resolveName(path);
  +linkDestination = getFileSystem().resolveFile(linkDestinationName);
  +}
  +
  +return linkDestination;
  +}
  +
  +protected FileObject[] doListChildrenResolved() throws Exception
  +{
  +if (fileInfo.isSymbolicLink())
  +{
  +return getLinkDestination().getChildren();
  +}
  +
  +return null;
  +}
  +
   /**
* Lists the children of the file.
*/
  @@ -328,7 +353,14 @@
*/
   protected long doGetContentSize() throws Exception
   {
  -return fileInfo.getSize();
  +if (fileInfo.isSymbolicLink())
  +{
  +return getLinkDestination().getContent().getSize();
  +}
  +else
  +{
  +return fileInfo.getSize();
  +}
   }
   
   /**
  @@ -338,14 +370,21 @@
*/
   protected long doGetLastModifiedTime() throws Exception
   {
  -Calendar timestamp = fileInfo.getTimestamp();
  -if (timestamp == null)
  +if (fileInfo.isSymbolicLink())
   {
  -return 0L;
  +return getLinkDestination().getContent().getLastModifiedTime();
   }
   else
   {
  -return (timestamp.getTime().getTime());
  +Calendar timestamp = fileInfo.getTimestamp();
  +if (timestamp == null)
  +{
  +return 0L;
  +}
  +else
  +{
  +return (timestamp.getTime().getTime());
  +}
   }
   }
   
  @@ -357,10 +396,17 @@
*/
   protected void doSetLastModifiedTime(final long modtime) throws Exception
   {
  -final Date d = new Date(modtime);
  -final Calendar c = new GregorianCalendar();
  -c.setTime(d);
  -fileInfo.setTimestamp(c);
  +if (fileInfo.isSymbolicLink())
  +{
  +getLinkDestination().getContent().setLastModifiedTime(modtime);
  +}
  +else
  +{
  +final Date d = new Date(modtime);
  +final Calendar c = new GregorianCalendar();
  +c.setTime(d);
  +fileInfo.setTimestamp(c);
  +}
   }
   
   /**
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[io] some criticism

2004-05-27 Thread Henri Yandell 

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 filters. I like this lego
style for comparators, but admit I don't do enough filter-ing to use them
in Filters. Still, he mainly is against the lego style I think, so again,
nothing to worry about.

3) DeferredOutputStream is pointless. Would be interesting to hear
Martin's view on his statement here.

4) IOUtils.toByteArray. Couple of things here, one that it's a method
created for symmetry which is better served by the JDK; two that IO lacks
encoding consideration.

Hen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

2004-05-27 Thread imario 
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/commons/vfs/example/ShowProperties.java
  
  Index: ShowProperties.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/example/ShowProperties.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ShowProperties.java   26 May 2004 08:22:07 -  1.3
  +++ ShowProperties.java   27 May 2004 20:06:56 -  1.4
  @@ -72,7 +72,16 @@
   }
   else if (file.getType().equals(FileType.FOLDER) && 
file.isReadable())
   {
  -System.out.println("Directory with " + 
file.getChildren().length + " files");
  +FileObject[] children = file.getChildren();
  +System.out.println("Directory with " + children.length + " 
files");
  +for (int iterChildren = 0; iterChildren < children.length; 
iterChildren++)
  +{
  +System.out.println("#" + iterChildren + ": " + 
children[iterChildren].getName());
  +if (iterChildren > 5)
  +{
  +break;
  +}
  +}
   }
   System.out.println("Last modified: " + 
DateFormat.getInstance().format(new Date(file.getContent().getLastModifiedTime(;
   }
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

2004-05-27 Thread imario 
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/sftp
SftpFileProvider.java SftpFileSystem.java
   vfs/src/java/org/apache/commons/vfs/provider/webdav
WebdavFileObject.java WebdavFileProvider.java
WebDavFileSystem.java
  Added:   vfs/src/java/org/apache/commons/vfs/provider/http
HttpClientFactory.java
   vfs/src/java/org/apache/commons/vfs/provider/sftp
SftpClientFactory.java
   vfs/src/java/org/apache/commons/vfs/provider/webdav
WebdavClientFactory.java
  Log:
  HTTP, FTP, SFTP, WEBDAV:

  create the used filesystem client before the filesystem itself to have a fail-fast 
behaviour if the host and/or user/password is wrong
  
  Revision  ChangesPath
  1.8   +13 -3 
jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/http/HttpFileProvider.java
  
  Index: HttpFileProvider.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/http/HttpFileProvider.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- HttpFileProvider.java 19 May 2004 19:34:06 -  1.7
  +++ HttpFileProvider.java 27 May 2004 19:09:37 -  1.8
  @@ -15,6 +15,7 @@
*/
   package org.apache.commons.vfs.provider.http;
   
  +import org.apache.commons.httpclient.HttpClient;
   import org.apache.commons.vfs.Capability;
   import org.apache.commons.vfs.FileName;
   import org.apache.commons.vfs.FileSystem;
  @@ -63,10 +64,19 @@
   /**
* Creates a [EMAIL PROTECTED] FileSystem}.
*/
  -protected FileSystem doCreateFileSystem(final FileName rootName, final 
FileSystemOptions fileSystemOptions)
  +protected FileSystem doCreateFileSystem(final FileName name, final 
FileSystemOptions fileSystemOptions)
   throws FileSystemException
   {
  -return new HttpFileSystem((GenericFileName) rootName, fileSystemOptions);
  +// Create the file system
  +final GenericFileName rootName = (GenericFileName) name;
  +
  +HttpClient httpClient = 
HttpClientFactory.createConnection(rootName.getHostName(),
  +rootName.getPort(),
  +rootName.getUserName(),
  +rootName.getPassword(),
  +fileSystemOptions);
  +
  +return new HttpFileSystem(rootName, httpClient, fileSystemOptions);
   }
   
   public FileSystemConfigBuilder getConfigBuilder()
  
  
  
  1.10  +4 -40 
jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/http/HttpFileSystem.java
  
  Index: HttpFileSystem.java
  ===
  RCS file: 
/home/cvs/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/http/HttpFileSystem.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- HttpFileSystem.java   19 May 2004 19:34:06 -  1.9
  +++ HttpFileSystem.java   27 May 2004 19:09:37 -  1.10
  @@ -15,14 +15,10 @@
*/
   package org.apache.commons.vfs.provider.http;
   
  -import org.apache.commons.httpclient.HostConfiguration;
   import org.apache.commons.httpclient.HttpClient;
  -import org.apache.commons.httpclient.MultiThreadedHttpConnectionManager;
  -import org.apache.commons.httpclient.UsernamePasswordCredentials;
   import org.apache.commons.vfs.FileName;
   import org.apache.commons.vfs.FileObject;
   import org.apache.commons.vfs.FileSystem;
  -import org.apache.commons.vfs.FileSystemException;
   import org.apache.commons.vfs.FileSystemOptions;
   import org.apache.commons.vfs.provider.AbstractFileSystem;
   import org.apache.commons.vfs.provider.GenericFileName;
  @@ -40,11 +36,12 @@
   implements FileSystem
   
   {
  -private HttpClient client;
  +private final HttpClient client;
   
  -public HttpFileSystem(final GenericFileName rootName, final FileSystemOptions 
fileSystemOptions)
  +public HttpFileSystem(final GenericFileName rootName, final HttpClient client, 
final FileSystemOptions fileSystemOptions)
   {
   super(rootName, null, fileSystemOptions);
  +this.client = client;
   }
   
   /**
  @@ -55,41 +52,8 @@
   caps.addAll(HttpFileProvider.capabilities);
   }
   
  -/**
  - * Returns the client for this file system.
  - */
   protected HttpClient getClient()
  -throws FileSystemException
   {
  -if (client == null)
  -{
  -// Create an Http client
  -final GenericFileName root

[math] ComplexFormat changes

2004-05-27 Thread brent 
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/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

2004-05-27 Thread bugzilla 
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_bug.cgi?id=23229

File Upload Not Compatible With IE 5.2.3 MacOS X





--- Additional Comments From [EMAIL PROTECTED]  2004-05-27 14:50 ---
I saw this thread and thought I'd give things a test, but as far as I can see I've a 
file upload working fine 
with MSIE 5.2. Why anybody would be silly enough to use it now there's safari, is 
another question.

This app i'm testing with is using the stable struts 1.1 release of struts with TC5. 
The only problem I'm 
having is with IE mac caching in its own gun slinging way so in my admin form i can 
see the new image 
when i'm forwarded back to the view (despite a reload to the original action). But its 
stored in the 
database just fine.

I'll try and break it but so far seems to be working fine, was the problem on a 
deployed apache to 
tomcat (jk and all that jazz) or just using built in http server?

I've just tested on our staging server.

Apache 2 + jk2 the same app, with msie 5.2 mac. And the same multipart form including 
an image 
upload worked just fine.

 Apache/2.0.49 (Unix) mod_jk2/2.0.5-dev

In case it makes any difference both machines i've tested on are osx 10.3 , but i 
really doubt this is the 
issue.

Just to make treble sure. I'll test when this app goes live with using jk1 again 
apache 2 on redhat linux, 
and also on the live version this particular form is served over https so thats 
another potential factor . 
And in case it makes any difference dev and stage configurations use tc 5.19 while the 
live deployment 
is new using 5.24.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [logging] ServletContextLogger

2004-05-27 Thread Inger, Matthew 
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 instance
was required.  Naturally, the LogFactory implementation which
would use this, would keep hold of the LogProvider once it was
found, and cache the Log instances, much like the existing implementation
does.  I can send you some example code if you'd like.

-Original Message-
From: Simon Kitching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 26, 2004 9:42 PM
To: Jakarta Commons Developers List
Subject: Re: [logging] ServletContextLogger


On Thu, 2004-05-27 at 08:22, Inger, Matthew wrote:

> PS:  I'm also willing to create a new implementation of LogFactory which
> will discover the available log implementations at runtime, rather than
the
> compile time strategy which exists now.

I'd be interested in seeing a proposal for this. I cannot think of any
mechanism for doing this that has reasonable performance.

Regards,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [logging] ServletContextLogger

2004-05-27 Thread Inger, Matthew 
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: Jakarta Commons Developers List
Subject: Re: [logging] ServletContextLogger



--- robert burrell donkin <[EMAIL PROTECTED]> wrote:


> > PS:  I'm also willing to create a new implementation of LogFactory 
> > which
> > will discover the available log implementations at runtime, rather 
> > than the
> > compile time strategy which exists now.
> 
> sounds interesting. the idea of using commons-discovery to find all 
> implementation at runtime has come up before but AFAIK without much 
> action.

IMO, adding a dependency to commons-logging is a very bad idea considering
how many other projects use it and have no need for commons-discovery.  If
commons-logging was released with another dependency I would just keep
using old versions to avoid the new dependency :-(.

David

> 
> - robert 





__
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [logging] ServletContextLogger

2004-05-27 Thread Inger, Matthew 
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 commons-discovery.  To me, logging is the most basic
functionality, and shouldn't have dependencies outside of the log
packages.
The discovery code is very simple (3 methods of relatively small size in
my
estimation), and would be included directly in the LogFactory
implemenation
class, or more likely, in a utility class.  The discovery file might
look like:

org.apache.commons.logging.impl.Log4JLogger
...

The order in the file, determines the search path.  When dealing with
multiple
resources, the order in which the resources are found is undetermined,
and this
is an issue we'd have to work out.  In most cases, we'll take the first
available
logger which can be used.  If the user wants a specific one, they can
set a system
property.

3.  I'd also like to refactor the existing logging classes to seperate each
logger
type out into it's own package.  ie.
org.apache.commons.logging.impl.log4j.Log4JLogger
Something like this would make it easier to create multiple build
artifacts, such as:

commons-logging-1.0.x-api.jar
commons-logging-1.0.x-log4j.jar
commons-logging-1.0.x-jdk14.jar
  etc


But this is something that can happen at a later date.

Plugging in the discovery mechanism would be the first thing i would do,
then implementation of the ServletContextLogger would come next.  It
would not affect the existing code. It would simply be an alternate
LogFactory implementation.

I am still waiting for my CLA to be processed (been several weeks now), so
I wouldn't be able to commit this myself.


-Original Message-
From: robert burrell donkin
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 26, 2004 5:11 PM
To: Jakarta Commons Developers List
Subject: Re: [logging] ServletContextLogger


On 26 May 2004, at 21:22, Inger, Matthew wrote:

hi matthew



> As far as initialization, it could provide a static method (since 
> there's
> only ever
> one ServletContext per web app anyway, a static variable will suffice),
> which could
> be called from the Servlet's init method.  (I'm open to other 
> suggestions
> here, but
> it's the only way i see to make this happen)
>
> public class ServletContextLogger {
>private static ServletContext context;
>
>public static synchronized init(ServletContext context) {
>   ServletContextLogger.context = context;
>}
>
>...
> }

the code you propose is unlikely to be safe in a servlet container 
environment. you'd have to use a per-context-classloader singleton. 
ideally, this would have to be held in a weak hashmap (to ensure that 
the context is garbage collection) but probably this should be 
discovered at runtime to allow better compatibility.

i'd probably not see this as part of the default logging compile time 
search (due to the fact that this registration stage is needed) but 
could be a good addition as an optional logger.

it may be a good idea to wait until after the upcoming 1.0.4 release 
before adding any new loggers.

> PS:  I'm also willing to create a new implementation of LogFactory 
> which
> will discover the available log implementations at runtime, rather 
> than the
> compile time strategy which exists now.

sounds interesting. the idea of using commons-discovery to find all 
implementation at runtime has come up before but AFAIK without much 
action.

- robert


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

2004-05-27 Thread Oliver Zeigermann 
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 like :
maven.xdoc.jsl=../sandbox-build/commons-site.jsl
Or
maven.xdoc.jsl=${basedir}/../../jakarta-commons/commons-build/commons-site.jsl
It is the same thing in vfs !!
I think that the error message is a little bit incomprehensible :-)
We will try to improve this !
Arnaud

-Message d'origine-
De : Heritier Arnaud 
Envoyé : jeudi 27 mai 2004 15:08
À : Jakarta Commons Developers List
Objet : 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é : jeudi 27 mai 2004 14:23
À : Jakarta Commons Developers List
Objet : 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-xdoc
s\changelog-report.xml

BUILD FAILED
File.. file:/C:/Dokumente und
Einstellungen/olli.C1-FSE/.maven/plugins/maven-xdoc-plugin-1.4/
Element... j:include
Line.. 333
Column 54
null:-1:-1:  Could not parse Jelly script
Total time: 50 seconds
Finished at: Thu May 27 13:02:01 CEST 2004
Thanks for helping!
Oliver
Heritier Arnaud wrote:

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, 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 and rc3 have some problems.
If you downgrade, don't forget to delete the .maven/plugins
directory

in
your home directory.
-- Dirk
Oliver Zeigermann wrote:

Sorry for bothering, but I do not know where to turn to in this 
matter.

marven site
does not work for me because of a problem reported by the jelly 
plugin both with rc2 and rc3. Does it work for you?

Thanks in advance,
Oliver




-
To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: 
[EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

2004-05-27 Thread ozeigermann 
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
  ===
  RCS file: /home/cvs/jakarta-commons-sandbox/transaction/project.properties,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- project.properties22 May 2004 12:39:24 -  1.1
  +++ project.properties27 May 2004 14:10:18 -  1.2
  @@ -6,7 +6,7 @@
   maven.javadoc.author=false
   maven.javadoc.links=http://java.sun.com/products/jdk/1.4/docs/api
   
  -maven.xdoc.jsl=../../../jakarta-commons/commons-build/commons-site.jsl
  +maven.xdoc.jsl=../../jakarta-commons/commons-build/commons-site.jsl
   maven.xdoc.date=bottom
   maven.xdoc.poweredby.image=maven-feather.png
   maven.xdoc.version=${pom.currentVersion}
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RE : [transaction] website

2004-05-27 Thread Oliver Zeigermann 
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/vfs
project.properties refers to
maven.xdoc.jsl=../../../jakarta-commons/commons-build/commons-site.jsl
Damn, I see the problem now. A ../ too much.
It should be:
maven.xdoc.jsl=../../jakarta-commons/commons-build/commons-site.jsl
I don't have the problem because jakarta-commons is on the root dir but 
in your setup it goes a level too far.

Can you try changing that property?
-- Dirk
Oliver Zeigermann wrote:
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:/Dokumente und 
Einstellungen/olli.C1-FSE/.maven/plugins/maven-xdoc-plugin-1.4/
Element... j:include
Line.. 333
Column 54
null:-1:-1:  Could not parse Jelly script
Total time: 50 seconds
Finished at: Thu May 27 13:02:01 CEST 2004

Thanks for helping!
Oliver
Heritier Arnaud wrote:
Can't you send us (maven-users) the log for your problem.
We will try to help us.
Arnaud


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

2004-05-27 Thread Heritier Arnaud 
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-commons/commons-build/commons-site.jsl

It is the same thing in vfs !!

I think that the error message is a little bit incomprehensible :-)

We will try to improve this !

Arnaud

> -Message d'origine-
> De : Heritier Arnaud 
> Envoyé : jeudi 27 mai 2004 15:08
> À : Jakarta Commons Developers List
> Objet : 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é : jeudi 27 mai 2004 14:23
> > À : Jakarta Commons Developers List
> > Objet : 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-xdoc
> > s\changelog-report.xml
> > 
> > BUILD FAILED
> > File.. file:/C:/Dokumente und
> > Einstellungen/olli.C1-FSE/.maven/plugins/maven-xdoc-plugin-1.4/
> > Element... j:include
> > Line.. 333
> > Column 54
> > null:-1:-1:  Could not parse Jelly script
> > Total time: 50 seconds
> > Finished at: Thu May 27 13:02:01 CEST 2004
> > 
> > Thanks for helping!
> > 
> > Oliver
> > 
> > Heritier Arnaud wrote:
> > 
> > > 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, 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 and rc3 have some problems.
> > >>>
> > >>>If you downgrade, don't forget to delete the .maven/plugins
> > >>
> > >>directory
> > >>
> > >>>in
> > >>>your home directory.
> > >>>
> > >>>-- Dirk
> > >>>
> > >>>Oliver Zeigermann wrote:
> > >>>
> > >>>
> > Sorry for bothering, but I do not know where to turn to in this 
> > matter.
> > 
> > marven site
> > 
> > does not work for me because of a problem reported by the jelly 
> > plugin both with rc2 and rc3. Does it work for you?
> > 
> > Thanks in advance,
> > 
> > Oliver
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > -
> > >>
> > >>>To unsubscribe, e-mail: 
> [EMAIL PROTECTED]
> > >>>For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > >>>
> > >>
> > >>
> > >>
> > -
> > >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >>For additional commands, e-mail: 
> [EMAIL PROTECTED]
> > >>
> > >>
> > > 
> > > 
> > > 
> > 
> -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: 
> [EMAIL PROTECTED]
> > > 
> > 
> > 
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RE : [transaction] website

2004-05-27 Thread Dirk Verbeeck 
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/commons-build/commons-site.jsl
Damn, I see the problem now. A ../ too much.
It should be:
maven.xdoc.jsl=../../jakarta-commons/commons-build/commons-site.jsl
I don't have the problem because jakarta-commons is on the root dir 
but in your setup it goes a level too far.

Can you try changing that property?
-- Dirk
Oliver Zeigermann wrote:
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:/Dokumente und 
Einstellungen/olli.C1-FSE/.maven/plugins/maven-xdoc-plugin-1.4/
Element... j:include
Line.. 333
Column 54
null:-1:-1:  Could not parse Jelly script
Total time: 50 seconds
Finished at: Thu May 27 13:02:01 CEST 2004

Thanks for helping!
Oliver
Heritier Arnaud wrote:
Can't you send us (maven-users) the log for your problem.
We will try to help us.
Arnaud


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

2004-05-27 Thread Noel J. Bergman 
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 [logging], but I'm
> pretty sure that the 1.0.4 code even auto-recognizes the availability
> of the Avalon logger like it does Log4J and JDK 1.4 logging.  If it
> doesn't, I'd be happy to implement that before a [logging] 1.0.4 release.

Craig, how does that work?  By that, I mean, Avalon uses an IoC model, so
how does the Commons Logger know which logger to use?  For example, I would
want DBCP to be using the logger defined for the database connection
component.  At present, we create an adapter between what DBCP expects
(PrintWriter) and the Avalon logger, but I'd very much like to see
full-fledged logging with levels.

--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE : RE : [transaction] website

2004-05-27 Thread Heritier Arnaud 
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é : jeudi 27 mai 2004 14:23
> À : Jakarta Commons Developers List
> Objet : 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-xdoc
> s\changelog-report.xml
> 
> BUILD FAILED
> File.. file:/C:/Dokumente und 
> Einstellungen/olli.C1-FSE/.maven/plugins/maven-xdoc-plugin-1.4/
> Element... j:include
> Line.. 333
> Column 54
> null:-1:-1:  Could not parse Jelly script
> Total time: 50 seconds
> Finished at: Thu May 27 13:02:01 CEST 2004
> 
> Thanks for helping!
> 
> Oliver
> 
> Heritier Arnaud wrote:
> 
> > 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, 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 and rc3 have some problems.
> >>>
> >>>If you downgrade, don't forget to delete the .maven/plugins
> >>
> >>directory
> >>
> >>>in
> >>>your home directory.
> >>>
> >>>-- Dirk
> >>>
> >>>Oliver Zeigermann wrote:
> >>>
> >>>
> Sorry for bothering, but I do not know where to turn to in this
> matter.
> 
> marven site
> 
> does not work for me because of a problem reported by the jelly
> plugin
> both with rc2 and rc3. Does it work for you?
> 
> Thanks in advance,
> 
> Oliver
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> -
> >>
> >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>For additional commands, e-mail: 
> [EMAIL PROTECTED]
> >>>
> >>
> >>
> >>
> -
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> > 
> > 
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RE : [transaction] website

2004-05-27 Thread Oliver Zeigermann 
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:/Dokumente und 
Einstellungen/olli.C1-FSE/.maven/plugins/maven-xdoc-plugin-1.4/
Element... j:include
Line.. 333
Column 54
null:-1:-1:  Could not parse Jelly script
Total time: 50 seconds
Finished at: Thu May 27 13:02:01 CEST 2004

Thanks for helping!
Oliver
Heritier Arnaud wrote:
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, 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 and rc3 have some problems.
If you downgrade, don't forget to delete the .maven/plugins 
directory 

in
your home directory.
-- Dirk
Oliver Zeigermann wrote:

Sorry for bothering, but I do not know where to turn to in this 
matter.

marven site
does not work for me because of a problem reported by the jelly 
plugin
both with rc2 and rc3. Does it work for you?

Thanks in advance,
Oliver



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE : [transaction] website

2004-05-27 Thread Heritier Arnaud 
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, 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 and rc3 have some problems.
> > 
> > If you downgrade, don't forget to delete the .maven/plugins 
> directory 
> > in
> > your home directory.
> > 
> > -- Dirk
> > 
> > Oliver Zeigermann wrote:
> > 
> >> Sorry for bothering, but I do not know where to turn to in this 
> >> matter.
> >>
> >> marven site
> >>
> >> does not work for me because of a problem reported by the jelly 
> >> plugin
> >> both with rc2 and rc3. Does it work for you?
> >>
> >> Thanks in advance,
> >>
> >> Oliver
> > 
> > 
> > 
> > 
> > 
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] website

2004-05-27 Thread Oliver Zeigermann 
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 package?

Oliver
Dirk Verbeeck wrote:
I'm still using rc1. It works for me and it seems the best release 
candidate, both rc2 and rc3 have some problems.

If you downgrade, don't forget to delete the .maven/plugins directory 
in your home directory.

-- Dirk
Oliver Zeigermann wrote:
Sorry for bothering, but I do not know where to turn to in this matter.
marven site
does not work for me because of a problem reported by the jelly 
plugin both with rc2 and rc3. Does it work for you?

Thanks in advance,
Oliver



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [transaction] website

2004-05-27 Thread Oliver Zeigermann 
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 and rc3 have some problems.

If you downgrade, don't forget to delete the .maven/plugins directory in 
your home directory.

-- Dirk
Oliver Zeigermann wrote:
Sorry for bothering, but I do not know where to turn to in this matter.
marven site
does not work for me because of a problem reported by the jelly plugin 
both with rc2 and rc3. Does it work for you?

Thanks in advance,
Oliver


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]