[SANDBOX-CLI] Multiple value support added
All, I have added support for multiple values to CLI. This is useful for specifying lists of values e.g. myUtil --include one two three -list *.java So the values for the include option are [one, two, three]. I will put this together into a patch later today and post the URL. CLI uses char as the id of an option. I think this limits developers too much. Lets use ant as an example. To specify a build file in ant the -buildfile option is required. This type of flag cannot be used in CLI. It can be either -b or --buildfile but not -buildfile. I would like to change the key from char to String. This could be made API compatible by delegating the current methods that use char to the new methods that will use String. Comments please, -John K -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/tools Enhancer.java
baliuka 02/04/29 04:50:24
Modified:simplestore/src/java/org/apache/commons/simplestore/tools
Enhancer.java
Log:
Fixed bug
Revision ChangesPath
1.21 +304 -291
jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/tools/Enhancer.java
Index: Enhancer.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/tools/Enhancer.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- Enhancer.java 14 Apr 2002 19:43:45 - 1.20
+++ Enhancer.java 29 Apr 2002 11:50:24 - 1.21
@@ -102,59 +102,60 @@
import org.apache.bcel.generic.Type;
import org.apache.bcel.generic.ArrayType;
/**
-* this code returns Enhanced Vector to intercept all methods for tracing
-* pre
-* java.util.Vector vector = (java.util.Vector)Enhancer.enhance(
-*java.util.Vector.class,
-*new Class[]{java.util.List.class},
-*
-*new MethodInterceptor(){
-*
-*public Object beforeInvoke( Object obj,java.lang.reflect.Method method,
-*Object args[] )
-*throws java.lang.Throwable{
-*return null;
-*}
-*
-*public boolean invokeSuper( Object obj,java.lang.reflect.Method method,
-*Object args[], Object retValFromBefore )
-*throws java.lang.Throwable{
-*return true;
-*}
-*
-*
-*public Object afterReturn( Object obj, java.lang.reflect.Method
method,
-*Object args[], Object retValFromBefore,
-*boolean invokedSuper, Object retValFromSuper,
-*java.lang.Throwable e )throws java.lang.Throwable{
-*System.out.println(method);
-*return retValFromSuper;//return the same as supper
-*}
-*
-*});
-* /pre
-*@author Juozas Baliuka a href=mailto:[EMAIL PROTECTED];
+ * this code returns Enhanced Vector to intercept all methods for tracing
+ * pre
+ * java.util.Vector vector = (java.util.Vector)Enhancer.enhance(
+ *java.util.Vector.class,
+ *new Class[]{java.util.List.class},
+ *
+ *new MethodInterceptor(){
+ *
+ *public Object beforeInvoke( Object obj,java.lang.reflect.Method
method,
+ *Object args[] )
+ *throws java.lang.Throwable{
+ *return null;
+ *}
+ *
+ *public boolean invokeSuper( Object obj,java.lang.reflect.Method
method,
+ *Object args[], Object retValFromBefore )
+ *throws java.lang.Throwable{
+ *return true;
+ *}
+ *
+ *
+ *public Object afterReturn( Object obj, java.lang.reflect.Method
method,
+ *Object args[], Object retValFromBefore,
+ *boolean invokedSuper, Object retValFromSuper,
+ *java.lang.Throwable e )throws java.lang.Throwable{
+ *System.out.println(method);
+ *return retValFromSuper;//return the same as supper
+ *}
+ *
+ *});
+ * /pre
+ *@author Juozas Baliuka a href=mailto:[EMAIL PROTECTED];
* [EMAIL PROTECTED]/a
- *@version$Id: Enhancer.java,v 1.20 2002/04/14 19:43:45 baliuka Exp $
+ *@version$Id: Enhancer.java,v 1.21 2002/04/29 11:50:24 baliuka Exp $
*/
-public class Enhancer implements org.apache.bcel.Constants , Constants{
+public class Enhancer implements org.apache.bcel.Constants ,
+Constants{
+
-
static final String INTERCEPTOR_CLASS = MethodInterceptor.class.getName();
static final ObjectType BOOLEAN_OBJECT =
-new ObjectType(Boolean.class.getName());
+new ObjectType(Boolean.class.getName());
static final ObjectType INTEGER_OBJECT =
-new ObjectType(Integer.class.getName());
+new ObjectType(Integer.class.getName());
static final ObjectType CHARACTER_OBJECT =
-new ObjectType(Character.class.getName());
+new ObjectType(Character.class.getName());
static final ObjectType BYTE_OBJECT = new ObjectType(Byte.class.getName());
static final ObjectType SHORT_OBJECT = new ObjectType(Short.class.getName());
static final ObjectType LONG_OBJECT = new ObjectType(Long.class.getName());
static final ObjectType DOUBLE_OBJECT = new ObjectType(Double.class.getName());
static final ObjectType FLOAT_OBJECT = new ObjectType(Float.class.getName());
static final ObjectType METHOD_OBJECT =
-new ObjectType(java.lang.reflect.Method.class.getName());
+new ObjectType(java.lang.reflect.Method.class.getName());
static final ObjectType NUMBER_OBJECT =
cvs commit: jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/tools Enhancer.java
baliuka 02/04/29 04:52:09
Modified:simplestore/src/java/org/apache/commons/simplestore/tools
Enhancer.java
Log:
Revision ChangesPath
1.22 +2 -2
jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/tools/Enhancer.java
Index: Enhancer.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/tools/Enhancer.java,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- Enhancer.java 29 Apr 2002 11:50:24 - 1.21
+++ Enhancer.java 29 Apr 2002 11:52:09 - 1.22
@@ -135,7 +135,7 @@
* /pre
*@author Juozas Baliuka a href=mailto:[EMAIL PROTECTED];
* [EMAIL PROTECTED]/a
- *@version$Id: Enhancer.java,v 1.21 2002/04/29 11:50:24 baliuka Exp $
+ *@version$Id: Enhancer.java,v 1.22 2002/04/29 11:52:09 baliuka Exp $
*/
public class Enhancer implements org.apache.bcel.Constants ,
Constants{
@@ -237,7 +237,7 @@
StringBuffer key = new StringBuffer(cls.getName() + ;);
if(interfaces != null){
for(int i = 0; i interfaces.length; i++ ){
-key.append(interfaces[i].getName());
+key.append(interfaces[i].getName() + ;);
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/persistence/impl PersistentProxy.java
baliuka 02/04/29 04:52:57
Modified:simplestore/src/java/org/apache/commons/simplestore/persistence/impl
PersistentProxy.java
Log:
Revision ChangesPath
1.28 +2 -2
jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/persistence/impl/PersistentProxy.java
Index: PersistentProxy.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/persistence/impl/PersistentProxy.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- PersistentProxy.java 20 Apr 2002 10:30:18 - 1.27
+++ PersistentProxy.java 29 Apr 2002 11:52:57 - 1.28
@@ -77,7 +77,7 @@
* [EMAIL PROTECTED]/a
*@author Gerhard Froehlich a href=mailto:[EMAIL PROTECTED];
* [EMAIL PROTECTED]/a
- *@version$Id: PersistentProxy.java,v 1.27 2002/04/20 10:30:18 baliuka Exp $
+ *@version$Id: PersistentProxy.java,v 1.28 2002/04/29 11:52:57 baliuka Exp $
*/
public class PersistentProxy
implements MetaObject, org.apache.commons.simplestore.tools.Constants ,
@@ -139,7 +139,7 @@
interfaces = new Class[]{ Persistent.class} ;
}
Persistent p = (Persistent)
-Enhancer.enhance( persistent,null,interfaces,handler,loader);
+Enhancer.enhance( persistent,interfaces,handler,loader);
handler.m_object = p;
if ( newCreated ) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/pool/xdocs index.xml
rwaldhoff02/04/29 05:11:30
Modified:pool/src/java/org/apache/commons/pool ObjectPool.java
pool/src/java/org/apache/commons/pool/impl
GenericObjectPool.java SoftReferenceObjectPool.java
StackObjectPool.java
pool/xdocs index.xml
Added: pool/src/java/org/apache/commons/pool BaseObjectPool.java
Log:
add BaseObjectPool
use it in the various impls
add some docs
Revision ChangesPath
1.5 +8 -7
jakarta-commons/pool/src/java/org/apache/commons/pool/ObjectPool.java
Index: ObjectPool.java
===
RCS file:
/home/cvs/jakarta-commons/pool/src/java/org/apache/commons/pool/ObjectPool.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ObjectPool.java 28 Apr 2002 21:52:43 - 1.4
+++ ObjectPool.java 29 Apr 2002 12:11:30 - 1.5
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-commons/pool/src/java/org/apache/commons/pool/ObjectPool.java,v 1.4
2002/04/28 21:52:43 rwaldhoff Exp $
- * $Revision: 1.4 $
- * $Date: 2002/04/28 21:52:43 $
+ * $Header:
/home/cvs/jakarta-commons/pool/src/java/org/apache/commons/pool/ObjectPool.java,v 1.5
2002/04/29 12:11:30 rwaldhoff Exp $
+ * $Revision: 1.5 $
+ * $Date: 2002/04/29 12:11:30 $
*
*
*
@@ -64,6 +64,9 @@
/**
* A pooling interface.
* p
+ * codeObjectPool/code defines a trivially simple pooling interface. The only
+ * required methods are {@link #borrowObject borrowObject} and {@link #returnObject
returnObject}.
+ * p
* Example of use:
* table border=1 cellspacing=0 cellpadding=3 align=center
bgcolor=#FFtrtdpre
* Object obj = font color=#CCnull/font;
@@ -79,13 +82,11 @@
* pool.returnObject(obj);
*}
* }/pre/td/tr/table
+ * See {@link org.apache.commons.pool.impl.BaseObjectPool BaseObjectPool} for a
simple base implementation.
*
* @author Rodney Waldhoff
- * @version $Revision: 1.4 $ $Date: 2002/04/28 21:52:43 $
+ * @version $Revision: 1.5 $ $Date: 2002/04/29 12:11:30 $
*
- * @see KeyedObjectPool
- * @see ObjectPoolFactory
- * @see PoolableObjectFactory
*/
public interface ObjectPool {
/**
1.1
jakarta-commons/pool/src/java/org/apache/commons/pool/BaseObjectPool.java
Index: BaseObjectPool.java
===
/*
* $Header:
/home/cvs/jakarta-commons/pool/src/java/org/apache/commons/pool/BaseObjectPool.java,v
1.1 2002/04/29 12:11:30 rwaldhoff Exp $
* $Revision: 1.1 $
* $Date: 2002/04/29 12:11:30 $
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999-2001 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Commons, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
cvs commit: jakarta-commons/pool/xdocs contributors.xml
rwaldhoff02/04/29 05:21:06 Modified:pool/xdocs contributors.xml Log: add John McNally to contributor list Revision ChangesPath 1.2 +2 -1 jakarta-commons/pool/xdocs/contributors.xml Index: contributors.xml === RCS file: /home/cvs/jakarta-commons/pool/xdocs/contributors.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- contributors.xml 15 Jan 2002 01:20:52 - 1.1 +++ contributors.xml 29 Apr 2002 12:21:05 - 1.2 @@ -4,7 +4,7 @@ titleContributors/title author email=[EMAIL PROTECTED]Commons Documentation Team/author author email=[EMAIL PROTECTED]Rodney Waldhoff/author - revision$Id: contributors.xml,v 1.1 2002/01/15 01:20:52 rwaldhoff Exp $/revision + revision$Id: contributors.xml,v 1.2 2002/04/29 12:21:05 rwaldhoff Exp $/revision /properties body @@ -18,6 +18,7 @@ liMorgan Delagrange/li liGeir Magnusson Jr./li liCraig R. McClanahan/li +liJohn McNally/li liRodney Waldhoff/li liDavid Weinrich/li /ul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/docs/pool contributors.html
rwaldhoff02/04/29 05:22:01 Modified:docs/pool contributors.html Log: add John McNally to contributor list Revision ChangesPath 1.2 +1 -0 jakarta-commons/docs/pool/contributors.html Index: contributors.html === RCS file: /home/cvs/jakarta-commons/docs/pool/contributors.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- contributors.html 23 Apr 2002 00:22:45 - 1.1 +++ contributors.html 29 Apr 2002 12:22:01 - 1.2 @@ -96,6 +96,7 @@ liMorgan Delagrange/li liGeir Magnusson Jr./li liCraig R. McClanahan/li +liJohn McNally/li liRodney Waldhoff/li liDavid Weinrich/li /ul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] - New FTP File Listing Mechanism
How about some unit tests exercising the parsing and interaction. A document for usage would also be nice. We can add it to the site docs maybe start some small how-to's or tutorials or something centered around the major portions of the api ( ftp, telnet, etc. ) = Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com -Original Message- From: Steve Cohen [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 28, 2002 11:02 PM To: Jakarta Commons Developers List Subject: Re: [PATCH] - New FTP File Listing Mechanism Jeff That's cool. I have no problem with such stylistic changes. My idea, because I can't think of a better one, is eventually to replace FTPClient with FTPClient2. (If you can think of better class and package names, I wouldn't quarrel with you!) I had an original implementation that had all the FTPClient2 listFiles methods in listFiles. I hadn't seen the guideline that files be kept to 2000 lines or less (which FTPClient is even now in violation of) but with all the new methods in FTPClient, it just felt too long and complicated to me. (Imagine FTPClient and FTPClient2 all in one class!) And yet I knew I couldn't break backward compatibility, so my approach was the lesser of evils as I saw it. After a period of experimentation, if the community sense is to deprecate the older methods, then that can and should be done. Do you think a document illustrating the usage of FTPClient2 would be helpful? Steve On Sunday 28 April 2002 10:21 pm, you wrote: I'll just apply what I have an we can clean up after. I did change the format of the code in the patch to match more closely the coding style posted on the site. No functional changes, just spacing, author/version fixes, and import statement cleansing. Is the idea to move forward and replace FTPClient with FTPClient2 or add in the functionality some other way? I suppose a nice way to deprecate the older listing methods and still have the new versions should be the next topic of discussion? Although we could just replace the listing stuff for the first release of this, I think maintaining the older interface would be the best for users. Then users of the orig netcomponents code would really just need to change package names. = Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com -Original Message- From: Steve Cohen [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 28, 2002 9:40 AM To: Brekke, Jeff Subject: Re: [PATCH] - New FTP File Listing Mechanism Say Jeff: I was looking back over my code and I see one thing that I meant to clean up and forgot about: FTPFileList.create() (FTPFileList.java, line 85) eats the IOException instead of throwing it, as it should (and as the analogous functionality in Daniel's code does). Worse, it System.out.println's the error. Would you rather I clean this now, or get it in as soon as the commit happens? I'd rather not send a whole new patch that's 99% the same as the other, but I will leave up to you the best way to handle it. Steve On Sunday 28 April 2002 07:33 am, Brekke, Jeff wrote: Thanks Steve. I've integrated your patch and looking at it now. I've recently placed the projects generate documentation here: http://jakarta.apache.org/commons/sandbox/net It include javadocs, metrics report, checkstyle report, etc. that maven generates. = Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com -Original Message- From: Steve Cohen [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 27, 2002 1:16 PM To: [EMAIL PROTECTED] Subject: [PATCH] - New FTP File Listing Mechanism The attached patch implements an alternative file listing mechanism. While designed to replace and enhance the original mechanism, complete backward compatibility is preserved. This patch was originally submitted in a slightly different form before the NetComponents project was moved to the Jakarta Sandbox in April 2002. I am also attaching the original comments that were submitted with that submission. They are all still valid. The only differences between the earlier patch and this one are these 1) my email address is different 2) the package names were changed to conform with the new commons location 3) licenses were
[GUMP] Build Failure - commons-latka
This email is autogenerated from the output from:
http://jakarta.apache.org/builds/gump/2002-04-29/commons-latka.html
Buildfile: build.xml
init:
[echo] latka 1.0-dev
jaxen-warn:
[echo] ***
[echo] WARNING: XPath validator not built
[echo] Property: ${jaxen.jar}
[echo] Current value: jaxen-full.jar
[echo] If you wish to build this validator, please fix the
[echo] above property in your build.properties file
[echo]***
[echo]
build-java:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/latka/target/classes
[javac] Compiling 63 source files to
/home/rubys/jakarta/jakarta-commons/latka/target/classes
[copy] Copying 5 files to /home/rubys/jakarta/jakarta-commons/latka/target/classes
build:
jar:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/latka/dist
[mkdir] Created dir: /tmp/buildtemp_200204290616
[copy] Copying 71 files to /tmp/buildtemp_200204290616
[jar] Building jar:
/home/rubys/jakarta/jakarta-commons/latka/dist/commons-latka-1.0-dev.jar
[delete] Deleting directory /tmp/buildtemp_200204290616
doc-top:
[copy] Copying 1 file to /home/rubys/jakarta/jakarta-commons/latka/target
doc-copy:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/latka/docs
[copy] Copying 1 file to /home/rubys/jakarta/jakarta-commons/latka/docs
check-javadoc:
doc-javadoc:
[mkdir] Created dir: /tmp/buildtemp_200204290616
[copy] Copying 65 files to /tmp/buildtemp_200204290616
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/latka/docs/api
[javadoc] Generating Javadoc
[javadoc] Javadoc execution
[javadoc] Loading source files for package org.apache.commons.latka...
[javadoc] Loading source files for package org.apache.commons.latka.event...
[javadoc] Loading source files for package org.apache.commons.latka.validators...
[javadoc] Loading source files for package org.apache.commons.latka.xml...
[javadoc] Loading source files for package org.apache.commons.latka.http...
[javadoc] Loading source files for package org.apache.commons.latka.junit...
[javadoc] Loading source files for package org.apache.commons.latka.util...
[javadoc] Loading source files for package org.apache.commons.latka.util.xml...
[javadoc] Constructing Javadoc information...
[javadoc] javadoc: warning - Import not found: org.jaxen.jdom.XPath - ignoring!
[javadoc] Building tree for all the packages and classes...
[javadoc] Building index for all the packages and classes...
[javadoc] Building index for all classes...
[javadoc] Generating
/home/rubys/jakarta/jakarta-commons/latka/docs/api/stylesheet.css...
[javadoc] 1 warning
[delete] Deleting directory /tmp/buildtemp_200204290616
doc-xslt:
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-commons/latka/target/generated-xdocs/stylesheets
[style] Transforming into
/home/rubys/jakarta/jakarta-commons/latka/target/generated-xdocs
[style] Processing
/home/rubys/jakarta/jakarta-commons/latka/src/docbook/developers-guide.xml to
/home/rubys/jakarta/jakarta-commons/latka/target/generated-xdocs/developers-guide.xml
[style] Loading stylesheet
/home/rubys/jakarta/jakarta-commons/latka/src/xsl/site/docbook2document.xsl
[style] http://www.oasis-open.org/docbook/xml/4.1.2/dbpoolx.mod:6286:22: Fatal
Error! The markup declarations contained or pointed to by the document type
declaration must be well-formed.
[style] Failed to process
/home/rubys/jakarta/jakarta-commons/latka/src/docbook/developers-guide.xml
BUILD FAILED
/home/rubys/jakarta/jakarta-commons/latka/build.xml:241: Fatal error during
transformation
Total time: 43 seconds
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SANDBOX-CLI] Multiple value support added
I think POSIX would argue that -buildfile is the '-b' option
with an argument of 'uildfile'. Or possibly equiv to
-b -u -i -l -d -f -i -l -e.
A dash preceeds a single-character switches (or a sequence of single
character switches), while 2 dashes preceed a 'word'-based switch.
I was intentionally staying POSIXy with CLI.
So, right now, -1 on the '-buildfile' type of option, unless
convinced otherwise.
Fair point. I forgot about that. Could we extend cli to
support functionality like this? We could have specific Options
implementations e.g. PosixOptions.
e.g.
interface PosixOptions
{
// required methods
}
class PosixOptionsImpl implements PosixOptions
{
// implement all of the methods on PosixOptions
// and have them delegate appropriately to
// Options or other classes were appropriate
// e.g. PosixParser, SimpleParser
}
interface CommandLineParser
{
public List parse( String[] args );
}
class PosixParser implements CommandLineParser
{
..
}
class SimpleParser implements CommandLineParser
{
..
}
I haven't gone through the whole scenario but they
are my initial thoughts on it.
-John K
-bob
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/jelly build.xml
jstrachan02/04/29 05:59:44
Modified:jellybuild.xml
Log:
Patched the build file so that its no longer dependent on jars included in jexl
Revision ChangesPath
1.15 +2 -2 jakarta-commons-sandbox/jelly/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/jelly/build.xml,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- build.xml 26 Apr 2002 12:20:11 - 1.14
+++ build.xml 29 Apr 2002 12:59:43 - 1.15
@@ -3,7 +3,7 @@
!--
Jelly component of the Jakarta Commons Subproject
-$Id: build.xml,v 1.14 2002/04/26 12:20:11 jstrachan Exp $
+$Id: build.xml,v 1.15 2002/04/29 12:59:43 jstrachan Exp $
--
@@ -52,7 +52,7 @@
property name=commons-digester.apivalue=${digester.home}/dist/docs/api/
property name=commons-digester.jar
value=${digester.home}/dist/commons-digester.jar/
property name=commons-jexl.jar
value=${jexl.home}/dist/commons-jexl.jar/
- property name=velocity-dep.jar
value=${jexl.home}/lib/velocity-dep-1.4-dev.jar/
+ property name=velocity-dep.jar
value=/java/velocity/velocity-dep-1.4-dev.jar/
!-- == Component Declarations --
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SANDBOX-CLI] Multiple value support added
On Mon, 29 Apr 2002, bob mcwhirter wrote: I think POSIX would argue that -buildfile is the '-b' option with an argument of 'uildfile'. Or possibly equiv to -b -u -i -l -d -f -i -l -e. I would agree, except that Sun seem happy to use the -buildfile style. Supporting both seems important to me. Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SANDBOX-CLI] Multiple value support added
I think POSIX would argue that -buildfile is the '-b' option with an argument of 'uildfile'. Or possibly equiv to -b -u -i -l -d -f -i -l -e. I would agree, except that Sun seem happy to use the -buildfile style. Supporting both seems important to me. That's a slipperly slope though. We're all angered when Microsoft embraces and extends a technology or standard. I think we should have a similar reaction when Sun, IBM or anyone else does it too. It'd be fine, if we follow John's suggestion of having different styles of parser, possibly even with the POSIX one as the default. You should have to go out of your way to do something non-standard (non-POSIX, in this case). -bob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SANDBOX-CLI] Multiple value support added
On Mon, 29 Apr 2002, bob mcwhirter wrote: I would agree, except that Sun seem happy to use the -buildfile style. Supporting both seems important to me. That's a slipperly slope though. We're all angered when Microsoft embraces and extends a technology or standard. I think we should have a similar reaction when Sun, IBM or anyone else does it too. Not so sure. I'd expect VB developers to follow the MS embrace and extend, so why should we Java plebs not follow Sun? :) It is irritating though yeah. It'd be fine, if we follow John's suggestion of having different styles of parser, possibly even with the POSIX one as the default. You should have to go out of your way to do something non-standard (non-POSIX, in this case). +1 If I can find some time I keep meaning to pour through CLI and push as much as I can from the one I use into it. In my continuing quest to dump my own code and replace it with Apache code. Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8620] New: - Closed Connection Exception on setAutoCommit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620 Closed Connection Exception on setAutoCommit Summary: Closed Connection Exception on setAutoCommit Product: Commons Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: Normal Priority: Other Component: Dbcp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] After roughly a half dozen successful uses, I throw a SQLException when doing a setAutoCommit(false) on a connection returned from DBCP. I have tested this with both Microsoft SQL Server 2000 using JSQLConnect and Oracle 8.1.7.0.0 using the Oracle provided thin drivers. My application makes heavy use of transactions, if that could be part of the problem. If I set both validations to be true, then it always rejects the connection on return to the pool, and everything works fine (except that I'm not reusing connections, of course). If I don't do validation, then I get this exception after a few successful connections: java.sql.SQLException: Closed Connection at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:180) at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:222) at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:285) at oracle.jdbc.driver.OracleConnection.setAutoCommit (OracleConnection.java:991) at org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(Unknown Source) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8620] - Closed Connection Exception on setAutoCommit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620 Closed Connection Exception on setAutoCommit --- Additional Comments From [EMAIL PROTECTED] 2002-04-29 14:08 --- Can you provide a more complete example? How have you set up the pool? Which DBCP impl are you using (PoolingDriver? PoolingDataSource? BasicDataSource?) How are you doing the validations? It's curious that all your connections fail when validated. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8620] - Closed Connection Exception on setAutoCommit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620 Closed Connection Exception on setAutoCommit --- Additional Comments From [EMAIL PROTECTED] 2002-04-29 14:16 --- This connection in particular is set up by Tomcat using the DBCP factory, but I can reproduce the problem by creating the pool myself. I do not know what kind of implementation Tomcat uses, but I tried with a GenericObjectPool with the default factory, then created a PoolableConnectionFactory using a DriverManagerConnectionFactory, and then created a DataSource using PoolingDataSource. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SANDBOX-CLI] Multiple value support added
I think POSIX would argue that -buildfile is the '-b' option with an argument of 'uildfile'. Or possibly equiv to -b -u -i -l -d -f -i -l -e. I would agree, except that Sun seem happy to use the -buildfile style. Supporting both seems important to me. That's a slipperly slope though. We're all angered when Microsoft embraces and extends a technology or standard. I think we should have a similar reaction when Sun, IBM or anyone else does it too. Agreed. It'd be fine, if we follow John's suggestion of having different styles of parser, possibly even with the POSIX one as the default. You should have to go out of your way to do something non-standard (non-POSIX, in this case). Cool. When I have the multiple value patch together I was thinking of having a bash at refactoring some of the parsing code anyway (its just a bit hard to follow at the moment, and even more so with the multiple value stuff going in). So I will have a go at drafting a design for this. I think the main thing here is to have it as simple as possible. The last thing we want is for users to wonder what the hell is going on, all I want to do is parse a command line?. An idea I have for testing is to add an ApplicationTest unit test that has testXXX methods, where XXX is an real world command line utility e.g. testJava, testJavac, testTar, testChmod, testUname, testCd, etc. Not only will we have some good test coverage we'll also have ready to wear demos :-) -John K -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8620] - Closed Connection Exception on setAutoCommit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620 Closed Connection Exception on setAutoCommit --- Additional Comments From [EMAIL PROTECTED] 2002-04-29 14:24 --- I think Tomcat's using BasicDataSource, so it looks like you can recreate this problem with more than one configuration. From your stack trace, it would seem that something's called setAutoCommit on DelegeatingConnection when the underlying connection is already closed. Perhaps we could add a test to see if the underlying connection is closed in setAutoCommit, but I'm not sure the exception in that case is incorrect. I'm guessing that for some reason the underlying Connection is already closed when it is returned to the pool. That would explain why the validations fail also. Can you provide a more complete example of what you are doing? A unit test would be ideal, but just a small example of how the pool and its connections are being used would suffice. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SANDBOX-CLI] Multiple value support added
If I can find some time I keep meaning to pour through CLI and push as much as I can from the one I use into it. In my continuing quest to dump my own code and replace it with Apache code. Exact same reason why I started doing this :-) -John K -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/pool/xdocs index.xml
rwaldhoff02/04/29 07:26:32 Modified:pool/xdocs index.xml Log: doc update Revision ChangesPath 1.4 +16 -2 jakarta-commons/pool/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons/pool/xdocs/index.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- index.xml 29 Apr 2002 12:11:30 - 1.3 +++ index.xml 29 Apr 2002 14:26:32 - 1.4 @@ -4,12 +4,26 @@ titleHome/title author email=[EMAIL PROTECTED]Commons Documentation Team/author author email=[EMAIL PROTECTED]Rodney Waldhoff/author - revision$Id: index.xml,v 1.3 2002/04/29 12:11:30 rwaldhoff Exp $/revision + revision$Id: index.xml,v 1.4 2002/04/29 14:26:32 rwaldhoff Exp $/revision /properties body section name=The Pool Component - pPool provides an Object-pooling API./p + p + Pool provides an Object-pooling API, with three major aspects: + ol + li +A generic object pool interface that clients and implementors can use to provide easily +interchangable pooling implementations. + /li + li +A toolkit for creating modular object pools. + /li + li +Several general purpose pool implementations. + /li + /ol + /p p See the a href=http://nagoya.apache.org/gump/javadoc/jakarta-commons/pool/dist/docs/api/index.html;javadoc/a for details. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/docs/pool index.html
rwaldhoff02/04/29 07:29:11 Modified:docs/pool index.html Log: doc update Revision ChangesPath 1.3 +15 -1 jakarta-commons/docs/pool/index.html Index: index.html === RCS file: /home/cvs/jakarta-commons/docs/pool/index.html,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- index.html29 Apr 2002 12:16:23 - 1.2 +++ index.html29 Apr 2002 14:29:11 - 1.3 @@ -88,7 +88,21 @@ /td/tr trtd blockquote -pPool provides an Object-pooling API./p +p + Pool provides an Object-pooling API, with three major aspects: + ol + li +A generic object pool interface that clients and implementors can use to provide easily +interchangable pooling implementations. + /li + li +A toolkit for creating modular object pools. + /li + li +Several general purpose pool implementations. + /li + /ol + /p p See the a href=http://nagoya.apache.org/gump/javadoc/jakarta-commons/pool/dist/docs/api/index.html;javadoc/a for details. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7618] - need a way to set time out when using HttpClient and HttpMultiClient
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7618. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7618 need a way to set time out when using HttpClient and HttpMultiClient [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Enhancement Status|NEW |RESOLVED Resolution||FIXED Version|Nightly Builds |2.0 Alpha 1 --- Additional Comments From [EMAIL PROTECTED] 2002-04-29 14:36 --- Fixed in nightly builds? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [pool] PROPOSAL: add collecting of statistics to pool implementations
-Original Message- From: otisg [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 27, 2002 4:05 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [pool] PROPOSAL: add collecting of statistics to pool implementations So after the recent discussion I think the conclusion would be as follows: - Look at Avalon/Excalibur pool implementation and the inspection code I plan to do this - Note any flaws, learn from mistakes made in that code And this also - Implement what you proposed below and try to make it better than Excalibur impl. Not sure I'm interested in trying to outdo the Excalibur impl. My main desire is to have this functionality in commons pool. If it is better than something else, fine. But that would not be a primary goal. I'd rather hear from the commons pool community as to whether my proposal is +1, and if not, what I can do to make it better from the community standpoint. Otis ___ Sign up for FREE iVillage newsletters http://s.ivillage.com/rd/16705 . From health and pregnancy to shopping and sex, iVillage has the scoop on what matters most to you. -Original Message- From: Steven Caswell Sent: 4/23/2002 8:26:39 PM To: [EMAIL PROTECTED] Subject: [pool] PROPOSAL: add collecting of statistics to pool implementations Proposal: add collecting of statistics to pool implementations Reasoning: I'd like to be able to get stats from a pooling implementation to see how well the various configuration parameters are set. For example, in the GenericObjectPool implementation, I'd like to know how many waits occurred, how many times the pool was extended, etc. Proposed design changes: - Create an interface called PoolStatistics that defines operations for obtaining the statistics values and associated labels. Actual values would be returned in an array of ints. Value labels would be returned in an array of Strings. This would allow each pool implementation class to define its own set of statistics and label them accordingly. - Create an interface called Measurable that would be implemented by a pool that supports reporting of statistics. This interface defines the operation that returns an instance of PoolStatistics. Defining a separate interface allows individual pool implementations to support or not support reporting statistics at the choosing of the implementor. I've attached source code for the new PoolStatistics and Measurable interfaces. I've also attached patches to the GenericObjectPool and GenericObjectPoolFactory implementation classes that provide a first cut implementation, and the TestGenericObjectPool test case. I've run the test cases on these changes and they pass. If this proposal is accepted in some form I'll be happy to add a first cut implementation to the other pool implementation classes. Steven Caswell [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [pool] PROPOSAL: add collecting of statistics to pool implementations
I'd rather hear from the commons pool community as to whether my proposal is +1, and if not, what I can do to make it better from the community standpoint. Can't speak for the community, but I'm +1 on the idea. I imagine a wrapper style implementation that allow one to collect stats on a arbitrary pool, right?
Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Waldhoff, Rodney wrote: I'd rather hear from the commons pool community as to whether my proposal is +1, and if not, what I can do to make it better from the community standpoint. Can't speak for the community, but I'm +1 on the idea. I imagine a wrapper style implementation that allow one to collect stats on a arbitrary pool, right? Why not just *use* Excalibur Instrumentation? It does not require using all of Avalon, it is light weight, and first rate. Leif did a great job of balancing performance and memory consumption. You don't have to use Excalibur pool impls, but the instrumentation code would help in debugging any arbitrary stat you want with graphs that you can view in real time. There's nothing like being able to attach the GUI client to an already *running* process, and then shutting down the client without shutting down the server code. Talk about easing remote administration This is an area where I think that duplication might be a wasteful activity. Sure, keep your pool implementation, but provide a version that uses Excalibur Instrumentation if the libs are included at compile time. There is *alot* that goes on behind the scenes, and to get to where Instrumentation is, is going to take a while. We started playing with the idea either early this year or late last year--but didn't have anything working until about a month or two ago. That is unless you *really* want to reinvent the wheel--which I cannot stop. However, as the JMeter team can tell you--memory leaks are a b*tch to track down in GUI apps. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
HTTP Clients Vs URL class
Would someone please explain to me what are the advantages of using HTTP Clients over the URL class in JDK 1.4? One think I know is HTTP Clients supports Cookie. What are other advantages? Thanks. Sam __ Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/ Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Logging] Why Jdk14Logger contructor sets log level to INFO ?
I don't understand why Jdk14Logger overwrites the JDK1.4 logging
configuration file settings.
Here is the Jdk14Logger constructor:
public Jdk14Logger(String name) {
logger = Logger.getLogger(name);
logger.setUseParentHandlers(true);
logger.setLevel(Level.INFO);
}
The java.util.logging.Logger should be configured with the config file
settings.
I think the two lines that sets properties should be removed.
I have an other problem with JDK1.4 logging. The name of the class that
issued the logging request is always
org.apache.commons.logging.impl.Jdk14Logger. Is it possible to work
around this problem ?
Christophe
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [collections] Would like to contribute my RangeIterator
Does it do anything more than list.sublist(left, right).iterator()? -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Oliver Fischer [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 27, 2002 3:27 PM To: commons-dev Subject: [collections] Would like to contribute my RangeIterator Hello, I wrote some time ago a RangeIterator, which allows you to set a right and left border criteria, so that only objects within this border are processed. Now I would like to contribute it to the collections package. Would it be accepted? Bye Oliver -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [collections] Would like to contribute my RangeIterator
Well, presumably it's an iterator wrapper, not a list operation, right Oliver? So it would be useful for interfaces that only provide access through iterators. It sounds a bit specialized to me, especially since it seems to assume that the iterations are returned in order. Could you provide a few use cases? - Morgan --- Tim Moore [EMAIL PROTECTED] wrote: Does it do anything more than list.sublist(left, right).iterator()? -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Oliver Fischer [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 27, 2002 3:27 PM To: commons-dev Subject: [collections] Would like to contribute my RangeIterator Hello, I wrote some time ago a RangeIterator, which allows you to set a right and left border criteria, so that only objects within this border are processed. Now I would like to contribute it to the collections package. Would it be accepted? Bye Oliver -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] = Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [pool] PROPOSAL: add collecting of statistics to pool implementations
On Mon, 29 Apr 2002, Waldhoff, Rodney wrote: Date: Mon, 29 Apr 2002 09:40:14 -0500 From: Waldhoff, Rodney [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Subject: RE: [pool] PROPOSAL: add collecting of statistics to pool impleme ntations I'd rather hear from the commons pool community as to whether my proposal is +1, and if not, what I can do to make it better from the community standpoint. Can't speak for the community, but I'm +1 on the idea. I imagine a wrapper style implementation that allow one to collect stats on a arbitrary pool, right? I'm also +1 on it, but would really like to get a 1.0 release of pool and dbcp out the door first. Does anyone see remaining issues that would be must fix for such a release? Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Logging] Why Jdk14Logger contructor sets log level to INFO ?
On Mon, 29 Apr 2002, Christophe Felix-Henry wrote:
Date: Mon, 29 Apr 2002 15:01:58 +0200
From: Christophe Felix-Henry [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Logging] Why Jdk14Logger contructor sets log level to INFO ?
I don't understand why Jdk14Logger overwrites the JDK1.4 logging
configuration file settings.
Here is the Jdk14Logger constructor:
public Jdk14Logger(String name) {
logger = Logger.getLogger(name);
logger.setUseParentHandlers(true);
logger.setLevel(Level.INFO);
}
The java.util.logging.Logger should be configured with the config file
settings.
I think the two lines that sets properties should be removed.
I think you're right ... the basic contract for commons-logging is to not
mess with the configuration of the underlying logging system.
I have an other problem with JDK1.4 logging. The name of the class that
issued the logging request is always
org.apache.commons.logging.impl.Jdk14Logger. Is it possible to work
around this problem ?
What problem does this cause you? If you use commons-logging to wrap JDK
1.4 logging (or any other logging implementation) the price you pay for
portability is the extra wrapper class.
If you really wanted to change it for some reason, you can always
implement your own LogFactory (using the provided APIs and factory
discovery mechanism) to return whatever you want.
Christophe
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [pool] PROPOSAL: add collecting of statistics to pool impleme ntations
Craig: I have no problem waiting until 1.0 is out before serious consideration is given to additional functionality, assuming a 1.0 release is in the near future. Rodney: My original proposal post had a proposed API and implementation. I can repost if necessary. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 10:28 AM To: Jakarta Commons Developers List Subject: RE: [pool] PROPOSAL: add collecting of statistics to pool impleme ntations On Mon, 29 Apr 2002, Waldhoff, Rodney wrote: Date: Mon, 29 Apr 2002 09:40:14 -0500 From: Waldhoff, Rodney [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Subject: RE: [pool] PROPOSAL: add collecting of statistics to pool impleme ntations I'd rather hear from the commons pool community as to whether my proposal is +1, and if not, what I can do to make it better from the community standpoint. Can't speak for the community, but I'm +1 on the idea. I imagine a wrapper style implementation that allow one to collect stats on a arbitrary pool, right? I'm also +1 on it, but would really like to get a 1.0 release of pool and dbcp out the door first. Does anyone see remaining issues that would be must fix for such a release? Craig -- To unsubscribe, e-mail: mailto:commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [collections] Would like to contribute my RangeIterator
Right, I guess an unstated motivation for my doubts were that for non-lists you're not really guaranteed an order for iteration. I guess that doesn't necessarily make a bounded iterator entirely useless, but I would tend to think that it would reduce its utility. And if you want to treat a non-list collection or map as if it were a list, there are ways to do that, too. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Morgan Delagrange [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 11:25 AM To: Jakarta Commons Developers List Subject: RE: [collections] Would like to contribute my RangeIterator Well, presumably it's an iterator wrapper, not a list operation, right Oliver? So it would be useful for interfaces that only provide access through iterators. It sounds a bit specialized to me, especially since it seems to assume that the iterations are returned in order. Could you provide a few use cases? - Morgan --- Tim Moore [EMAIL PROTECTED] wrote: Does it do anything more than list.sublist(left, right).iterator()? -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Oliver Fischer [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 27, 2002 3:27 PM To: commons-dev Subject: [collections] Would like to contribute my RangeIterator Hello, I wrote some time ago a RangeIterator, which allows you to set a right and left border criteria, so that only objects within this border are processed. Now I would like to contribute it to the collections package. Would it be accepted? Bye Oliver -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [collections] Would like to contribute my RangeIterator
--- Tim Moore [EMAIL PROTECTED] wrote: Right, I guess an unstated motivation for my doubts were that for non-lists you're not really guaranteed an order for iteration. It could also be useful for SortedSets, the keys of a SortedMap, and other Sorted collections, but your point is well-taken. I guess that doesn't necessarily make a bounded iterator entirely useless, but I would tend to think that it would reduce its utility. And if you want to treat a non-list collection or map as if it were a list, there are ways to do that, too. Yes, I'd like to hear some use cases from Oliver, or at least a humorous anecdote or two. :) If there are one or two common APIs that only return sorted iterations, that might be sufficient. Also, I'm wondering what the contract of this Iterator is. Do the left and right boundaries have to exist inside the iteration, or does your iterator assume a Sorted and Comparable iteration? If it does assume order, does it only support inclusive ranges? - Morgan -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Morgan Delagrange [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 11:25 AM To: Jakarta Commons Developers List Subject: RE: [collections] Would like to contribute my RangeIterator Well, presumably it's an iterator wrapper, not a list operation, right Oliver? So it would be useful for interfaces that only provide access through iterators. It sounds a bit specialized to me, especially since it seems to assume that the iterations are returned in order. Could you provide a few use cases? - Morgan --- Tim Moore [EMAIL PROTECTED] wrote: Does it do anything more than list.sublist(left, right).iterator()? -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Oliver Fischer [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 27, 2002 3:27 PM To: commons-dev Subject: [collections] Would like to contribute my RangeIterator Hello, I wrote some time ago a RangeIterator, which allows you to set a right and left border criteria, so that only objects within this border are processed. Now I would like to contribute it to the collections package. Would it be accepted? Bye Oliver -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] = Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Steven Caswell wrote: My problem is one of keeping the design clean. My view of Excalibur is that it sits in a domain higher than commons. I see Excalibur as being at an architcture level, and I see commons as being more at a foundation level. I hesitate to have a commons package reach up into a higher domain. I don't know if you can make that distinction as it is right now. Quite a few pieces of Excalibur are foundational (like the CLI impl, pooling, event architecture, instrumentation hooks, etc.). Some are quite architectural (like Fortress, ExcaliburComponentManager, Monitor, etc.) Having said that, I suspect there are packages in Excalibur that really ought to be at a foundation level, and there are packages in commons that ought to be at an architecture level. Perhaps pool should eventually be migrated to Excalibur. Perhaps better organization of Jakarta projects along domain lines would be appropriate. And perhaps I need to decide if a pooling package is really foundational (as I would label one in commons) or architectural (as I would label one in Excalibur) and have my application architecture based on the most appropriate domain. Perhaps the current reorg of Excalibur will make it easier for me to do this. I hope we get done soon :) However, for the present, I would like to make the pooler I'm better by adding statistics gathering. And for the present, the most expedient way I see to do that is the implementation I proposed. Oh well, I was trying to save you alot of work. The Instrumentation package is really great stuff IMNSHO--and its not too hard to use. -- They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. - Benjamin Franklin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8627] New: - Add 1/0 to BooleanConverter
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8627. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8627 Add 1/0 to BooleanConverter Summary: Add 1/0 to BooleanConverter Product: Commons Version: Nightly Builds Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Bean Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In XML Schema, 1/0 are valid true/false values for the boolean datatype. The usage is common in other programming languages as well. I'd like to suggest extending BooleanConverter to accept these as legal values for true and false. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Collections][SUBMIT] WeakHashSet
// Creates a Set backed by the given map. Given // map must be empty. public static Set createSet(Map map); public static SortedSet createSortedSet(SortedMap map); This kind of depends on how a Set is backed by a Map. (You'll have to forgive me for not knowing how this works.) For example, in a WeakHashMap, it is the keys that are held with weak references. If while backing the Set with this Map, the Set's values are stored in the Map's values and not its keys, then it may not work as expected. If it works as expected, I have no objection to this. The map-to-set wrapper would have to use the map's keys as the set's elements, as values in a map are not guaranteed to be unique. The WeakHashMap javadoc specifies that it uses weak keys, so it should work correctly with such a set wrapper. So maybe what I really need to do is write a weak reference Set wrapper, and encapsulate whatever Set the user passes. Basically, doing something similar to your Transformers and Predicates, that wrap underlying collections. Perhaps the natural extension is to go to Lists, etc. as you are discussing with Transformers and Predicates. As long as the public API is static wrapper methods for each of the implementations (as per the java.util.Collections.synchronized methods) I'm fine with this. Although it really does feel like we could provide some sort of Transformer- based approach that would enable weak elements but also other functionality... Like...Before I mentioned a two-transformer approach. If the read transformer (which would transform weak references back into their referents before returning the value from the collection) emptied the reference queue before returning results, the two-transformer approach would probably work. Which brings me to another thought - Ultimately, this weak reference Collection wrapper, Transformers and Predicates are all collection wrappers of one sort or another that encapsulate another collection that actually stores the objects (or another wrapper). Perhaps they should all subclass from the same class, or implement a common interface? There already exists a ProxyMap class for this purpose for Maps, and there's been talk of including ProxyList, ProxySet etc. My feeling is if you want to code them up, they'd be accepted. -Paul -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HTTP Clients Vs URL class
One think I know is HTTP Clients supports Cookie. What are other advantages? HTTP Client provides significantly more wire-level control over the HTTP transaction. If you just want to grab content from some URL, then the java.net.* package may suffice. If you're writing an HTTP client (like Slide, or Latka, or a SOAP client, etc.) and you begin to have an opinion about how the transactions are handled, what information gets sent, etc., you quickly run into the limitations of the java.net package.
RE: [pool] PROPOSAL: add collecting of statistics to pool implementations
On Mon, 29 Apr 2002, Steven Caswell wrote: Craig: I have no problem waiting until 1.0 is out before serious consideration is given to additional functionality, assuming a 1.0 release is in the near future. I'd like to do one in the next day or so, if there are no remaining gotcha bugs. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Commons Messenger - How to set 'Transacted' to true?
Tom Its also worth mentioning that there's a 'durable' mode that you can use to enable durable subscriptions. You can configure this via the durable property on a messenger element... messenger name=foo durable=true factory transacted=true .. James - Original Message - From: James Strachan [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, April 29, 2002 6:16 PM Subject: Re: Commons Messenger - How to set 'Transacted' to true? Hi Tom - Original Message - From: Tom Marsh [EMAIL PROTECTED] All: I'm trying to use messenger.rollback() when I have a problem, but JMS complains that I'm not transacted. I was trying to figure out how to set it in messenger.xml, but couldn't. (Using MqSeries JMS). I hard coded transaction to true in sessionfactory. I'm thinking I could set up for it in MessengerDigester, but I'm a little over my head.. You're right its all to do with getting the MessengerDigester to create the correctly configured JMS Connection / Sessions for you. One way to do it is to use whatever tools come with your J2EE app server or JMS implementation and create JNDI administered objects, then just look up your connection factories via JNDI messenger name=topic jndiDestinations=true jndi lookupName=TopicConnectionFactory topic=true ... There are various things relating to transactions and rollbacks here. JMS can operate in a 'transacted' mode. To enable transacted mode you just need to use a 'transacted' attribute in the factory element messenger name=foo factory transacted=true Or you could write your own SessionFactory class to create connections/sessions however you wish. For example it might well make sense to write an XASessionFactory to create XAConnection and XASessions. Then you could use it as follows... messenger name=foo factory className=org.apache.commons.messenger.XASessionFactory ... Then you could use your JMS provider in an XA (2 phase commit) manner. Probably working in 'transacted' mode might work for you; otherwise using your own factory might be better or trying the administered objects / JNDI route. James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8620] - Closed Connection Exception on setAutoCommit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620 Closed Connection Exception on setAutoCommit --- Additional Comments From [EMAIL PROTECTED] 2002-04-29 17:30 --- I am definitely calling close() on the connection to return it to the pool, I don't know how else to return it, since the connection is not pool-aware in any way. According to the JavaDocs on PoolableConnection, I believe this is what I'm supposed to do: A delegating connection that, rather than closing the underlying connection, returns itself to an ObjectPool when closed. Perhaps PoolableConnection should check to make sure the connection is not closed before returning? Of course, this still doesn't really answer the question of why is the connection closed, huh? Anyway, I've attached a hacked together test. Please excuse the sloppiness, I had to combine a half dozen classes to get it into one file. You'll need to provide a SQL command on line 47, and change the connection url on line 189. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/tools Enhancer.java
baliuka 02/04/29 11:01:59
Modified:simplestore build.xml
simplestore/src/java/org/apache/commons/simplestore/persistence/impl
DBStorage.java
simplestore/src/java/org/apache/commons/simplestore/tools
Enhancer.java
Log:
Revision ChangesPath
1.21 +2 -2 jakarta-commons-sandbox/simplestore/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/simplestore/build.xml,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- build.xml 20 Mar 2002 17:49:49 - 1.20
+++ build.xml 29 Apr 2002 18:01:59 - 1.21
@@ -2,7 +2,7 @@
!--
simplestore component of the Jakarta Commons Subproject
-$Id: build.xml,v 1.20 2002/03/20 17:49:49 baliuka Exp $
+$Id: build.xml,v 1.21 2002/04/29 18:01:59 baliuka Exp $
--
!-- == Executable Targets --
@@ -104,7 +104,7 @@
bottom=Copyright (c) 2001 - Apache Software Foundation/
/target
- target name=dist depends=compile,javadoc
+ target name=dist depends=compile
description=Create binary distribution
mkdir dir=${dist.home}/
copy file=../LICENSE
1.19 +2 -4
jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/persistence/impl/DBStorage.java
Index: DBStorage.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/persistence/impl/DBStorage.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- DBStorage.java20 Apr 2002 10:30:18 - 1.18
+++ DBStorage.java29 Apr 2002 18:01:59 - 1.19
@@ -85,17 +85,15 @@
/**
*@author Juozas Baliuka a href=mailto:[EMAIL PROTECTED];
* [EMAIL PROTECTED]/a
- *@version$Id: DBStorage.java,v 1.18 2002/04/20 10:30:18 baliuka Exp $
+ *@version$Id: DBStorage.java,v 1.19 2002/04/29 18:01:59 baliuka Exp $
*/
public class DBStorage extends AbstractStorage implements
org.apache.commons.simplestore.tools.Constants {
private final static String CONNECTION =
org.apache.commons.simplestore.jdbc.DBStorage.connection;
private final static String INTERNAL_OID = INTERNAL_OID;
-//TODO : must be in MetaClass
-private static Properties procedures = new Properties();
private ConnectionFactory ds;
private Context context;
-//private MetaClass rootMetaClass = new MetaClassImpl(this);
+
/**
* Creates new DBStorageManager
*
1.23 +7 -4
jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/tools/Enhancer.java
Index: Enhancer.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/simplestore/src/java/org/apache/commons/simplestore/tools/Enhancer.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- Enhancer.java 29 Apr 2002 11:52:09 - 1.22
+++ Enhancer.java 29 Apr 2002 18:01:59 - 1.23
@@ -135,7 +135,7 @@
* /pre
*@author Juozas Baliuka a href=mailto:[EMAIL PROTECTED];
* [EMAIL PROTECTED]/a
- *@version$Id: Enhancer.java,v 1.22 2002/04/29 11:52:09 baliuka Exp $
+ *@version$Id: Enhancer.java,v 1.23 2002/04/29 18:01:59 baliuka Exp $
*/
public class Enhancer implements org.apache.bcel.Constants ,
Constants{
@@ -195,10 +195,13 @@
throws Throwable {
enhanced.getClass().getField(FIELD_NAME).set(enhanced, ih);
}
-public static MethodInterceptor getMethodInterceptor(Object enhanced)
-throws Throwable {
+public static MethodInterceptor getMethodInterceptor(Object enhanced){
+ try{
return (MethodInterceptor) enhanced.getClass().getField(FIELD_NAME).get(
-enhanced);
+enhanced);
+ }catch(Exception e){
+throw new java.lang.IllegalStateException(e.getMessage());
+ }
}
public static void addConstructionHandler(ConstructionHandler ch) {
costructionHandlers.add(ch);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/docs/pool examples.html index.html downloads.html contributors.html
rwaldhoff02/04/29 11:02:32
Modified:docs/pool index.html downloads.html contributors.html
Added: docs/pool examples.html
Log:
adding examples doc
Revision ChangesPath
1.4 +26 -32jakarta-commons/docs/pool/index.html
Index: index.html
===
RCS file: /home/cvs/jakarta-commons/docs/pool/index.html,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- index.html29 Apr 2002 14:29:11 - 1.3
+++ index.html29 Apr 2002 18:02:31 - 1.4
@@ -18,7 +18,7 @@
-titleHTTP Client - Home/title
+titlePool - Home/title
/head
body bgcolor=#ff text=#00 link=#525D76
@@ -52,12 +52,14 @@
ul
lia
href=http://nagoya.apache.org/gump/javadoc/jakarta-commons/pool/dist/docs/api/index.html;API Documentation/a
/li
+lia href=./examples.htmlExamples/a
+/li
/ul
pstrongProject Files/strong/p
ul
lia href=./downloads.htmlDownloads/a
/li
-lia
href=http://cvs.apache.org/viewcvs/jakarta-commons/pool/;CVS/a
+lia
href=http://cvs.apache.org/viewcvs/jakarta-commons/pool/;Source/a
/li
lia
href=http://cvs.apache.org/viewcvs/~checkout~/jakarta-commons/pool/PROPOSAL.html?content-type=text/html;Original Proposal/a
/li
@@ -141,12 +143,10 @@
a
href=http://nagoya.apache.org/gump/javadoc/jakarta-commons/pool/dist/docs/api/org/apache/commons/pool/ObjectPool.html;codeObjectPool/code/a
defines a trivially simple pooling interface:
/p
-pre
-public interface ObjectPool {
-Object borrowObject();
-void returnObject(Object borrowed);
-}
- /pre
+prepublic interface ObjectPool {
+Object borrowObject();
+void returnObject(Object borrowed);
+}/pre
p
Some client classes won't integrate with iPool/i any more than this.
Clients written to this interface can use arbitrary
codeObjectPool/code
@@ -162,12 +162,10 @@
a
href=http://nagoya.apache.org/gump/javadoc/jakarta-commons/pool/dist/docs/api/org/apache/commons/pool/KeyedObjectPool.html;codeKeyedObjectPool/code/a
defines a similiar interface for pools composed of heterogenous
objects:
/p
-pre
-public interface KeyedObjectPool {
-Object borrowObject(Object key);
-void returnObject(Object key, Object borrowed);
-}
- /pre
+prepublic interface
KeyedObjectPool {
+Object borrowObject(Object key);
+void returnObject(Object key, Object borrowed);
+}/pre
/blockquote
/td/tr
trtdbr//td/tr
@@ -186,15 +184,13 @@
a
href=http://nagoya.apache.org/gump/javadoc/jakarta-commons/pool/dist/docs/api/org/apache/commons/pool/PoolableObjectFactory.html;codePoolableObjectFactory/code/a
supports this by providing a generic inteface for the lifecycle of a
pooled object:
/p
-pre
-public interface PoolableObjectFactory {
-Object makeObject();
-void activateObject(Object obj);
-void passivateObject(Object obj);
-boolean validateObject(Object obj);
-void destroyObject(Object obj);
-}
- /pre
+prepublic interface
PoolableObjectFactory {
+Object makeObject();
+void activateObject(Object obj);
+void passivateObject(Object obj);
+boolean validateObject(Object obj);
+void destroyObject(Object obj);
+}/pre
p
codeObjectPool/code implementations may be written to accept
arbitrary
codePoolableObjectFactory/codes.
@@ -210,15 +206,13 @@
a
href=http://nagoya.apache.org/gump/javadoc/jakarta-commons/pool/dist/docs/api/org/apache/commons/pool/KeyedPoolableObjectFactory.html;codeKeyedPoolableObjectFactory/code/a
defines a similiar interface for codeKeyedObjectPool/codes:
/p
-pre
-public interface KeyedPoolableObjectFactory {
-
DO NOT REPLY [Bug 8620] - Closed Connection Exception on setAutoCommit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620 Closed Connection Exception on setAutoCommit --- Additional Comments From [EMAIL PROTECTED] 2002-04-29 18:08 --- I am definitely calling close() on the connection to return it to the pool, I don't know how else to return it, That's what you should be doing (but it shouldn't in general be closing the underlying connection). Lemme take a look at your example, and I'll see what I can figure out. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/latka/src/resources org.apache.commons.latka.report.xsl
morgand 02/04/29 11:20:21
Modified:latka/src/distribution/conf report.dtd suite.ent
latka/src/java/org/apache/commons/latka
AbstractReporter.java XMLReporter.java
latka/src/java/org/apache/commons/latka/event
LatkaEventListener.java LatkaEventPublisher.java
latka/src/java/org/apache/commons/latka/junit
JUnitEventReporter.java JUnitTestAdapter.java
latka/src/java/org/apache/commons/latka/xml
SessionHandler.java SuiteHandler.java
latka/src/resources org.apache.commons.latka.report.xsl
Added: latka/src/java/org/apache/commons/latka/event
ReportMessageEvent.java
Log:
added reportMessage tag to suite and report DTDs
Revision ChangesPath
1.2 +4 -1 jakarta-commons/latka/src/distribution/conf/report.dtd
Index: report.dtd
===
RCS file: /home/cvs/jakarta-commons/latka/src/distribution/conf/report.dtd,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- report.dtd22 Apr 2002 15:48:34 - 1.1
+++ report.dtd29 Apr 2002 18:20:21 - 1.2
@@ -1,8 +1,11 @@
?xml encoding=UTF-8 ?
-!ELEMENT report (request+)
+!ELEMENT report ( (request | reportMessage)+ )
!ATTLIST report suiteSuccess (true|false) #REQUIRED
label CDATA#IMPLIED
+
+!ELEMENT reportMessage EMPTY
+!ATTLIST reportMessage message CDATA #REQUIRED
!ELEMENT request (requestSuccess | requestFailure |
requestSkipped | requestError)
1.3 +6 -2 jakarta-commons/latka/src/distribution/conf/suite.ent
Index: suite.ent
===
RCS file: /home/cvs/jakarta-commons/latka/src/distribution/conf/suite.ent,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- suite.ent 27 Apr 2002 17:47:39 - 1.2
+++ suite.ent 29 Apr 2002 18:20:21 - 1.3
@@ -7,14 +7,18 @@
!ENTITY % tests.ent SYSTEM tests.ent
%tests.ent;
-!ELEMENT suite ( (session | request)+ )
+!ELEMENT suite ( (session | request | reportMessage)+ )
!ATTLIST suite defaultHost CDATA #IMPLIED
defaultPort CDATA #IMPLIED
defaultProxyHostCDATA #IMPLIED
defaultProxyPortCDATA #IMPLIED
labelCDATA #IMPLIED
+
+!-- prints out a message to the log generated by the test --
+!ELEMENT reportMessage EMPTY
+!ATTLIST reportMessage message CDATA #REQUIRED
-!ELEMENT session (request+)
+!ELEMENT session ( (request | reportMessage)+)
!-- tests that use the same session_id share the same environment --
!ATTLIST session sessionId CDATA #IMPLIED
label CDATA #IMPLIED
1.18 +1 -5
jakarta-commons/latka/src/java/org/apache/commons/latka/AbstractReporter.java
Index: AbstractReporter.java
===
RCS file:
/home/cvs/jakarta-commons/latka/src/java/org/apache/commons/latka/AbstractReporter.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- AbstractReporter.java 11 Apr 2002 13:54:02 - 1.17
+++ AbstractReporter.java 29 Apr 2002 18:20:21 - 1.18
@@ -1,8 +1,4 @@
/*
- *
- *
- *
- *
*
*
* The Apache Software License, Version 1.1
@@ -80,7 +76,7 @@
*
* @author Rodney Waldhoff
* @author Morgan Delagrange
- * @version $Revision: 1.17 $
+ * @version $Revision: 1.18 $
*/
public abstract class AbstractReporter implements LatkaEventInfo {
1.18 +8 -5
jakarta-commons/latka/src/java/org/apache/commons/latka/XMLReporter.java
Index: XMLReporter.java
===
RCS file:
/home/cvs/jakarta-commons/latka/src/java/org/apache/commons/latka/XMLReporter.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- XMLReporter.java 11 Apr 2002 13:54:02 - 1.17
+++ XMLReporter.java 29 Apr 2002 18:20:21 - 1.18
@@ -1,8 +1,4 @@
/*
- *
- *
- *
- *
*
*
* The Apache Software License, Version 1.1
@@ -67,6 +63,7 @@
import java.io.StringWriter;
// latka imports
import org.apache.commons.latka.http.Request;
+import org.apache.commons.latka.event.ReportMessageEvent;
import org.apache.commons.latka.event.RequestErrorEvent;
import org.apache.commons.latka.event.RequestEvent;
import
DO NOT REPLY [Bug 8620] - Closed Connection Exception on setAutoCommit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620 Closed Connection Exception on setAutoCommit --- Additional Comments From [EMAIL PROTECTED] 2002-04-29 18:33 --- The problem appears to be that I was explicitly closing connections a second time. I'm not sure why this caused a problem, but by not doing it, things work better. :) Now I'm having another problem. When I do call close() on my connection, the PreparedStatements aren't being closed, unless I close them myself. Shouldn't close() close the statements as well? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8620] - Closed Connection Exception on setAutoCommit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620 Closed Connection Exception on setAutoCommit --- Additional Comments From [EMAIL PROTECTED] 2002-04-29 18:41 --- (Just saw your comment, but since I already wrote this I'll post it anyway) If I'm reading this correctly, you're closing your connection multiple times: Your main loop calls ConnectionManager.commit(), which will call connection.close() in its finally block (or in ConnectionManager.rollback(), or both). Your main loop also calls con.close(), which references the same connection. Both calls will attempt to return the Connection to the pool, leading the pool to have multiple references to the same Connection, which will probably cause unexpected results. You should probably either close the Connection directly of via ConnectionManager, but not both. I would expect similiar results if you were to use Oracle directly (replace your DriverManager.getConnection(jdbc:apache:commons:dbcp:example) call with jdbc:oracle:thin:scott/tiger@hostname:1521:mysid). This is a generally useful heurstic when working with DBCP, get it working using the underlying driver directly, and then add the pooling behaviour. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/latka/src/webapps/latka-webapp/webapp report.xsl
morgand 02/04/29 11:52:56 Modified:latka/src/webapps/latka-webapp/webapp report.xsl Log: webapp support for the reportMessage tag Revision ChangesPath 1.2 +5 -1 jakarta-commons/latka/src/webapps/latka-webapp/webapp/report.xsl Index: report.xsl === RCS file: /home/cvs/jakarta-commons/latka/src/webapps/latka-webapp/webapp/report.xsl,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- report.xsl22 Apr 2002 15:51:21 - 1.1 +++ report.xsl29 Apr 2002 18:52:55 - 1.2 @@ -9,7 +9,7 @@ /xsl:template xsl:template match=report - xsl:apply-templates select=//request[not(requestSuccess)]/ + xsl:apply-templates select=//request[not(requestSuccess)] | reportMessage/ pxsl:call-template name=summary//p /xsl:template @@ -30,6 +30,10 @@ xsl:value-of select=count(//request/requestSkipped)/ skipped.br/ xsl:value-of select=count(//request/requestError)/ errors. /p + /xsl:template + + xsl:template match=reportMessage + pfont color=green[message]/font xsl:value-of select=@message//p /xsl:template xsl:template match=request -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8620] - Closed Connection Exception on setAutoCommit
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8620 Closed Connection Exception on setAutoCommit [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-04-29 19:03 --- Now I'm having another problem. When I do call close() on my connection, the PreparedStatements aren't being closed, unless I close them myself. Shouldn't close() close the statements as well? I'm not exactly sure. The JDBC JavaDocs don't seem very specific on this point, and I don't find any mention of it in the JBDC 2.x specs. Here's the JDBC 3.0 specification, section 11.6.2: Closing a Pooled Statement An application closes a pooled statement exactly the same way it closes a nonpooled statement. Whether it is pooled or not, a statement that has been closed is no longer available for use by the application, and an attempt to reuse it will cause an exception to be thrown. The following methods can close a pooled statement: * Statement.close called by an application; if the statement is being pooled, closes the logical statement used by the application but does not close the physical statement being pooled * Connection.close called by an application * Nonpooled connection closes the physical connection and all statements created by that connection. This is necessary because the garbage collection mechanism is unable to detect when externally managed resources can be released. * Pooled connection closes the logical connection and the logical statements it returned but leaves open the underlying PooledConnection object and any associated pooled statements But that's not totally clear to me either. In your case, we're pooling connections but not statements. Should we close them in that case? I don't think we're really doing a full JDBC 3.0 connection pooling impl anyway. The best practice would probably be to close the statements on your own anyway. Certainly the current DBCP impl won't make an effort to close them for you (although the underlying driver implementations might on a real close). Someone with a better understanding of the spec than I will need to tell me if there's a bug there or not. If there's a bug, please submit submit it as a new Bugzilla entry. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/pool build.xml
craigmcc02/04/29 12:56:40
Modified:pool build.xml
Log:
Make it possible to run the xdoc target when you don't have
commons-collections.jar in your classpath or $ANT_HOME/lib directory.
Revision ChangesPath
1.8 +5 -2 jakarta-commons/pool/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/pool/build.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- build.xml 28 Apr 2002 21:48:08 - 1.7
+++ build.xml 29 Apr 2002 19:56:40 - 1.8
@@ -1,4 +1,4 @@
-!-- $Id: build.xml,v 1.7 2002/04/28 21:48:08 rwaldhoff Exp $ --
+!-- $Id: build.xml,v 1.8 2002/04/29 19:56:40 craigmcc Exp $ --
project name=commons-pool default=test basedir=.
!-- patternset describing files to be copied from the doc directory --
@@ -272,12 +272,15 @@
/
/target
- target name=xdoc depends=xdoc.fetch-stylesheet
+ target name=xdoc depends=init,xdoc.fetch-stylesheet
description=Generates HTML documentation from XML source
+ mkdir dir=${dist.home}/
+ mkdir dir=${dist.home}/docs/
taskdef name=anakia classname=org.apache.velocity.anakia.AnakiaTask
classpath location=${velocity.jar}/
classpath location=${jdom.jar}/
classpath location=${xerces.jar}/
+ classpath location=${commons-collections.jar}/
/taskdef
echo
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [pool] 1.0 release soon (was RE: [pool] PROPOSAL: add collecting of statistics to pool implementations)
If anyone is strongly bothered by ObjectPool.numIdle() and ObjectPool.numActive() versus the getXXX() style, now might be the right time to change it, although it may already be too late depending upon how broadly pool is being used. How about adding getXxx() versions, implement the old ones in terms of them, and deprecate the old ones? If we add getActiveCount()/getIdleCount() methods to the interface, it'll break any custom implementations of ObjectPool that are out there. (This is of course why I want to add the base impls, then it'll only break anyone who's implementing ObjectPool directly.) I'd lean toward doing this now rather than for a 2.0 release. I'm not even aware of anyone using a custom ObjectPool impl, but this'll surely find them.
RE: [pool] 1.0 release soon (was RE: [pool] PROPOSAL: add collecting of statistics to pool implementations)
Better now than later. -Original Message- From: Waldhoff, Rodney [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 3:05 PM To: 'Jakarta Commons Developers List' Subject: RE: [pool] 1.0 release soon (was RE: [pool] PROPOSAL: add collecting of statistics to pool implementations) If anyone is strongly bothered by ObjectPool.numIdle() and ObjectPool.numActive() versus the getXXX() style, now might be the right time to change it, although it may already be too late depending upon how broadly pool is being used. How about adding getXxx() versions, implement the old ones in terms of them, and deprecate the old ones? If we add getActiveCount()/getIdleCount() methods to the interface, it'll break any custom implementations of ObjectPool that are out there. (This is of course why I want to add the base impls, then it'll only break anyone who's implementing ObjectPool directly.) I'd lean toward doing this now rather than for a 2.0 release. I'm not even aware of anyone using a custom ObjectPool impl, but this'll surely find them. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] TreeNode, TreeIterator, IdentityHashSet proposed collections
From: Kief Morris [EMAIL PROTECTED] Stephen Colebourne typed the following on 12:17 AM 4/7/2002 +0100 I have tweaked our two sets of interfaces tonight to produce a combination that starts to hang together. I don't think I lost any functionality, but they are only the interfaces at the moment. See what you think at Stephen, my personal situation right now is keeping me from getting into this. Why don't you go ahead with submitting TreeNode and related stuff, and when I get some more time (probably a few months) I'll dig back into this. Sorry to lame out on you. Kief OK. I will proceed with implementing the interfaces previously posted. I will then post the full Tree implementation for wider commons review. Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections][SUBMIT] WeakHashSet
From: Jack, Paul [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Although it really does feel like we could provide some sort of Transformer- based approach that would enable weak elements but also other functionality... Like...Before I mentioned a two-transformer approach. If the read transformer (which would transform weak references back into their referents before returning the value from the collection) emptied the reference queue before returning results, the two-transformer approach would probably work. I'm not sure a two transformer approach is all thats needed. Collections have three basic types of method: - input (add/set) - query (indexOf, contains, equals, remove) - output (get, toArray) The Predicate/Transform proposal covers only the input group at the moment. A 'two transformer' approach would cover the output group of methods (but would require another 7 classes to do it). This is perfectly possible, but naming would be interesting :-) Which brings me to another thought - Ultimately, this weak reference Collection wrapper, Transformers and Predicates are all collection wrappers of one sort or another that encapsulate another collection that actually stores the objects (or another wrapper). Perhaps they should all subclass from the same class, or implement a common interface? There already exists a ProxyMap class for this purpose for Maps, and there's been talk of including ProxyList, ProxySet etc. My feeling is if you want to code them up, they'd be accepted. I have looked at the ProxyMap. It is suitable for use by the Predicate and Transform classes as it provides protected access to the map, but no public method to access it. Thus ProxyList and ProxySet would also be useful. However, that would still only cover 3 of the 7 collections! At the moment I'm pausing on the implementation of the predicate/transform classes until things clear. Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/src/java/org/apache/commons/beanutils package.html
craigmcc02/04/29 14:37:47
Modified:beanutils build.xml
beanutils/src/java/org/apache/commons/beanutils package.html
Added: beanutils/src/java overview.html
Log:
Include an overview file in the Javadocs since there is now more than
one Java package.
Revision ChangesPath
1.31 +3 -2 jakarta-commons/beanutils/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/beanutils/build.xml,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -r1.30 -r1.31
--- build.xml 18 Mar 2002 16:32:42 - 1.30
+++ build.xml 29 Apr 2002 21:37:46 - 1.31
@@ -3,7 +3,7 @@
!--
Bean Utilities component of the Jakarta Commons Subproject
-$Id: build.xml,v 1.30 2002/03/18 16:32:42 craigmcc Exp $
+$Id: build.xml,v 1.31 2002/04/29 21:37:46 craigmcc Exp $
--
@@ -205,7 +205,8 @@
author=true
private=true
version=true
- doctitle=lt;h1gt;${component.title}lt;/h1gt;
+ overview=src/java/overview.html
+ doctitle=lt;h1gt;${component.title} (Version
${component.version})lt;/h1gt;
windowtitle=${component.title} (Version ${component.version})
bottom=Copyright (c) 2001-2002 - Apache Software Foundation
classpath refid=compile.classpath/
1.1 jakarta-commons/beanutils/src/java/overview.html
Index: overview.html
===
html
head
titleOverview Documentation for COMMONS-BEANUTILS/title
/head
body bgcolor=white
pThe emBean Introspection Utilities/em component of the Jakarta Commons
subproject offers low-level utility classes that assist in getting and setting
property values on Java classes that follow the naming design patterns outlined
in the JavaBeans Specification, as well as mechanisms for dynamically defining
and accessing bean properties./p
pSee the
a href=org/apache/commons/beanutils/package-summary.html#package_description
Package Description/a for the codeorg.apache.commons.beanutils/code
package for more information./p
/body
/html
1.7 +5 -4
jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/package.html
Index: package.html
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/package.html,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- package.html 28 Apr 2002 01:16:48 - 1.6
+++ package.html 29 Apr 2002 21:37:47 - 1.7
@@ -3,10 +3,11 @@
titlePackage Documentation for org.apache.commons.beanutils Package/title
/head
body bgcolor=white
-pThe emBean Utilties/em component of the Jakarta Commons subproject
-offers low-level utility classes that assist in getting and setting property
-values on Java classes that follow the naming design patterns outlined in the
-JavaBeans Specification./p
+pThe emBean Introspection Utilities/em component of the Jakarta Commons
+subproject offers low-level utility classes that assist in getting and setting
+property values on Java classes that follow the naming design patterns outlined
+in the JavaBeans Specification, as well as mechanisms for dynamically defining
+and accessing bean properties./p
h1Table of Contents/h1
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/digester/src/java/org/apache/commons/digester/xmlrules package.html
craigmcc02/04/29 14:46:27
Modified:digester build.xml
digester/src/java/org/apache/commons/digester/xmlrules
package.html
Added: digester/src/java overview.html
digester/src/java/org/apache/commons/digester/rss
package.html
Log:
Add an overview file and tweak the package documentation.
Revision ChangesPath
1.23 +3 -2 jakarta-commons/digester/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons/digester/build.xml,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- build.xml 11 Mar 2002 21:31:15 - 1.22
+++ build.xml 29 Apr 2002 21:46:27 - 1.23
@@ -3,7 +3,7 @@
!--
Digester component of the Jakarta Commons Subproject
-$Id: build.xml,v 1.22 2002/03/11 21:31:15 craigmcc Exp $
+$Id: build.xml,v 1.23 2002/04/29 21:46:27 craigmcc Exp $
--
@@ -210,7 +210,8 @@
author=true
private=true
version=true
- doctitle=lt;h1gt;${component.title}lt;/h1gt;
+ overview=src/java/overview.html
+ doctitle=lt;h1gt;${component.title} (Version
${component.version})lt;/h1gt;
windowtitle=${component.title} (Version ${component.version})
bottom=Copyright (c) 2001-2002 - Apache Software Foundation
link offline=true packagelistLoc=${commons-beanutils.api}
1.1 jakarta-commons/digester/src/java/overview.html
Index: overview.html
===
html
head
titleOverview Documentation for COMMONS-DIGESTER/title
/head
body bgcolor=white
The emDigester/em component of the Jakarta Commons subproject supports
rules-based processing of arbitrary XML documents./p
pSee the
a href=org/apache/commons/digester/package-summary.html#package_description
Package Description/a for the codeorg.apache.commons.digester/code
package for more information./p
/body
/html
1.1
jakarta-commons/digester/src/java/org/apache/commons/digester/rss/package.html
Index: package.html
===
html
head
titlePackage Documentation for org.apache.commons.digester.rss Package/title
/head
body bgcolor=white
pExample usage of Digester to parse XML documents compatible with the
emRich Site Summary/em format used by many newsfeeds./p
/body
/html
1.2 +1 -1
jakarta-commons/digester/src/java/org/apache/commons/digester/xmlrules/package.html
Index: package.html
===
RCS file:
/home/cvs/jakarta-commons/digester/src/java/org/apache/commons/digester/xmlrules/package.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- package.html 4 Dec 2001 19:50:32 - 1.1
+++ package.html 29 Apr 2002 21:46:27 - 1.2
@@ -4,11 +4,11 @@
/head
body bgcolor=white
-a name=doc.Description/a
pThe codexmlrules/code package provides for XML-based definition of
rules for codeDigester/code. This improves maintainability of Java code,
as rules are now defined in XML and read into codeDigester/code at run-time.
/p
+a name=doc.Description/a
br /
br /
div align=center
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Collections][SUBMIT] WeakHashSet
I'm not sure a two transformer approach is all thats needed. Collections
have three basic types of method:
- input (add/set)
- query (indexOf, contains, equals, remove)
- output (get, toArray)
The Predicate/Transform proposal covers only the input group at the
moment.
A 'two transformer' approach would cover the output group of methods (but
would require another 7 classes to do it). This is perfectly possible, but
naming would be interesting :-)
Well, we could eliminate the need for 1-transformer implementations by
providing an identity transform, that doesn't actually alter the object.
And it seems that the query group of functions would just use the
input transform...here's what the code looks like in my head:
public boolean contains(Object value) {
value = inputTransformer.transform(value);
return wrapped.contains(value);
}
public Object get(int index) {
Object result = wrapped.get(index);
return outputTransformer.transform(result);
}
public Object set(int index, Object value) {
value = inputTransformer.transform(value);
Object result = wrapped.set(index, value);
return outputTransformer.transform(result);
}
I have looked at the ProxyMap. It is suitable for use by the Predicate and
Transform classes as it provides protected access to the map, but no
public
method to access it. Thus ProxyList and ProxySet would also be useful.
However, that would still only cover 3 of the 7 collections!
It's true, we'd be adding six public classes to the API...
At the moment I'm pausing on the implementation of the predicate/transform
classes until things clear.
Well the Predicate implementations, at any rate, appear uncontroversial, and
would be extremely useful.
-Paul
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils build.xml
craigmcc02/04/29 15:06:22 Modified:beanutils build.xml Log: Update version number for release. Revision ChangesPath 1.32 +2 -2 jakarta-commons/beanutils/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-commons/beanutils/build.xml,v retrieving revision 1.31 retrieving revision 1.32 diff -u -r1.31 -r1.32 --- build.xml 29 Apr 2002 21:37:46 - 1.31 +++ build.xml 29 Apr 2002 22:06:22 - 1.32 @@ -3,7 +3,7 @@ !-- Bean Utilities component of the Jakarta Commons Subproject -$Id: build.xml,v 1.31 2002/04/29 21:37:46 craigmcc Exp $ +$Id: build.xml,v 1.32 2002/04/29 22:06:22 craigmcc Exp $ -- @@ -55,7 +55,7 @@ property name=component.title value=Bean Introspection Utilities/ !-- The current version number of this component -- - property name=component.version value=1.3-dev/ + property name=component.version value=1.3/ !-- The base directory for compilation targets -- property name=build.home value=target/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections][SUBMIT] WeakHashSet
From: Jack, Paul [EMAIL PROTECTED]
I'm not sure a two transformer approach is all thats needed. Collections
have three basic types of method:
- input (add/set)
- query (indexOf, contains, equals, remove)
- output (get, toArray)
The Predicate/Transform proposal covers only the input group at the
moment.
A 'two transformer' approach would cover the output group of methods
(but
would require another 7 classes to do it). This is perfectly possible,
but
naming would be interesting :-)
Well, we could eliminate the need for 1-transformer implementations by
providing an identity transform, that doesn't actually alter the object.
A cunning plan...
And it seems that the query group of functions would just use the
input transform...here's what the code looks like in my head:
public boolean contains(Object value) {
value = inputTransformer.transform(value);
return wrapped.contains(value);
}
public Object get(int index) {
Object result = wrapped.get(index);
return outputTransformer.transform(result);
}
public Object set(int index, Object value) {
value = inputTransformer.transform(value);
Object result = wrapped.set(index, value);
return outputTransformer.transform(result);
}
The input and output I'm happy with. Its the queries I wasn't so sure about.
I guess that they are a kind of input... And in the String interning example
that was suggested the queries would need to be transformed. Hmm, I'm
talking myself into this ;-)
I have looked at the ProxyMap. It is suitable for use by the Predicate
and
Transform classes as it provides protected access to the map, but no
public
method to access it. Thus ProxyList and ProxySet would also be useful.
However, that would still only cover 3 of the 7 collections!
It's true, we'd be adding six public classes to the API...
At the moment I'm pausing on the implementation of the
predicate/transform
classes until things clear.
Well the Predicate implementations, at any rate, appear uncontroversial,
and
would be extremely useful.
Great, I'll try to manage these sometime in this week (without the Proxy*
classes).
Stephen
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils build.xml
craigmcc02/04/29 15:17:51 Modified:beanutils build.xml Log: Set version number back to development. Revision ChangesPath 1.33 +2 -2 jakarta-commons/beanutils/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-commons/beanutils/build.xml,v retrieving revision 1.32 retrieving revision 1.33 diff -u -r1.32 -r1.33 --- build.xml 29 Apr 2002 22:06:22 - 1.32 +++ build.xml 29 Apr 2002 22:17:51 - 1.33 @@ -3,7 +3,7 @@ !-- Bean Utilities component of the Jakarta Commons Subproject -$Id: build.xml,v 1.32 2002/04/29 22:06:22 craigmcc Exp $ +$Id: build.xml,v 1.33 2002/04/29 22:17:51 craigmcc Exp $ -- @@ -55,7 +55,7 @@ property name=component.title value=Bean Introspection Utilities/ !-- The current version number of this component -- - property name=component.version value=1.3/ + property name=component.version value=1.4-dev/ !-- The base directory for compilation targets -- property name=build.home value=target/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/digester build.xml
craigmcc02/04/29 15:18:48 Modified:digester build.xml Log: Update version number for release. Revision ChangesPath 1.25 +2 -2 jakarta-commons/digester/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-commons/digester/build.xml,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- build.xml 29 Apr 2002 22:03:51 - 1.24 +++ build.xml 29 Apr 2002 22:18:48 - 1.25 @@ -3,7 +3,7 @@ !-- Digester component of the Jakarta Commons Subproject -$Id: build.xml,v 1.24 2002/04/29 22:03:51 craigmcc Exp $ +$Id: build.xml,v 1.25 2002/04/29 22:18:48 craigmcc Exp $ -- @@ -55,7 +55,7 @@ property name=component.title value=Digester - XML to Java Object Configuration/ !-- The current version number of this component -- - property name=component.version value=1.2-dev/ + property name=component.version value=1.2/ !-- The base directory for compilation targets -- property name=build.home value=target/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/xdocs beanutils.xml components.xml digester.xml
craigmcc02/04/29 15:34:11 Modified:docs beanutils.html components.html digester.html xdocsbeanutils.xml components.xml digester.xml Log: Update web site stuff for new BeanUtils and Digester versions. Revision ChangesPath 1.32 +1 -0 jakarta-commons/docs/beanutils.html Index: beanutils.html === RCS file: /home/cvs/jakarta-commons/docs/beanutils.html,v retrieving revision 1.31 retrieving revision 1.32 diff -u -r1.31 -r1.32 --- beanutils.html23 Apr 2002 16:37:16 - 1.31 +++ beanutils.html29 Apr 2002 22:34:11 - 1.32 @@ -196,6 +196,7 @@ lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils/v1.0/;Version 1.0/a/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils/v1.1/;Version 1.1/a/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils/v1.2/;Version 1.2/a/li +lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils/v1.3/;Version 1.3/a/li /ul /blockquote /p 1.29 +2 -0 jakarta-commons/docs/components.html Index: components.html === RCS file: /home/cvs/jakarta-commons/docs/components.html,v retrieving revision 1.28 retrieving revision 1.29 diff -u -r1.28 -r1.29 --- components.html 29 Apr 2002 02:10:37 - 1.28 +++ components.html 29 Apr 2002 22:34:11 - 1.29 @@ -162,6 +162,7 @@ br / Releases: ul + lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils/v1.3/;Release 1.3/a - 29 Apr 2002/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils/v1.2/;Release 1.2/a - 24 Dec 2001/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils/v1.1/;Release 1.1/a - 22 Sep 2001/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils/v1.0/;Release 1.0/a - 14 July 2001/li @@ -204,6 +205,7 @@ br / Releases: ul + lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.1.2/;Release 1.2/a - 29 Apr 2002/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.1.1/;Release 1.1.1/a - 16 Oct 2001/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.1/;Release 1.1/a - 22 Sep 2001/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.0/;Release 1.0/a - 14 July 2001/li 1.18 +5 -1 jakarta-commons/docs/digester.html Index: digester.html === RCS file: /home/cvs/jakarta-commons/docs/digester.html,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- digester.html 23 Apr 2002 16:37:16 - 1.17 +++ digester.html 29 Apr 2002 22:34:11 - 1.18 @@ -165,7 +165,10 @@ /td/tr trtd blockquote -pThe a href=http://jakarta.apache.org/commons/digester/commons-digester-1.1.1/docs/api/index.html; +pThe a href=http://jakarta.apache.org/commons/digester/RELEASE-NOTES.txt; +Release Notes/a document the new features and bug fixes that have been +included in this release./p +pThe a href=http://jakarta.apache.org/commons/digester/api/index.html; JavaDoc API documents/a are available online. In particular, you should read the package description for the codeorg.apache.commons.digester/code package for detailed information on using the package./p @@ -185,6 +188,7 @@ ul lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.0/;Version 1.0/a/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.1.1/;Version 1.1.1/a/li +lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.2/;Version 1.2/a/li /ul /blockquote /p 1.8 +1 -0 jakarta-commons/xdocs/beanutils.xml Index: beanutils.xml === RCS file: /home/cvs/jakarta-commons/xdocs/beanutils.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- beanutils.xml 24 Dec 2001 21:58:39 - 1.7 +++ beanutils.xml 29 Apr 2002 22:34:11 - 1.8 @@ -62,6 +62,7 @@ lia
cvs commit: jakarta-commons/xdocs components.xml
craigmcc02/04/29 15:35:31 Modified:docs components.html xdocscomponents.xml Log: Let's get the link right this time. Revision ChangesPath 1.30 +1 -1 jakarta-commons/docs/components.html Index: components.html === RCS file: /home/cvs/jakarta-commons/docs/components.html,v retrieving revision 1.29 retrieving revision 1.30 diff -u -r1.29 -r1.30 --- components.html 29 Apr 2002 22:34:11 - 1.29 +++ components.html 29 Apr 2002 22:35:31 - 1.30 @@ -205,7 +205,7 @@ br / Releases: ul - lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.1.2/;Release 1.2/a - 29 Apr 2002/li + lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.2/;Release 1.2/a - 29 Apr 2002/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.1.1/;Release 1.1.1/a - 16 Oct 2001/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.1/;Release 1.1/a - 22 Sep 2001/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.0/;Release 1.0/a - 14 July 2001/li 1.26 +1 -1 jakarta-commons/xdocs/components.xml Index: components.xml === RCS file: /home/cvs/jakarta-commons/xdocs/components.xml,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- components.xml29 Apr 2002 22:34:11 - 1.25 +++ components.xml29 Apr 2002 22:35:31 - 1.26 @@ -71,7 +71,7 @@ br/ Releases: ul - lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.1.2/;Release 1.2/a - 29 Apr 2002/li + lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.2/;Release 1.2/a - 29 Apr 2002/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.1.1/;Release 1.1.1/a - 16 Oct 2001/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.1/;Release 1.1/a - 22 Sep 2001/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester/v1.0/;Release 1.0/a - 14 July 2001/li -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[ANNOUNCEMENT] JXPath 1.0 Beta 1 released
JXPath 1.0 Beta 1 has been released. JXPath is a component of Jakarta Commons. JXPath is an interpreter of the XPath expression language. JXPath applies XPath expressions to graphs of objects of all kinds: JavaBeans, Collections, arrays, Maps, Servlet contexts, DOM etc, including mixtures thereof. It is highly extensible, allowing the developer to customize support for existing object models and introduce support for new ones. Home page: http://jakarta.apache.org/commons/jxpath Downloads (source and binaries): http://jakarta.apache.org/builds/jakarta-commons/release/commons-jxpath/v1.0 Dmitri Plotnikov [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Release Vote for BeanUtils 1.3 and Digester 1.2
On Mon, Apr 29, 2002 at 09:39:03AM -0700, Craig R. McClanahan wrote: Vote on releasing COMMONS-BEANUTILS Version 1.3 [ ] +1 I am in favor of this release and will help [X] +0 I am in favor of this release but cannot help [ ] -0 I am not in favor of this release [ ] -1 I am opposed to this release, and here is why: Vote on releasing COMMONS-DIGESTER Version 1.2 [ ] +1 I am in favor of this release and will help [X] +0 I am in favor of this release but cannot help [ ] -0 I am not in favor of this release [ ] -1 I am opposed to this release, and here is why: --Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/xo project.xml
jon 02/04/29 17:27:05 Modified:xo project.xml Log: fixed deps so that the thing actually compiles. do people test this stuff? -jon Revision ChangesPath 1.2 +3 -3 jakarta-commons-sandbox/xo/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/xo/project.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- project.xml 16 Apr 2002 19:07:55 - 1.1 +++ project.xml 30 Apr 2002 00:27:04 - 1.2 @@ -51,8 +51,8 @@ dependency namecommons-digester/name typerequired/type - version1.0/version - jarcommons-digester.jar/jar + version1.2/version + jarcommons-digester-1.2.jar/jar /dependency dependency @@ -80,7 +80,7 @@ namecommons-logging/name typerequired/type version1.0/version - jarcommons-logging.jar/jar + jarcommons-logging-1.0.jar/jar /dependency dependency -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/configuration project.xml
jon 02/04/29 19:15:28 Modified:configuration project.xml Log: need to point at the right commons-logging.jar -jon Revision ChangesPath 1.2 +1 -1 jakarta-commons-sandbox/configuration/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/configuration/project.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- project.xml 16 Apr 2002 19:05:23 - 1.1 +++ project.xml 30 Apr 2002 02:15:28 - 1.2 @@ -79,7 +79,7 @@ namecommons-logging/name typerequired/type version1.0/version - jarcommons-logging.jar/jar + jarcommons-logging-1.0.jar/jar /dependency /dependencies -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bad dependency?
What the heck? I thought that these packages were not supposed to have dependencies on other projects?? On top of it, the build.properties.sample wasn't updated to reflect the need for this dependency. -jon compile: [javac] Compiling 12 source files to /Users/jon/checkout/jakarta-commons-sandbox/util/target/classes [javac] [javac] Found 6 semantic errors compiling /Users/jon/checkout/jakarta-commons-sandbox/util/src/java/org/apache/common s/util/XmlUtils.java: [javac] [javac] 57. import org.apache.commons.lang.Strings; [javac]- [javac] *** Error: org/apache/commons/lang/Strings is either a misplaced package name or a non-existent entity. [javac] [javac] [javac] 68. str = Strings.replace(str,,amp;); [javac] - [javac] *** Error: Strings is either a misplaced package name or a non-existent entity. [javac] [javac] [javac] 69. str = Strings.replace(str,,lt;); [javac] - [javac] *** Error: Strings is either a misplaced package name or a non-existent entity. [javac] [javac] [javac] 70. str = Strings.replace(str,,gt;); [javac] - [javac] *** Error: Strings is either a misplaced package name or a non-existent entity. [javac] [javac] [javac]113. int count = Strings.countMatches(text.substring(start, nextCloseIdx), open); [javac] - [javac] *** Error: Strings is either a misplaced package name or a non-existent entity. [javac] [javac] [javac]123. count = Strings.countMatches(text.substring(start, nextCloseIdx), open); [javac] - [javac] *** Error: Strings is either a misplaced package name or a non-existent entity. BUILD FAILED /Users/jon/checkout/jakarta-commons-sandbox/util/build.xml:140: Compile failed, messages should have been provided. Total time: 3 seconds -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/util project.xml build.xml build.properties.sample
jon 02/04/29 19:34:45
Modified:util build.xml
Added: util project.xml
Removed: util build.properties.sample
Log:
maven'ized commons-util
maven kicks ass...
-jon
Revision ChangesPath
1.13 +93 -239 jakarta-commons-sandbox/util/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/util/build.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- build.xml 25 Feb 2002 18:44:27 - 1.12
+++ build.xml 30 Apr 2002 02:34:45 - 1.13
@@ -1,248 +1,102 @@
-project name=Util default=compile basedir=.
+?xml version=1.0?
+project name=Commons-Util default=maven:jar basedir=.
-!--
-Util component of the Jakarta Commons Subproject
-$Id: build.xml,v 1.12 2002/02/25 18:44:27 bayard Exp $
---
+ !-- Give user a chance to override without editing this file
+ (and without typing -D each time they invoke a target) --
-
-!-- == Initialize Properties = --
-
-
- property file=build.properties/!-- Component local --
- property file=../build.properties/ !-- Commons local --
- property file=${user.home}/build.properties/ !-- User local--
-
-
-!-- == External Dependencies = --
-
-
- !-- The directory containing your binary distribution of JUnit,
- version 3.7 or later --
- property name=junit.home value=/usr/local/junit3.7/
- property name=lang.home value=../lang/
-
-
-!-- == Derived Values --
-
-
- !-- The pathname of the junit.jar JAR file --
- property name=junit.jar value=${junit.home}/junit.jar/
- property name=commons-lang.api value=${lang.home}/dist/docs/api/
- property name=commons-lang.jar value=${lang.home}/dist/commons-lang.jar/
-
-
-!-- == Component Declarations --
-
-
- !-- The name of this component --
- property name=component.name value=util/
-
- !-- The primary package name of this component --
- property name=component.package value=org.apache.commons.util/
-
- !-- The title of this component --
- property name=component.title value=Jakarta Commons Utilities/
-
- !-- The current version number of this component --
- property name=component.version value=1.0-rc2-dev/
-
- !-- The base directory for compilation targets --
- property name=build.home value=target/
-
- !-- The base directory for component configuration files --
- property name=conf.home value=src/conf/
-
- !-- The base directory for distribution targets --
- property name=dist.home value=dist/
-
- !-- The base directory for component sources --
- property name=source.home value=src/java/
-
- !-- The base directory for unit test sources --
- property name=test.home value=src/test/
-
-
-!-- == Compiler Defaults = --
-
-
- !-- Should Java compilations set the 'debug' compiler option? --
- property name=compile.debug value=true/
-
- !-- Should Java compilations set the 'deprecation' compiler option? --
- property name=compile.deprecation value=true/
-
- !-- Should Java compilations set the 'optimize' compiler option? --
- property name=compile.optimizevalue=true/
-
- !-- Construct compile classpath --
- path id=compile.classpath
-pathelement location=${build.home}/classes/
-pathelement location=${commons-lang.jar}/
- /path
-
-
-!-- == Test Execution Defaults === --
-
-
- !-- Construct unit test classpath --
- path id=test.classpath
-pathelement location=${build.home}/classes/
-pathelement location=${build.home}/tests/
-pathelement location=${commons-lang.jar}/
-pathelement location=${junit.jar}/
- /path
-
- !-- Should all tests fail if one does? --
- property name=test.failonerrorvalue=true/
-
- !-- The test runner to execute --
- property name=test.runner value=junit.textui.TestRunner/
-
-
-!-- == Executable Targets --
-
-
- target name=init
- description=Initialize and evaluate conditionals
-echo message= ${component.name} ${component.version} /
-filter token=name value=${component.name}/
-filter token=package value=${component.package}/
-filter token=version value=${component.version}/
-
cvs commit: jakarta-commons-sandbox/graph2 project.xml
jon 02/04/29 19:47:09 Modified:graph2 project.xml Log: removed duplicate mention of same dependency Revision ChangesPath 1.3 +0 -7 jakarta-commons-sandbox/graph2/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/graph2/project.xml,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- project.xml 24 Mar 2002 15:50:00 - 1.2 +++ project.xml 30 Apr 2002 02:47:08 - 1.3 @@ -54,13 +54,6 @@ /dependency dependency - namensuml/name - typerequired/type - version1.0/version - jarnsuml.jar/jar - /dependency - - dependency namelog4j/name typerequired/type version1.1.3/version -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/email/src/test - New directory
jon 02/04/29 20:00:48 jakarta-commons-sandbox/email/src/test - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/email .cvsignore project.xml build.xml build.properties
jon 02/04/29 20:02:08
Modified:emailbuild.xml
Added: email.cvsignore project.xml
Removed: emailbuild.properties
Log:
build with maven now.
-jon
Revision ChangesPath
1.4 +75 -205 jakarta-commons-sandbox/email/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-commons-sandbox/email/build.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- build.xml 28 Feb 2002 18:03:51 - 1.3
+++ build.xml 30 Apr 2002 03:02:08 - 1.4
@@ -1,232 +1,102 @@
-project name=Jakarta Commons Email default=jar basedir=.
+?xml version=1.0?
-!--
-$Id: build.xml,v 1.3 2002/02/28 18:03:51 dlr Exp $
---
+project name=Commons-Email default=maven:jar basedir=.
-!-- == Initialize Properties === --
+ !-- Give user a chance to override without editing this file
+ (and without typing -D each time they invoke a target) --
!-- Allow any user specific values to override the defaults --
property file=${user.home}/build.properties /
-
- !-- Set default values for the build --
+ !-- Allow user defaults for this project --
property file=build.properties /
+ !-- Set default values for the build --
+ property file=project.properties /
-!-- == Component Declarations == --
-
-
- !-- The name of this component --
- property name=component.name value=commons-email/
-
- !-- The title of this component --
- property name=component.title value=Jakarta Commons Email/
-
- !-- The current version number of this component --
- property name=component.version value=0.1-dev/
-
- !-- The JAR file for this component --
- property name=component.jar
value=${component.name}-${component.version}.jar/
-
- !-- The base directory for compilation targets --
- property name=build.home value=target/
-
- !-- The base directory for distribution targets --
- property name=dist.home value=dist/
-
- !-- The base directory for component sources --
- property name=source.home value=src/
-
- !-- The base directory for unit test sources --
- property name=test.home value=src/test/
-
-
-!-- == Compiler Defaults === --
-
-
- !-- Should Java compilations set the 'debug' compiler option? --
- property name=compile.debug value=false/
-
- !-- Should Java compilations set the 'deprecation' compiler option? --
- property name=compile.deprecation value=true/
-
- !-- Should Java compilations set the 'optimize' compiler option? --
- property name=compile.optimize value=true/
-
- !-- Construct compile classpath --
- path id=classpath
-pathelement location=${javamail.jar}/
-pathelement location=${jaf.jar}/
-pathelement location=${commons-util.jar}/
- /path
-
-!-- == Test Execution Defaults = --
-
-
- !-- Construct unit test classpath --
- path id=test.classpath
-pathelement location=${build.home}/classes/
-pathelement location=${build.home}/tests/
-pathelement location=${junit.jar}/
- /path
-
- !-- Should all tests fail if one does? --
- property name=test.failonerror value=true/
-
- !-- The test runner to execute --
- property name=test.runner value=junit.textui.TestRunner/
-
-
-!-- == Executable Targets == --
-
- target name=init
-description=Initialize and evaluate conditionals
-echo message= ${component.name} ${component.version} /
-filter token=name value=${component.name}/
-filter token=version value=${component.version}/
-
-available
- classname=org.apache.commons.util.GenerateUniqueId
- property=commons-util.present
- classpathref=classpath
-/
-
-available
- classname=javax.mail.internet.MimeUtility
- property=javamail.present
- classpathref=classpath
-/
-
-available
- classname=javax.activation.DataSource
- property=jaf.present
- classpathref=classpath
-/
-
+ !-- maven:start --
+
+ !-- == --
+ !-- D E L E G A T O R S--
+ !-- == --
+
+ target
+name=maven:site
+ant antfile=${maven.home}/build-docs.xml target=site/
/target
-
- target name=check.javamail unless=javamail.present
-antcall target=property-warning
- param name=name value=javamail.jar/
- param name=value value=${javamail.jar}/
-/antcall
+
+ target
+
test ignore
test time is 2:40PM Chris -- Chris Lomvardias [EMAIL PROTECTED] PublicBuy.Net 400 E. Pratt Street, Suite 300 Baltimore, MD 21202 (410)539-3737 x1722 voice (410)539-7302 fax [EMAIL PROTECTED] (pager via email) -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
