Question about DBCP
Hi all, Can anyone provide pointers to open source sites using DBCP? I am trying to get DBCP to work with DbForms (www.dbforms.org). DbForms currently uses Poolman as it's suggested pool for JDBC connections, but it badly needs something newer and easier to set up! I have managed to tweak the class ManualPoolingDataSourceExample to work with MSSql Server. However, what is confusing to me is how in the example my jdbc driver is passed in? I see it goes in from the commandline as -Djdbc.drivers=oracle.jdbc.driver.OracleDriver, but I never see how it get's used. In addition, when i hardcoded my driver, I couldn't get it to work until I added a Class.forName(com.microsoft.jdbc.sqlserver.SQLServerDriver) at the top of the code in my copy of ManualPoolingDataSourceExample. Can someone give me some pointers on how the -Djdbc.drivers value actually get's registered with the DriverManager? Also, how can I verify that I am actually pooling connections, versus creating a new one over and over? I have attached my copy of ManualPoolingDataSourceExample that I have renamed to ManualPoolingDataSourceTest, and am using under JUnit to test. Eric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Question about DBCP
Sorry, hit send button too quick. I am attaching my JUnit test that I am working with. Thanks, Eric -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 10:20 AM To: 'Jakarta Commons Developers List' Subject: Question about DBCP Hi all, Can anyone provide pointers to open source sites using DBCP? I am trying to get DBCP to work with DbForms (www.dbforms.org). DbForms currently uses Poolman as it's suggested pool for JDBC connections, but it badly needs something newer and easier to set up! I have managed to tweak the class ManualPoolingDataSourceExample to work with MSSql Server. However, what is confusing to me is how in the example my jdbc driver is passed in? I see it goes in from the commandline as -Djdbc.drivers=oracle.jdbc.driver.OracleDriver, but I never see how it get's used. In addition, when i hardcoded my driver, I couldn't get it to work until I added a Class.forName(com.microsoft.jdbc.sqlserver.SQLServerDriver) at the top of the code in my copy of ManualPoolingDataSourceExample. Can someone give me some pointers on how the -Djdbc.drivers value actually get's registered with the DriverManager? Also, how can I verify that I am actually pooling connections, versus creating a new one over and over? I have attached my copy of ManualPoolingDataSourceExample that I have renamed to ManualPoolingDataSourceTest, and am using under JUnit to test. Eric -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] ManualPoolingDataSourceTest.java Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Question about DBCP
I see, when the docs are referring to the property jdbc.drivers, that is something passed to the JVM that makes it load them implicitly for you! However, I am planning on calling this from another application, DbForms. Therefore, I need the driver to be specified in the JOCL file.. Is there an attriubte specified that I can use to provide that, or do I have to work via passing it in via the property. Eric -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 1:19 PM To: 'Jakarta Commons Developers List' Subject: RE: Question about DBCP Thanks for the info, I guess the whole JOCL thing was scaring me.. What is JOCL? It appears to be some sort of weird config format only used by DBCP? I guess I didn't want to try and figure it all out (lazy me!)... Also, DbForms uses the Digester to parse an XML file, and DBForms tanks if I add in Xalan/Xerces with Digester in the classpath.. I was hoping to keep things simple, but I will look at the JOCLPoolingDriverExample. Did you basically just use the example as your code? I'm trying to solve a problem without customizing/writing much at all! Lastly, is there any way to have a monitor on the pool size? Eric -Original Message- From: Anjan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 12:42 PM To: Jakarta Commons Developers List Subject: RE: Question about DBCP Hi Eric!, I was using poolman in our NON open-source product but eventually moved to DBCP -- it works fine for me. Did you look at JOCLPoolingDriverExample.java in the doc directory ? This gives a sample of how the DriverManager uses the jdbc.drivers property. When DriverManager loads, it looks for the property jdbc.drivers and then loads all the drivers specified in this property(Be sure to separate the drivers in this property using COLONs and NOT SEMI-COLONs. You don't have to use Class.forName() on it since JDBC(1.2 JDK and later) uses this property to load all the drivers and initialize the drivers(actually the drivers register with the DriverManager when they are loaded). If you want to know more, you can look into the source of DriverManager in the JDK source. You will know that pooling is working by the speed with which the connections are obtained when you use DriverManager.getConnection(url); Best Regards, ANJAN. B -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 7:20 AM To: 'Jakarta Commons Developers List' Subject: Question about DBCP Hi all, Can anyone provide pointers to open source sites using DBCP? I am trying to get DBCP to work with DbForms (www.dbforms.org). DbForms currently uses Poolman as it's suggested pool for JDBC connections, but it badly needs something newer and easier to set up! I have managed to tweak the class ManualPoolingDataSourceExample to work with MSSql Server. However, what is confusing to me is how in the example my jdbc driver is passed in? I see it goes in from the commandline as -Djdbc.drivers=oracle.jdbc.driver.OracleDriver, but I never see how it get's used. In addition, when i hardcoded my driver, I couldn't get it to work until I added a Class.forName(com.microsoft.jdbc.sqlserver.SQLServerDriver) at the top of the code in my copy of ManualPoolingDataSourceExample. Can someone give me some pointers on how the -Djdbc.drivers value actually get's registered with the DriverManager? Also, how can I verify that I am actually pooling connections, versus creating a new one over and over? I have attached my copy of ManualPoolingDataSourceExample that I have renamed to ManualPoolingDataSourceTest, and am using under JUnit to test. Eric -- 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] -- 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: Question about DBCP
Well,
I wanted to post to the list what I learned! Firstly, thanks to Craig for
his quick patch on exposing the number of active and idle connections for
BasicDataSource.
I am able to successfully pool connections for use by DbForms. That is
wonderful! I am currently running on MSSQLServer 2000 and use the MS
JDBCODBC driver. I ended up using the BasicDataSource because it was easy.
Some things I have noticed/have questions:
1) If I don't provide a maxActive, then when I go for the first connection,
nothing happends.
2) What exactly does the idle mean? At one point I had 5 connections
running according to the database server, but according to the the numIdle,
numActive, I only had 2 active, 0 idle.. Are there some extra connections
as overhead? I know I wasn't using any of them for other processes.
3) What is the difference between the BasicDataSource and the
BasicDataSourceFactory? Is BasicDataSource what I should be using to pool
my db connections for a web app?
4) The code for the Tomcat 4.0 DBCPPoolFactory (sp?) in CVS seems to have
been replaced with the text of an Ant Build file. (I got that browsing via
the web cvs).
How I configured my DataSource:
try{
if (dataSource == null){
dataSource = new BasicDataSource();
dataSource.setDriverClassName(conClass);
dataSource.setUrl(name);
dataSource.setPassword(password);
dataSource.setUsername(username);
dataSource.setValidationQuery(null);
dataSource.setMaxActive(20);
dataSource.setMaxIdle(5);
dataSource.setMaxWait(-1);
}
logCat.debug(Current Connections: active: +
dataSource.getNumActive()
+, idle: + dataSource.getNumIdle());
return dataSource.getConnection();
}
catch (Exception e){
logCat.error(e);
e.printStackTrace();
return null;
}
Thank you very much for the help,
Eric
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 30, 2002 2:07 PM
To: Jakarta Commons Developers List
Subject: RE: Question about DBCP
On Tue, 30 Apr 2002, Eric Pugh wrote:
Date: Tue, 30 Apr 2002 13:18:59 -0400
From: Eric Pugh [EMAIL PROTECTED]
Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' [EMAIL PROTECTED]
Subject: RE: Question about DBCP
Thanks for the info,
I guess the whole JOCL thing was scaring me.. What is JOCL? It appears
to
be some sort of weird config format only used by DBCP? I guess I didn't
want to try and figure it all out (lazy me!)... Also, DbForms uses the
Digester to parse an XML file, and DBForms tanks if I add in Xalan/Xerces
with Digester in the classpath.. I was hoping to keep things simple, but
I
will look at the JOCLPoolingDriverExample.
Did you basically just use the example as your code? I'm trying to solve
a
problem without customizing/writing much at all!
A different approach would be to use a pre packaged data source
implementation like org.apache.commons.dbcp.BasicDataSource. This is what
Tomcat 4.1 is going to use as the default data source implementation
(accessbile via JNDI), but it also works fine in other environments --
just configure it with JavaBeans property setters in whatever manner you'd
like.
Lastly, is there any way to have a monitor on the pool size?
The underlying pool implementations have numActive() and numIdle() methods
-- this would need to be rippled up to be visible through the DBCP
implementation -- I just checked in an update to BasicDataSource for this.
Eric
Craig
-Original Message-
From: Anjan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 30, 2002 12:42 PM
To: Jakarta Commons Developers List
Subject: RE: Question about DBCP
Hi Eric!,
I was using poolman in our NON open-source product but eventually
moved to DBCP -- it works fine for me.
Did you look at JOCLPoolingDriverExample.java in the doc directory ?
This gives a sample of how the DriverManager uses the jdbc.drivers
property.
When DriverManager loads, it looks for the property jdbc.drivers
and then loads all the drivers specified in this property(Be sure to
separate the drivers in this property using COLONs and NOT SEMI-COLONs.
You don't have to use Class.forName
RE: Community (was: Re: You make the decision (was Re: Quick! convertall yourprojects to maven!))
As someone who uses Maven in his own projects (and is evangelizing it in other non Jakarta projects) I would love to see Common's built using Maven. But really, if Common's was built with either Maven or Krysalis, we would have some of the same advantages, not having to decipher build.xml files to get good compiles! I ended up having to tweak the dbcp build.xml because of various classpath issues. Now I have to remember those changes whenever I rebuild dbcp from CVS. If it uses a standard build system, then life will be much easier... PS, In reading, one of the things I like best about VisualStudio is the addition of more build structure. Not trying to start a flame war about .net or anything, but if Java has a solid open source build system (whatever it ends up being) the better it looks to compete. Eric -Original Message- From: Amir D. Kolsky [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 6:22 PM To: Jakarta Commons Developers List Subject: RE: Community (was: Re: You make the decision (was Re: Quick! convertall yourprojects to maven!)) I am very weary of any NIH type sentiment, is it might eventually lead to massive wastes of effort. I am aware of neither Maven nor Krysalis, so I can't comment on anything but the dogfood sentiment. Dogs don't really care where their food come from, they just eat it... Yours truly, Fido -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Wed, May 01, 2002 1:17 AM To: Jakarta Commons Developers List Subject: Community (was: Re: You make the decision (was Re: Quick! convertall yourprojects to maven!)) on 4/30/02 3:04 PM, Amir D. Kolsky [EMAIL PROTECTED] wrote: Krysalis isn't our own dog food. Argh NIH Yes. I admit that I'm biased towards Jakarta technologies, but it has nothing to do with NIH (focus on invented), think of it more like me being community centered. The same reason why I use Catalina instead of Jetty. Both are good containers, it is just that Catalina came from here and this is my community that I belong to. I support the community I belong to. Simple. Now, why doesn't Krysalis join with Maven? Would that be calling the Krysalis developers NIH? I don't think so...it is their choice. I also gave valid technical reasons why I prefer Mavenhowever, you choose to focus on the dog food statement. Yawn. I await your patches. -jon -- 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] attachment: winmail.dat -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [pool] 1.0 release soon
I would love to see pool and dbcp make it to 1.0! I am using them to provide pooling for DBForms in a soon to be in production application.. And it just makes me feel better to know the code is all at least 1.0! Eric -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 5:49 PM To: Jakarta Commons Developers List Subject: RE: [pool] 1.0 release soon On Fri, 3 May 2002, Waldhoff, Rodney wrote: Date: Fri, 3 May 2002 12:26:54 -0500 From: Waldhoff, Rodney [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Subject: RE: [pool] 1.0 release soon Any remaining to-dos for a 1.0 commons-pool release? My list is done. I just removed the KeyedObjectPool.numActive and KeyedObjectPool.numIdle methods, so we may want to wait for a clean gump build, but otherwise I think we're OK. (Bugzilla is also clear of pool-related bugs.) I'm ready for this (and for dbcp). - Rod Craig -- 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]
[PATCH] Small Documentation Error in NestableException
Hi all, I couldn't seem to find the page on the Jakarta site that specifies how to create a proper diff patch. There where some small documentation errors for org.apache.commons.lang.exception.NestableException that I stubbed my toe on when I first tried to use it. Eric cvs -z9 -q diff -w -i NestableException.java (in directory C:\java\jakarta-commons-sandbox\lang\src\java\org\apache\commons\lang\except ion\) Index: NestableException.java === RCS file: /home/cvspublic/jakarta-commons-sandbox/lang/src/java/org/apache/commons/lan g/exception/NestableException.java,v retrieving revision 1.1 diff -w -i -r1.1 NestableException.java 79c79 * 1 import org.apache.commons.NestedException; --- * 1 import org.apache.commons.lang.exception.NestableException; 94c94 * 16 throw new NestedException(foo, e); --- * 16 throw new NestableException(foo, e); 102c102 * 24 throw new NestedException(bar, e); --- * 24 throw new NestableException(bar, e); 116c116 * rethrown as NestedException: bar --- * rethrown as NestableException: bar 119c119 * rethrown as NestedException: foo --- * rethrown as NestableException: foo 126a127 * @author a href=mailto:[EMAIL PROTECTED];Eric Pugh/a -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[COLLECTIONS/BEANUTILS] Is there a comparator that can dynamically pick a method to call on a bean?
Hi all,
I have a series of Torque objects that I want to sort. Sometimes I want to
sort by MethodA, sometiems by MethodB. (Basically mapping onto all the
columns in my database).
Right now, I have a comparator compare method that looks like this:
public int compare( Object o1, Object o2 ) {
Daughterboard db1 = (Daughterboard) o1;
Daughterboard db2 = (Daughterboard) o2;
int sort = 0;
if ( sortMethod.equals( ScintillationFileNumber ) ) {
/*
* if ( db1 == null == db2 ) {
* return 0;
* }
* else if (db1 == null
*/
sort = Strings.clean( db1.getScintillationFileNumber()
).compareTo(
Strings.clean( db2.getScintillationFileNumber() ) );
}
else if ( sortMethod.equals( DaughterboardId ) ) {
sort = db1.getDaughterboardId().compareTo(
db2.getDaughterboardId() );
}
if ( sortPolarity.equals( desc ) ) {
sort = sort * -1;
}
return sort;
}
What I really want to do is pass in a sortMethod like
ScintillationFileNumber, and dynamically call the objects getter for that
name. If I wrap my object in a WrapDynaBean, and use that to call the data,
will is actually change the ordering of my objects? Or should I just use
the WrapDynaBean locally inside of my compare method to facilitate calling
the methods?
First time using BeanUtils, but it looks great..
Lastly, would a comparator like this be something of general interest to add
to the collections list of comparators?
Eric
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [COLLECTIONS/BEANUTILS] Is there a comparator that can dynamically pick a method to call on a bean?
I forged ahead.. I had a need to sort in asc/desc... so I have added a
sortPolarity and sortProperty methods..
Here is what I created...
package com.upstate.util;
import org.apache.commons.beanutils.WrapDynaBean;
import org.apache.commons.beanutils.*;
import org.apache.log4j.Category;
/**
* Description of the Class
*
*@author epugh
*@createdMay 5, 2002
*/
public class BeanMethodComparator implements java.util.Comparator {
public final static String ASC = ASC;
public final static String DESC = DESC;
private static Category log = Category.getInstance(
BeanMethodComparator.class.getName() );
private String sortProperty;
private String sortPolarity = ASC;
/** Constructor for the BeanMethodComparator object */
public BeanMethodComparator() { }
/**
* Constructor for the BeanMetodComparator object
*
*@param sortProperty Description of Parameter
*@param sortPolarity Description of Parameter
*/
public BeanMethodComparator( String sortProperty, String sortPolarity ) {
setSortProperty( sortProperty );
setSortPolarity( sortPolarity );
}
/**
* Sets the sortProperty attribute of the SortDaughterboard object
*
*@param sortProperty The new sortProperty value
*/
public void setSortProperty( String sortProperty ) {
this.sortProperty = sortProperty;
}
/**
* Sets the sortPolarity attribute of the SortDaughterboard object
*
*@param sortPolarityThe new sortPolarity
value.
* Can be either ASC/DESC.
*@exception java.lang.IllegalArgumentException Thrown if you pass in a
bad
* sortPolarity.
*/
public void setSortPolarity( String sortPolarity )
throws java.lang.IllegalArgumentException {
sortPolarity = sortPolarity.toUpperCase();
if ( sortPolarity.equals( ASC ) || sortPolarity.equals( DESC ) ) {
throw new java.lang.IllegalArgumentException( The argument: +
sortPolarity + was invalid. );
}
this.sortPolarity = sortPolarity;
}
/**
* Gets the sortPolarity attribute of the SortDaughterboard object
*
*@returnThe sortPolarity value
*/
public String getSortPolarity() {
return sortPolarity;
}
/**
* Gets the sortProperty attribute of the SortDaughterboard object
*
*@returnThe sortProperty value
*/
public String getSortProperty() {
return sortProperty;
}
/**
* Description of the Method
*
*@param o1 Description of Parameter
*@param o2 Description of Parameter
*@return Description of the Returned Value
*/
public int compare( Object o1, Object o2 ) {
try {
WrapDynaBean bean1 = new WrapDynaBean( o1 );
WrapDynaBean bean2 = new WrapDynaBean( o2 );
Comparable value1 = (Comparable) bean1.get( sortProperty );
Comparable value2 = (Comparable) bean2.get( sortProperty );
int sort = 0;
if ( ( value1 == null ) ( value2 == null ) ) {
sort = 0;
}
else if ( value1 == null value2 != null ) {
sort = 1;
}
else if ( value1 != null value2 == null ) {
sort = -1;
}
else {
sort = value1.compareTo( value2 );
}
if ( sortPolarity.equals( DESC ) ) {
sort = sort * -1;
}
return sort;
}
catch ( Exception e ) {
log.error( Problem in Sort. sortPolarity: + sortPolarity + ,
sortProperty: + sortProperty, e );
return 0;
}
}
}
Eric Pugh
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 10:50 AM
To: Jakarta Commons Developers List
Subject: Re: [COLLECTIONS/BEANUTILS] Is there a comparator that can
dynamically pick a method to call on a bean?
I don't think there is one in Commons yet. I've had one for myself for a
bit and it can be a lifesaver sometimes.
BeanComparator bc = new BeanComparator([1]); was very sweet when I
realised that would work :) Not just Beans but also arrays/collections.
I'm +1 for a BeanComparator, +1
RE: [COLLECTIONS/BEANUTILS] Is there a comparator that can dynamically pick a method to call on a bean?
Works for me.. For my application, if there was a good comparator, then I
would probably wrap up my code in something that combined ReverseComparator
and BeanMethodComparartor properly...
I guess I was just kinda tossing it out as an example.. If there is
interest in adding it to CVS, I will make the changes, change the package
class and add licesnising etc
Eric
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 11:21 AM
To: Jakarta Commons Developers List
Subject: RE: [COLLECTIONS/BEANUTILS] Is there a comparator that can
dynamically pick a method to call on a bean?
-1 to the ASC/DESC bit. That shouldn't be in comparators in my opinion,
instead use the ReverseComparator.
What is Polarity vs Property?
On Fri, 7 Jun 2002, Eric Pugh wrote:
I forged ahead.. I had a need to sort in asc/desc... so I have added a
sortPolarity and sortProperty methods..
Here is what I created...
package com.upstate.util;
import org.apache.commons.beanutils.WrapDynaBean;
import org.apache.commons.beanutils.*;
import org.apache.log4j.Category;
/**
* Description of the Class
*
*@author epugh
*@createdMay 5, 2002
*/
public class BeanMethodComparator implements java.util.Comparator {
public final static String ASC = ASC;
public final static String DESC = DESC;
private static Category log = Category.getInstance(
BeanMethodComparator.class.getName() );
private String sortProperty;
private String sortPolarity = ASC;
/** Constructor for the BeanMethodComparator object */
public BeanMethodComparator() { }
/**
* Constructor for the BeanMetodComparator object
*
*@param sortProperty Description of Parameter
*@param sortPolarity Description of Parameter
*/
public BeanMethodComparator( String sortProperty, String sortPolarity ) {
setSortProperty( sortProperty );
setSortPolarity( sortPolarity );
}
/**
* Sets the sortProperty attribute of the SortDaughterboard object
*
*@param sortProperty The new sortProperty value
*/
public void setSortProperty( String sortProperty ) {
this.sortProperty = sortProperty;
}
/**
* Sets the sortPolarity attribute of the SortDaughterboard object
*
*@param sortPolarityThe new sortPolarity
value.
* Can be either ASC/DESC.
*@exception java.lang.IllegalArgumentException Thrown if you pass in a
bad
* sortPolarity.
*/
public void setSortPolarity( String sortPolarity )
throws java.lang.IllegalArgumentException {
sortPolarity = sortPolarity.toUpperCase();
if ( sortPolarity.equals( ASC ) || sortPolarity.equals( DESC ) ) {
throw new java.lang.IllegalArgumentException( The argument: +
sortPolarity + was invalid. );
}
this.sortPolarity = sortPolarity;
}
/**
* Gets the sortPolarity attribute of the SortDaughterboard object
*
*@returnThe sortPolarity value
*/
public String getSortPolarity() {
return sortPolarity;
}
/**
* Gets the sortProperty attribute of the SortDaughterboard object
*
*@returnThe sortProperty value
*/
public String getSortProperty() {
return sortProperty;
}
/**
* Description of the Method
*
*@param o1 Description of Parameter
*@param o2 Description of Parameter
*@return Description of the Returned Value
*/
public int compare( Object o1, Object o2 ) {
try {
WrapDynaBean bean1 = new WrapDynaBean( o1 );
WrapDynaBean bean2 = new WrapDynaBean( o2 );
Comparable value1 = (Comparable) bean1.get( sortProperty );
Comparable value2 = (Comparable) bean2.get( sortProperty );
int sort = 0;
if ( ( value1 == null ) ( value2 == null ) ) {
sort = 0;
}
else if ( value1 == null value2 != null ) {
sort = 1;
}
else if ( value1 != null value2 == null ) {
sort = -1;
}
else {
sort = value1.compareTo( value2 );
}
if ( sortPolarity.equals( DESC ) ) {
sort = sort * -1;
}
return sort;
}
catch ( Exception e
RE: [Collections] ComparableComparator - nulls OK
+1, In my sorts, having to deal with nulls is causing me difficulties as well.. Although I could see something like any nulls being ignored as a type of behavior.. Sort everything, and drop the nulls! Eric -Original Message- From: Jonathan Carlson [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 3:38 PM To: [EMAIL PROTECTED] Subject: [Collections] ComparableComparator - nulls OK I'd like to make the case for a ComparableComparator that allows the sorting of nulls to the bottom. This could be a flag to set on the existing class or another Comparator called something like NullableComparableComparator (or ComparableNullComparator?). This becomes a big issue when sorting a collection of things based on one of their getter methods with generic components like the TransformingComparator I just submitted. Too often the returned value can be a null. It's not too hard to write my own (I already have), but I prefer having things like this standardized in one library rather than written differently for each project. My two cents. I'd appreciate feedback, even negative feedback if it's appropriate. Jonathan = Jonathan Carlson [EMAIL PROTECTED] Minneapolis, Minnesota __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- 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/BEANUTILS] Is there a comparator that can dynamically pick a method to call on a bean?
Good suggestion... I guess I could do that, except for when the object is
some random weird object with it's own specialized compareTo method... Like
maybe some sort of tree being compared to some other tree...? I am not sure
how often that would come up though!
Does any one have any statistics on how fast CASE_INSENSITIVE_ORDER is
compared to other comparators..
The other reason, and why I started down this path was the original big
decimals: 2, 12, and 22, when compared as strings come out as 12, 2, 22!
That I guess is why it seemed to me that using Lowercase when you have other
comparators to call, or both sides are not Strings is the way to go, versus
blindly changing to Strings... I think the transforming comparator comes
into its own when you have multiple disparate (sp?) objects that you want to
compare together, versus multiple types of objects that are all the same...
I take it to submit the code I send an email with subject
[SUBMIT][COLLECTIONS]? Is there interest in CaseInsensitiveComparator the
way I outlined?
Eric
-Original Message-
From: Jack, Paul [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 5:11 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [COLLECTIONS/BEANUTILS] Is there a comparator that can
dynamically pick a method to call on a bean?
Why not use a TransformingComparator to transform the objects
into strings before passing them to CASE_INSENSITIVE_ORDER?
I really am just trying to help. :)
-Paul
-Original Message-
From: Eric Pugh [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 2:07 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [COLLECTIONS/BEANUTILS] Is there a comparator that can
dynamically pick a method to call on a bean?
Now I figured out why I have the Lowercase comparator.. I am
using the
lowercase comparator decorated by BeanCompartor, which
sometiems passes
strings to lowercase comparator and other times passes other
objects...
CASE_INSENSITIVE_ORDER throws classcastexceptions on anything
that is not a
string..
So, how about changing LowercaseComparator to
CaseInsensitiveComparator
which wraps a call to CASE_INSENSITIVE_ORDER when both args
are Strings, and
otherwise doesn't? The problem is still that you can't daisy
chain any
furthur.. Maybe only use CaseInsensitiveComparator when the
user doesn't
pass in another comparator, other do the toLowerCase call...
ERic
-Original Message-
From: Jack, Paul [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 4:45 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [COLLECTIONS/BEANUTILS] Is there a comparator that can
dynamically pick a method to call on a bean?
FYI, java.lang.String.CASE_INSENSITIVE_ORDER does what your
LowercaseComparator does, but somewhat more efficiently.
-Paul
-Original Message-
From: Eric Pugh [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 10, 2002 1:35 PM
To: 'Jakarta Commons Developers List'
Subject: RE: [COLLECTIONS/BEANUTILS] Is there a comparator that can
dynamically pick a method to call on a bean?
Hi all,
Attached is my first attempt at submitting a BeanComparator,
along with the
test case.. However, i am running into two issues becomes of
my lack of
familiarty with beans that are causing me pain. However, in my app,
everything is working great! My testcase is attached.
1) the test suite fails because my test object which has a
getBeanValue and
setBeanValue causes the WrapDynaBean class to throw an
exception that
value has no read method.. Yet it does, and in other uses of the
BeanComparator in my code it works great.
2) All comparisions are string comparisons.. So when I
compare Bigdecimals
2, 12, and 22, the orders is 12, 2, 22! Do I need to hand in
another class
to cast the objects to?
Also, I would love to see the ComparatorUtils, I created my
own one to
handle the reversing of my sorts based on the text values
ASC/DESC, and
removed them from my BeanComparator.
I have also attached my LowercaseComparator.. I was sorting
columns of
String data, and noticed that if I didn't lowercase them, the
A versus a
differenced caused funny looking ordering. I also set up
LowercaseComparator and BeanComparator to work as decorators
(similar to
ReverseComparator). Lastly, for the bean comparator, I am using
PropertyUtils, so if you can pass in NESTED properties!
customer.name
results in getCustomer().getName() being returned! I would
love to add
jxPath converter as I build up some more experience!
Here is some sample code:
public static Comparator sortedBean( String sortProperty, String
sortPolarity )
throws java.lang.IllegalArgumentException {
Comparator c = null;
sortPolarity = sortPolarity.toUpperCase();
if ( !sortPolarity.equals( ASC )
!sortPolarity.equals( DESC ) ) {
throw new
RE: [COLLECTIONS/BEANUTILS] Is there a comparator that can dynamically pick a method to call on a bean?
I see your question.. If there is no Comparator passed in then the ComparableComparator is used.. The reason I was getting weird results was that for the method getPrimaryKey() in my objects, there where two matching methods, one that returned String objects, the other returned BigDecimal objects.. However BeanComparator (via PropertyUtils) was returning the String version.. So the comparision was 2 versus 22, not 2 versus 22 etc... Eric -Original Message- From: Henri Yandell [mailto:[EMAIL PROTECTED]] Sent: Monday, June 10, 2002 5:44 PM To: Jakarta Commons Developers List Subject: RE: [COLLECTIONS/BEANUTILS] Is there a comparator that can dynamically pick a method to call on a bean? On Mon, 10 Jun 2002, Eric Pugh wrote: The other reason, and why I started down this path was the original big decimals: 2, 12, and 22, when compared as strings come out as 12, 2, 22! I still don't get this. Why are they compared as strings?? Is it if a Comparator isn't passed in the constructor? Why not ComparableComparator? Hen -- 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]
[SUBMIT][COLLECTIONS]
Hi all, I *think* I made all the changes for BeanComparator that were suggested.. I am still working on various changes to CaseInsensitiveIterator, but am not ready to submit that. So I wanted to go ahead and submit BeanComparator for inclusion in the Collections package. Thanks, Eric Pugh BeanComparator.java Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Three month contribution to Commons?
Jeff... The approach you might take is to go through some of the commons projects and look at the list of todo that some maintain(http://jakarta.apache.org/commons/sandbox/configuration/tasks.html) . Then, submit patches that fix those problems. You might also want to use a tool like clover and look at which commons projects are light on testcases. Then provide tests to those projects. Comprehensive testing, while a pain to do after the fact, is very important to the long term success of any project. Just to throw out something to look at, the Configuration project in the sandbox has a couple things it would like. Something to start with that wouldn't take too much time is a JDBCConfiguration that provided a Configuration object backed by a database table. If you could provide something like that (plus testcases!) I promise to look at the patches for you. As far as getting your own projects into Commons, to be granted karma you have to be around a while so people get to know you and are confortably with your approach to coding. Sincerely, Eric Pugh -Original Message- From: Jeff Epstein [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 5:44 AM To: [EMAIL PROTECTED] Subject: Three month contribution to Commons? Hello there. I am an MSIS student (Masters of Science, Information System) at Drexel University, with five years professional experience under my belt (mostly server-side Java and Oracle). I have the opportunity to take a three month independent study (about twenty hours a week, September through December), and, if you'll have me, I would love to spend that time contributing something significant to the Jakarta Commons project. Is there something specific that you need, that I could start-and-finish within this time? As far as the Commons sub-projects that I'm familiar with, I'm particularly interested in CLI and Lang (but am quite open to others). I've been working on my own Lang-like project for six years now, XBN Java. I don't deny how much I have to learn--I'm not even sure anyone else uses it--but XBN Java is one of my proudest accomplishments. *I* use it for everything I do. I am reading the how to contribute articles spiced about the Jakarta site, figuring out what I can. Is there perhaps any specific advice on how I might best pursue this with Commons? I understand this would be in an unofficial capacity, but I need to propose something concrete to Drexel within the next three weeks. (A thought: Are there avenues towards getting one's own existing modules/packages proposed and potentially/eventually implemented into the Commons?) Thanks very much. Feel free to check out my resume or downloadable code at my homepage, linked below. :' ) = :' ) Jeffy [EMAIL PROTECTED] http://www.jeffyjeffy.com .. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] Looking to the next version
Matt, Before you get to far, I have written a plugin for Findbugs... I am currently trying to get in touch with the folks running mavenplugins.sf.net to get it added there... I think though people might be on vacation.. At any rate, the findbugs folks are discussing changing the license to asf compatible, whereupon we could put the plugin in the maven core. I am attaching my code, note though it is still pretty raw. Findbugs the next version will have a better classloader. For now now, you have to have all the jars in the lib dir in the plugin. I removed them for the email though.. If you make any improvements, send me a patch file until I can get this up on the maven plugins sourceforge site. Eric Pugh -Original Message- From: __matthewHawthorne [mailto:[EMAIL PROTECTED] Sent: Saturday, August 16, 2003 10:24 PM To: Jakarta Commons Developers List Subject: Re: [lang] Looking to the next version I also thought that the results Henri posted from findbugs (http://www.cs.umd.edu/~pugh/java/bugs/) were very useful. I downloaded the program and have begun to use it, it catches a lot of errors which are easy to miss. I may look into writing a Maven plugin for this, if someone hasn't already. It could be a nice project report to go along with clover, checkstyle, etc. On Sat, 2003-08-16 at 11:29, Stephen Colebourne wrote: Although I'm not a huge maven fan (yet), I am +0.5 this :-) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] One idea I'd like to throw into the mix for the next version of Lang [or maybe it'd still be 2.0 in this case] is to move to a Maven site and use Maven as our primary build. While we're getting Lang out the door, I thought I'd see what people's reaction is to this. We'd get a proper clover licence and publish that, I imagine JDiff can be integrated in, etc etc. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] findbugs.zip Description: Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[math] Would code for generating IC50 curves fit here?
Hi all, I am faced with a needing to generate IC50 (also called EC50) curves for a project. A) Does anyone know of any packages that do this? B) If not, would this be something of interest for Math? Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [lang] .lang.math (WAS: Words - for 2.0)
I think from earlier posts the plan is to deprecate the methods in lang, but only after math reaches a 1.0 release. Eric Pugh -Original Message- From: Gary Gregory [mailto:[EMAIL PROTECTED] Sent: Sunday, August 17, 2003 7:00 PM To: '[EMAIL PROTECTED]' Subject: FW: [lang] .lang.math (WAS: Words - for 2.0) Resending. Since we are on the topic of things in the wrong place... I'll raise another arg and ask: Why have an o.a.c.lang.math when we have a o.a.c.math in the works? If o.a.c.lang.math is really useful, why not move it to o.a.c.math? If you used the now deprecated range classes, you /should/ change your code to .lang.math. Hmm, maybe this is something we could do for 2.1/3.0. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Saturday, August 16, 2003 10:05 To: Jakarta Commons Developers List Subject: Re: [lang] Words - for 2.0 So, not too aarggh then, just pull WordWrapUtils ;-)) (The other stuff this morning was all javadoc except for ToStringStyle where a method rename took place with deprecation) Stephen - Original Message - From: Henri Yandell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Saturday, August 16, 2003 5:56 PM Subject: Re: [lang] Words - for 2.0 On Sat, 16 Aug 2003, Stephen Colebourne wrote: In examining the release, I found I need to annoy everyone again. *aarggh* :) WordWrapUtils is broken. No no no. It's a feature. The algorithm relies on a newLineChars parameter that is used for two purposes. 1) Splitting the input string 2) Adding newlines to the output string This is a new class, so it should either be pulled (preferred) or fixed (not preferred, as there are various issues) +1 to pulled out for consideration for 2.1/other. Related issue - WordWrapUtils is too specific a name. I propose: 1) changing it to WordUtils (or StringWordUtils) +1 on WordUtils. More generic. 2) moving capitalizeAllWords to WordUtils 3) moving uncapitalizeAllWords to WordUtils 4) moving swapCase to WordUtils +1 for 2.1/3.0. This would help reduce the size of StringUtils, and provide much better functional grouping. There is lots we can do with words. (Of course you could argue for a separate [text] project, but I doubt there is that much.) -1 to [text] taking the above until [text] is ready for 1.0. I am +1 for a [text], in the same way I'm +1 for [math], but I don't want us to deprecate our methods until [math] releases at 1.0 with our methods included. I would like to do this for 2.0, as otherwise users of capitaliseAllWords will have to change twice. However we could say that is a small group of people and postpone the change to 2.1. Opinions? There are going to be changes on the new features before 2.1/3.0, and it's going to be a year probably until we have a 3.0 out [though 2.0.1 or 2.1 might be quicker]. I may be being lazy, but I don't think that going with WordUtils right now would affect too many people and we don't really have enough knowledge right now to get it right for 2.0. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [math] Would code for generating IC50 curves fit here?
Al, You are correct.. Those curves are used for testing data, looking for goodness of fit when plotting a series of data points that should be on a nice curve. You are right about more general curve fitting would be the way to go. I'm hoping to not reinvent the wheel on this, but if I do, I will post it to [math] as a proposal. Eric -Original Message- From: Al Chou [mailto:[EMAIL PROTECTED] Sent: Sunday, August 17, 2003 7:49 PM To: Jakarta Commons Developers List Subject: Re: [math] Would code for generating IC50 curves fit here? --- Eric Pugh [EMAIL PROTECTED] wrote: Hi all, I am faced with a needing to generate IC50 (also called EC50) curves for a project. A) Does anyone know of any packages that do this? B) If not, would this be something of interest for Math? I don't think we have any curve-fitting code yet. I think a set of more widely used curves (a brief search on Google suggests that IC50/EC50 curves are used primarily in pharmacology, is that right?) would be higher on the priority list, if we were to put curve fitting in scope for some release (it probably wouldn't be the initial release, given the situation to date). Al = Albert Davidson Chou Get answers to Mac questions at http://www.Mac-Mgrs.org/ . __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[JELLY] JMS taglib examples?
Hi, Does anyone have any example code for the jms taglib? I tried to build it, and it failed on the JMS api. I swapped in j2ee.jar and it compiled, however I am not sure how to actually go about using the taglib. Thanks, Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Inherit and Develop
I believe that as an Apache committer, you already have Karma for the sandbox. Eric Pugh -Original Message- From: Leo Sutic [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 1:01 PM To: 'Jakarta Commons Developers List' Subject: RE: [Attributes] Inherit and Develop From: Ryan Hoegg [mailto:[EMAIL PROTECTED] Search back through the commons-dev archives. This code originally came from nanning, and there is a more recent version available. Thanks. I've checked it out. However, I think that the approach taken in the Avalon version still deserves to be explored more before a merge can be discussed. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [naming] Getting started...
well, here are two sites (plus the maven site itself) that use reactor. Just to give you ideas. http://xingu.sf.net (maven build-all) http://jakarta.apache.org/turbine/fulcrum/ (maven build) Do a checkout of whats in CVS, then from the root run the appropriate maven goal. This basically just calls the reactor and tells it to iterator over all the subprojects, building them. It deals with dependencies as well. So it will download the jars needed for each subproject, as well as build them in the order needed. There isn't any jelly at all. Also, the multiproject plugin allows you to work with multiple projects at once. So you can easily do a build on all of them. It also helps with makeing the various sub project docs glue together into a single whole. Eric -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Sunday, August 24, 2003 5:58 PM To: Jakarta Commons Developers List Subject: Re: [naming] Getting started... Eric Pugh wrote: As far as getting your two jars built, if you think that your opt jars are going to have a ton of odd/different dependencies, then using a single maven project and two subprojects works well. The sub projects share any common project elements from the top project, but function as two existing seperate projects. Thanks, Eric. That sounds like a good approach. I am still not sure exactly where the boundaries are going to be, but right now it looks like initially we will have the parent core and one or more fully dependent children. Any ideas that you have on the simplest way to set this up (without resorting to piles of jellyscript) would be much appreciated. Thanks in advance. Phil -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Sunday, August 24, 2003 2:03 AM To: Jakarta Commons Developers List Subject: [naming] Getting started... Anyone have any objections to my adding myself to STATUS and starting on the following: 1. fix a couple of package declarations to make the build work 2. find a way to get both core and opt jars generated. My current thinking is that core will include everything but the factory implementations. Feedback on this appreciated. 3. get cracking on some unit tests for the core elements 4. encapsulate the tomcat server.xml JDNI resource configuration stuff to add support for xml configuration files Thoughts? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Attributes] Commons Attributes alive again
Have you thought about putting some links to basic information on attributes on the site? I am not familiar with what attributes are, but I will definitly go and look into them! Eric -Original Message- From: Leo Sutic [mailto:[EMAIL PROTECTED] Sent: Monday, August 25, 2003 10:55 PM To: [EMAIL PROTECTED] Subject: [Attributes] Commons Attributes alive again There has been some major changes in how the attributes work and the project has a new maintainer (moi). If you're not interested in attributes then no sales pitch I can deliver will change that, but if I've managed to raise some curiosity - or at least not extinguish the curiosity you had - you're welcome to stop by http://jakarta.apache.org/commons/sandbox/attributes/ and have a look around. /LS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] Change Commons-Configuration getVector to getSet?
Hi all, I am looking at a chunk of code like this: Vector packages = Turbine.getConfiguration() .getVector(TurbineConstants.MODULE_PACKAGES); ObjectUtils.addOnce(packages, GenericLoader.getBasePackage()); from Layout Loader... And it seems to me that commons-configuration getVector should be deprecated in favor of getSet(). I can't think why you would want duplicate values, so getSet() makes more sense then getList(). Then, funky call's like the ObjectUtils.addOnce() wouldn't be needed... Opinons? And do we have to deprecate getVector() since we haven't released from sandbox yet? Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Change Commons-Configuration getVector to getSet?
Re: [configuration] Change Commons-Configuration getVector to getSet?Out of curiosity, what would be a usecase for multiple duplicate config entries that are the same? Maybe to count them or something? So, does anyone have an opinion on List? I definitly can understand why the Set wouldn't work. I suggested Set thinking order didn't matter, but you are right, it does.. I guess I just don't like the look of Vector in things... Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2003 2:45 PM To: Jakarta Commons Developers List Cc: 'Turbine Developers List' Subject: Re: [configuration] Change Commons-Configuration getVector to getSet? A Set is too restrictive i think, there are valid reasons for preserving duplicate configuration entries. I would use a Collection or better, a List when the element order matters. Emmanuel Eric Pugh wrote: Hi all, I am looking at a chunk of code like this: Vector packages = Turbine.getConfiguration() .getVector(TurbineConstants.MODULE_PACKAGES); ObjectUtils.addOnce(packages, GenericLoader.getBasePackage()); from Layout Loader... And it seems to me that commons-configuration getVector should be deprecated in favor of getSet(). I can't think why you would want duplicate values, so getSet() makes more sense then getList(). Then, funky call's like the ObjectUtils.addOnce() wouldn't be needed... Opinons? And do we have to deprecate getVector() since we haven't released from sandbox yet? Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] Missed an email about providing a good AbstractConfiguration class
Hi all, Someone sent I think to me directly an email about the difficulty they had in creating a JDBCConfiguration object because of some cruft in the BaseConfiguration class in reponse to an earlier post I made. Unfortunantly I deleted it.. Could they resend it to the list and maybe we can figure out how to make a nice easy to extend BaseConfiguration class? Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Change Commons-Configuration getVector to getSet?
Is getCollection what is wanted, or getList()? I was under the impression that a collection isn't ordered.. And then you would have to cast to a List to pass the collection into anything that expects an ordered list. Eric -Original Message- From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 10:02 AM To: [EMAIL PROTECTED] Subject: Re: [configuration] Change Commons-Configuration getVector to getSet? Emmanuel Bourg [EMAIL PROTECTED] writes: --ms080101070400050103080207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit A Set is too restrictive i think, there are valid reasons for preserving duplicate configuration entries. I would use a Collection or better, a List when the element order matters. -1 on using a set -1 on deprecating getVector() +1 on using a Collection +1 on getCollection() I have use cases, where I need repeating keys in the sequence that was put into the configuration file - sequence: list org service. keys in turbine.properties - repeating keys: list of packages to search for an action/screen in turbine.properties (here I need the exact sequence, too) So changing this API to use a set without order would damage the current Turbine code (which might be one of the main users of commons-configuration). Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon! -- AOL CD when played backwards (User Friendly - 200-10-15) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Missed an email about providing a good AbstractConfiguration class
Konstantin, I like your idea about trying to make things easier. I have been wanting to write a JDBCConfiguration class, but haven't gotten around to it. The BaseConfiguration works the way it does I think because it keeps config values in two seperate lists, correct? One in memory, and one loaded by the user? What if we instead create an AbstractConfiguration class that overrides everything. Then, when you implement your own, you just override the methods you want? Similar to the approach taken by java.util.AbstractList? If you can supply the code with unit tests, I would be very happy to review and commit it. As far as the NoSuchElementException etc.. I actually think only getObject should return null.. Or none of them maybe.. However, your idea for getProperty(String ke, Object defaultValue) would it return an Object? How would that be different then getObject()? Also, if you want to donate your JDBCConfiguration, it would be much appreciated... Eric Pugh -Original Message- From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 2:30 PM To: Jakarta Commons Developers List Subject: Re: [configuration] Missed an email about providing a good AbstractConfiguration class Hello. Here is my previous mail: --- I've tried to create my own Configuration class which loads properties from database. Because I don't want to implement all methods from Configuration interface by myself I decide to extend my class from BaseConfiguration and found that it is not easy task. All methods which retrieve properties call private method resolveContainerStore, which directly access store Map in which BaseConfiguration store properties. So if I only want to change way how properties retrieved from underlying data store I also need to override all getProperty methods (JNDIConfiguration implemented in this way). There is easy solution for this problem. We can add new protected method in BaseConfiguration which provide way to retrieve property values (and call it f.e. getPropertyDirect) and replace all occurrence of accessing store map with call to this method. What do you think about it? --- Also I have some more comments about implementation of BaseConfiguration class. May be we can discuss them too. I think that all getProperty methods should behave similar. Now methods getBoolean, getByte, getDouble, getFloat, getInt, getLong, getShort which take only key as argument (without default value) throw NoSuchElementException if there is no element associated with given key, but getString and getObject methods behave different - they simply return null. Also I think that method getProperty(String key, Object defaultValue) also can be useful. Eric Pugh wrote: Hi all, Someone sent I think to me directly an email about the difficulty they had in creating a JDBCConfiguration object because of some cruft in the BaseConfiguration class in reponse to an earlier post I made. Unfortunantly I deleted it.. Could they resend it to the list and maybe we can figure out how to make a nice easy to extend BaseConfiguration class? Eric Pugh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] AbstractConfiguration
[configuration] AbstractConfigurationKonstantin, The changes look good. And I checked through the Turbine codebase, and the changes you propose don't look like they will cause problems Could you do me a favor and submit a patch file? Not sure what editor you use, but Eclipse does a good job of creating patch files. Also, run the maven site and make sure your changes don't cause more checkstyle errors. You seem to use 2 spaces for a tab versus 4, a couple other little things as well. Although actually the BaseConfiguration needs lots of checkstyle help as it has 194 violations! Don't forget to add yourself to the contributor list in the project.xml and the @author tags;-) I agree with the testBoolean, it should return a boolean value I think as well. As far as the addProperty/addPropertyDirect, I would recommend that you add a unit test to the original code that tests it. then, apply your changes, and verify the tests work the same way. To be honest, I never had to look too closely at that part. So, if you can try and resolve some of those questions, and get the formatting in line with the standard style then I'll be happy to commit these changes. And then we can discuss your JDBC implementation which I am very curious to see... Eric -Original Message- From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED] Sent: Sunday, September 28, 2003 8:16 PM To: 'Jakarta Commons Developers List' Subject: [configuration] AbstractConfiguration Hello Eric, Pease see attached files: AbstractConfiguration.java - AbstractConfiguration class, actually this is slightly modified BaseConfiguration class (I've addes some methods and made some methods abstract) BaseConfiguration.java - BaseConfiguration class modified to extend Abstract configuration TestBaseConfiguration.java - I add one test method to test new behaviour of getString method and default configuration. All tests are passed succesfully (maven test :) . I also put some my comments in the source code. Please review them. You are talking about getObject method but there is no such method in Configuration interface. May be it will be usefull to add it? As for a JDBCConfiguration class, I actually need very specific to my project configuration implementation (using Hibernate and special logic to access database). But we can discuss this class and may be I'll implement them for commons-configuration project. In any case I think that first we should refactor existing Configuration implementations to use AbstractConfiguration (of course if you accept it). On 17:41 Fri 26 Sep, Eric Pugh wrote: Konstantin, I like your idea about trying to make things easier. I have been wanting to write a JDBCConfiguration class, but haven't gotten around to it. The BaseConfiguration works the way it does I think because it keeps config values in two seperate lists, correct? One in memory, and one loaded by the user? What if we instead create an AbstractConfiguration class that overrides everything. Then, when you implement your own, you just override the methods you want? Similar to the approach taken by java.util.AbstractList? If you can supply the code with unit tests, I would be very happy to review and commit it. As far as the NoSuchElementException etc.. I actually think only getObject should return null.. Or none of them maybe.. However, your idea for getProperty(String ke, Object defaultValue) would it return an Object? How would that be different then getObject()? Also, if you want to donate your JDBCConfiguration, it would be much appreciated... Eric Pugh
RE: [configuration] AbstractConfiguration
Re: [configuration] AbstractConfigurationI agree with the checkstyle errors being kinda bogus on some of them.. I agree with you on the unit tests.. they may be tests, but they are also great learning tools! I am patched C-C and it went in nice and clean, thanks.. I am going to test it with some of my apps for a day and then commit. I want to make sure the API change doesn't cause any problems. Then I would love to see any other refactorings you have. Maybe once we refactor to use AbstractCollection then would be time to push for a move out of sandbox... Eric Pugh -Original Message- From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 1:08 AM To: 'Jakarta Commons Developers List' Subject: Re: [configuration] AbstractConfiguration Eric, I perform code formatting of my changes to sources. See attached patch file. I also use Eclipse for the development. Unfortunately I am behind firewall, so I can't access cvs from eclipse (because for some reason it refuses to work with socks5 proxy server), so I create patch file using cvs diff command. Then I try to apply this patch to the unmodified sources using Eclipse and everything looks fine. As for checkstyle I think that It report a lot of useless warning. F.e. about final parameters. May be we can modify checkstyle configuration to turn them off or just ignore them. Now AbstractConfiguration has 175 warnings and BaseConfiguration - 21. I modify testBoolean to return Boolean instead of String. As for additional tests it seems to me that existing tests cover addProperty/addPropertyDirect functionality. Actually this tests were very helpful for me when I perform refactoring. Also I think that later I can refactor other Configuration classes to extend AbstractConfiguration. On 17:28 Mon 29 Sep , Eric Pugh wrote: [configuration] AbstractConfigurationKonstantin, The changes look good. And I checked through the Turbine codebase, and the changes you propose don't look like they will cause problems Could you do me a favor and submit a patch file? Not sure what editor you use, but Eclipse does a good job of creating patch files. Also, run the maven site and make sure your changes don't cause more checkstyle errors. You seem to use 2 spaces for a tab versus 4, a couple other little things as well. Although actually the BaseConfiguration needs lots of checkstyle help as it has 194 violations! Don't forget to add yourself to the contributor list in the project.xml and the @author tags;-) I agree with the testBoolean, it should return a boolean value I think as well. As far as the addProperty/addPropertyDirect, I would recommend that you add a unit test to the original code that tests it. then, apply your changes, and verify the tests work the same way. To be honest, I never had to look too closely at that part. So, if you can try and resolve some of those questions, and get the formatting in line with the standard style then I'll be happy to commit these changes. And then we can discuss your JDBC implementation which I am very curious to see... Eric -Original Message- From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED] Sent: Sunday, September 28, 2003 8:16 PM To: 'Jakarta Commons Developers List' Subject: [configuration] AbstractConfiguration Hello Eric, Pease see attached files: AbstractConfiguration.java - AbstractConfiguration class, actually this is slightly modified BaseConfiguration class (I've addes some methods and made some methods abstract) BaseConfiguration.java - BaseConfiguration class modified to extend Abstract configuration TestBaseConfiguration.java - I add one test method to test new behaviour of getString method and default configuration. All tests are passed succesfully (maven test :) . I also put some my comments in the source code. Please review them. You are talking about getObject method but there is no such method in Configuration interface. May be it will be usefull to add it? As for a JDBCConfiguration class, I actually need very specific to my project configuration implementation (using Hibernate and special logic to access database). But we can discuss this class and may be I'll implement them for commons-configuration project. In any case I think that first we should refactor existing Configuration implementations to use AbstractConfiguration (of course if you accept it). On 17:41 Fri 26 Sep, Eric Pugh wrote: Konstantin, I like your idea about trying to make things easier. I have been wanting to write a JDBCConfiguration class, but haven't gotten around to it. The BaseConfiguration works the way it does I
RE: [configuration] AbstractConfiguration
Re: [configuration] AbstractConfigurationKonstantin, I have applied your patchs.. Can you do a fresh CO and just verify I applied everything properly. The unit tests all run cleanly for me. Can't wait to see your JDBC configuration! Eric -Original Message- From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 1:08 AM To: 'Jakarta Commons Developers List' Subject: Re: [configuration] AbstractConfiguration Eric, I perform code formatting of my changes to sources. See attached patch file. I also use Eclipse for the development. Unfortunately I am behind firewall, so I can't access cvs from eclipse (because for some reason it refuses to work with socks5 proxy server), so I create patch file using cvs diff command. Then I try to apply this patch to the unmodified sources using Eclipse and everything looks fine. As for checkstyle I think that It report a lot of useless warning. F.e. about final parameters. May be we can modify checkstyle configuration to turn them off or just ignore them. Now AbstractConfiguration has 175 warnings and BaseConfiguration - 21. I modify testBoolean to return Boolean instead of String. As for additional tests it seems to me that existing tests cover addProperty/addPropertyDirect functionality. Actually this tests were very helpful for me when I perform refactoring. Also I think that later I can refactor other Configuration classes to extend AbstractConfiguration. On 17:28 Mon 29 Sep , Eric Pugh wrote: [configuration] AbstractConfigurationKonstantin, The changes look good. And I checked through the Turbine codebase, and the changes you propose don't look like they will cause problems Could you do me a favor and submit a patch file? Not sure what editor you use, but Eclipse does a good job of creating patch files. Also, run the maven site and make sure your changes don't cause more checkstyle errors. You seem to use 2 spaces for a tab versus 4, a couple other little things as well. Although actually the BaseConfiguration needs lots of checkstyle help as it has 194 violations! Don't forget to add yourself to the contributor list in the project.xml and the @author tags;-) I agree with the testBoolean, it should return a boolean value I think as well. As far as the addProperty/addPropertyDirect, I would recommend that you add a unit test to the original code that tests it. then, apply your changes, and verify the tests work the same way. To be honest, I never had to look too closely at that part. So, if you can try and resolve some of those questions, and get the formatting in line with the standard style then I'll be happy to commit these changes. And then we can discuss your JDBC implementation which I am very curious to see... Eric -Original Message- From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED] Sent: Sunday, September 28, 2003 8:16 PM To: 'Jakarta Commons Developers List' Subject: [configuration] AbstractConfiguration Hello Eric, Pease see attached files: AbstractConfiguration.java - AbstractConfiguration class, actually this is slightly modified BaseConfiguration class (I've addes some methods and made some methods abstract) BaseConfiguration.java - BaseConfiguration class modified to extend Abstract configuration TestBaseConfiguration.java - I add one test method to test new behaviour of getString method and default configuration. All tests are passed succesfully (maven test :) . I also put some my comments in the source code. Please review them. You are talking about getObject method but there is no such method in Configuration interface. May be it will be usefull to add it? As for a JDBCConfiguration class, I actually need very specific to my project configuration implementation (using Hibernate and special logic to access database). But we can discuss this class and may be I'll implement them for commons-configuration project. In any case I think that first we should refactor existing Configuration implementations to use AbstractConfiguration (of course if you accept it). On 17:41 Fri 26 Sep, Eric Pugh wrote: Konstantin, I like your idea about trying to make things easier. I have been wanting to write a JDBCConfiguration class, but haven't gotten around to it. The BaseConfiguration works the way it does I think because it keeps config values in two seperate lists, correct? One in memory, and one loaded by the user? What if we instead create an AbstractConfiguration class that overrides everything. Then, when you implement your own, you just override the methods you want? Similar
RE: [configuration]HierarchicalConfiguration
Oliver, So, if I understand properly, the reason is so that we refactor out the code so that you don't have to do a cut'n'paste job from the AbstractConfiguration to your new subclass.. Seems reasonable enough.. Why don't you submit a patch with your next chunk of code then? Oh, and the attachements came through okay for me! Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration][PATCH]addProperty
Oliver, I have applied your patch. Do you want to check things out? I also added in some more maven reports. I thought our coverage with unit tests was going to be steller, but according to JCoverage, we only have 59% coverage of the code base. At any rate, let me know how things go.. I am updating the website as I write this... Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 1:58 PM To: Jakarta Commons Developer List; [EMAIL PROTECTED] Subject: [configuration][PATCH]addProperty Eric, I have created the patch for refactoring the addProperty() method. AbstractConfiguration.addProperty() now only handles collection and string properties with multiple values and then delegates to the abstract addPropertyDirect() method. The stuff with the containers was moved to BaseConfiguration.addPropertyDirect(). The unit tests run fine. There is a little thing more I changed: I made the nested Container class in AbstractConfiguration static. The reason is that I have a static nested class HierarchicalProperties.Node that needs to create instances of Container. This is impossible with Container being nonstatic unless I make the Node class nonstatic, too; but I don't like that because it would make usage of this class more complicated for clients of HierarchicalProperties (normally clients need not access this class directly, but there might be cases where it could make sense). Was there any specific reason for making Container nonstatic? Regards Oli - Original Message - From: Eric Pugh [EMAIL PROTECTED] To: 'Oliver Heger' [EMAIL PROTECTED]; 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Tuesday, October 14, 2003 10:40 AM Subject: RE: [configuration]HierarchicalConfiguration Oliver, So, if I understand properly, the reason is so that we refactor out the code so that you don't have to do a cut'n'paste job from the AbstractConfiguration to your new subclass.. Seems reasonable enough.. Why don't you submit a patch with your next chunk of code then? Oh, and the attachements came through okay for me! Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration][PATCH]HierarchicalConfiguration
Oliver, I wanted to look at your code, but I don't seem to have it as an attachement.. Could you resend it or open a bug and attach it? Thanks.. ERic -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Monday, October 20, 2003 3:02 PM To: Jakarta Commons Developer List Subject: [configuration][PATCH]HierarchicalConfiguration Hi, I have now created a patch with my first implementation of HierarchicalConfiguration and related classes. Here are some remarks to the new classes: HierarchicalConfiguration This is a base class for configuration classes that use a hierarchical schema to store their properties. The class is fully functional and provides meaningful implementations for all abstract methods defined in AbstractConfiguration. HierarchicalDOM4JConfiguration A sub class of HierarchicalConfiguration that allows to parse XML documents using DOM4J. This class does the same as DOM4JConfiguration, but keeps the structure of the parsed documents. Saving of configuration properties is not implemented yet. HierarchicalConfigurationXMLReader This class is a faked SAX parser that operates on HierarchicalConfiguration objects. It processes a configuration object and generates corresponding SAX events that can be caught and evaluated by a ContentHandler implementation. The associated unit test shows how this class can be used to construct a DOM4J document from a configuration object. With this class it should also be possible to feed configuration objects into a Digester. ConfigurationKey This class is used internaly to construct keys and iterate over the single parts a key consists of. I made it public because it may be useful for clients as well. The class hides the concrete syntax of a property key, so instead of dealing with strings, property delimiters, index or attribute markers a client only needs to call methods of this class. There are unit tests for each of these classes; according to the reports they have a quite high coverage rate ;-) Please send me your critics, ideas and suggestions and your thoughts how (and if) to integrate this stuff with the existing code. I think the concept of transforming a Configuration object to XML by using a simplified SAX parser could be useful for non hierarchical configuration objects, too. So it would be nice to have a corresponding implementation. Then there is another idea that came me when I wrote HierarchicalDOM4JConfiguration: How about separating the code for writing configuration objects from the configuration classes? There could be different ConfigurationOutputter classes for different formats (properties, XML, ...). This would have a couple of advantages, e.g. it would allow to save configuration data in another format than it was loaded from. What do you mean? Oli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration]Enhanced patch and some thoughts
Wow! Lots of good feedback.. Let me start with the ConfigurationFactory. Okay.. CF sucks.. I discovered the problem with the files myself recently. What it really should work with is an InputStream or Url.. , since the xml file that digester uses could be in a jar. So, I totally agree with you on that. Okay, second bit, whether a configfactory returns the merged set or properties, or overrides.. I guess there are two seperate usecases. The first usecase, which is what it implements now is that you have a standard set of properties, so you include them in a jar file and use them. But, you want to give the user/deployer the ability to override them, so you put either another properties file or jndi or what not ahead of the standard. And voila! You can override all your properties. Second use case.. I want to collect all the properties from multiple locations and then merge them into one super Configuration object. This would allow me to dynamically add to what is already setup. I think that the ConfigurationFactory should deal with both cases.. I see something like: override list of locations to look for properties that override the onces that come after it. Similar to what is there now. /override additional list of locations to add all the properties into one uber Configuration object. /additonal This would then allow me the ability to do both usecases. I would love to see some patches for ConfigurationFactory, that could support this. As an aside, I wrote an Avalon wrapper for the ConfigurationFactory based Configuration objects: http://jakarta.apache.org/turbine/fulcrum/fulcrum-configuration/index.html I made it part of fulcrum as I didn't want to bloat c-c with a ton of extra dependencies for something that is just a wrapper. Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Thursday, October 30, 2003 7:15 PM To: Jakarta Commons Developer List Subject: [configuration]Enhanced patch and some thoughts Hi, I have added an enhanced version of the HierarchicalConfiguration patch to bugzilla (because of its size): Bug 24262. In this patch there is also an XMLReader implementation that operates on a BaseConfiguration instance rather than HierarchicalConfiguration. This makes it possible to perform XML processing on all kind of Confiugration objects and e.g. pass them to a Digester. The new parsing functionality for (Base)Configuration objects is implemented in the BaseConfigurationXMLReader class. There is also a new base class ConfigurationXMLReader that provides common functionality of the specific XMLReader classes. An additional class HierarchicalConfigurationConverter is used by BaseConfigurationXMLReader and provides means to iterate over the keys defined in a Configuration and treat them in a structured manner. I am expecting your feedback... Finally some thoughts about ConfigurationFactory: This class and some of the Configuration classes that can be created by this factory load their data from files. I think that will cause problems for applications that are deloyed in jars (and that have their configuration also stored in these archives), e.g. web applications. Wouldn't it be better if the affected classes used URLs instead? Then it would be possible to determine a URL to a configuration file (even if it is located in a jar) in a simmilar way as ClassPropertiesConfiguration work and let the classes read their data from that URL. And still another point: I am not very happy with ConfigurationFactory in the way that it not really constructs a union of the properties it reads. For instance if two XML files are read that contain similar elements you cannot obtain the data in the second file because the search for properties stops when values in the first file are found. I would prefer to get all properties. The BasePropertiesConfiguration class provides a way of including other files into a property file. I think it would be very useful to implement this feature for other configuration classes, too. Maybe a generic approach could be found to allow includes of arbirary files in all configuration classes (e.g. include .properties files in XML files and vice versa, XML files in XML files etc.). With this approach a developer could access all properties in his application through a single configuration object; this is similar to a Unix file system which allows to mount different disks into one logic directory tree. As a use case consider web frameworks like struts. Those frameworks typically define lots of configuration information in a monolithic file (struts-config.xml), which can be a bottle neck in large projects with lots of developers. With the generic include facility it would be very simple to split these large files into arbitrary small portions and link them together. For the code that processes the configuration these portions occur as a single logic file.
RE: [Math] common-math and bloated 3rd party libraries
This backlash against multiple commons jars is happening in a lot of places.
However, I think it is a bit shortsighted. If you are in a non server
environment, I understand the problem, but in a server environment with lots
of harddrive space, I don't. Additionally, since in a server app you are
likely to need all thoses dependencies any way. I think almost every app I
work on has commons-lang, commons-loggin, and commons-collections included.
And then depending on what else, commons-discovery and commons-beanutils
show up all the time!
By removing the dependency on commons-lang etc you also remove the ability
to leverage their code when something better comes out. You end up copying
and pasting more and more out of all these projects in math. And don't get
the benefit of the testing, bugfixing etc they go through..
Maybe a better approach is to try and figure out why things like
commons-collections are so big, and should they be shrunk down or partioned?
Eric
-Original Message-
From: Kasper Nielsen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 2:55 PM
To: [EMAIL PROTECTED]
Subject: [Math] common-math and bloated 3rd party libraries
Hi gang,
I love commons-math, one problem though!
lets take a look at the dependecies
common-lang: 189 kb
commons-beanutils: 116 kb
commons-collections-SNAPSHOT.jar 463
commons-discovery 70 kb
commons-logging-1.0.3.jar 31 kb kb
Thats 850 kb!!! of 3rd party libraries that are only used in
a few places.
So to calculate a simple mean I need to include around 6 jars
(including
commons-math)
So lets get the list down a bit.
* Commons-lang
Getting rid of Commons-lang is pretty easy since it is only
used in one
place: MathException
Solution : Let MathException extend Exception instead of
NestableException. There aren't really anywhere we use the ability to
nest Exceptions inside other Exceptions in commons-math.
* Commons-collections
Getting rid of commons-collections is also pretty easy
Solution: Getting a copy of HashBag (and the Testcase) and put into
math.util (no need to copy the interface)
now we got rid of ~ 650 kb in around 2 minutes, 3 jars left,
this is a
fun game!!
* Commons-Beanutils
Okay the transformers are nice but come on how many people
are going to
use them?
Solution: put them into a new small library:
commons-math-transformers.jar
** Commons-Discovery
KISS keep it simple stupid, who on earth is going to provide
there own
UnivariateRealSolverFactory??
and for those few people that need it... I think they are
smart enough
to do figure it out themself.
Solution: remove it (or do something like we do for commons-logging)
** Commons-logging
Lastly commons-logging...
I would think returning NaN is enough, but okay if people
insist we can
do something like (pseudo code)
public class logutil
static Method logMethod;
static {
try
{
Class clazz = Class.forName(commons.LogFactory);
logMethod = clazz.getMethod(error);
}
catch (ClassNotFoundException e) {}
}
public static logError(String msg, Throwable t)
{
if (logMethod!=null)
{
logMethod.invoke(msg + t);
}
}
}
and whoops we have now gotten rid of all the libraries, and
we have easy
embeddable little commons math jar.
regards
Kasper
Kasper Nielsen
kaspern at apache.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration]Constructing a union of properties
I am traveling till monday, but I will check it out then.. Looks from first blush pretty great! -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Thursday, November 06, 2003 5:43 PM To: Jakarta Commons Developer List Subject: [configuration]Constructing a union of properties Hi again, the patch mentioned in my last posting also enhances ConfigurationFactory to support a union of some configurations defined in the XML definition file. As was suggested this works in the following way: - XML elements defined in a override section or standalone work as before. They override properties defined in other configurations. - XML elements in a additional section collect properties in a single configuration. They can be used to construct a union. The basic idea behind this is quite simple: All configurations to be loaded in a additional section are added to a HierarchicalConfiguration object. The corresponding XML elements also support a new at attribute, which allows to specify a property key under which all properties are stored. This HierarchicalConfiguration is then added as last element to the CompositeConfiguration returned by ConfigurationFactory. So the logic of CompositeConfiguration needn't be changed: because configurations defined in an override section are added first to the CompositeConfiguration their properties are found first and thus override others; the union configuration is the last in this chain and is searched only if the requested key was not found before. The existing unit tests run without changes; XML definition files without any override or additional section are treated as before. A new method in the unit test class tests the union capabilities. It loads a definition file which includes two HierarchicalDOM4JConfigurations and one PropertiesConfiguration in the additional section and one PropertiesConfiguration in the override section. The first dom4j element loads the database table definition I have often used as example. The second adds another table to it. The unit test checks now if the additional table can be found. The properties file in the override section defines some properties that are also defined in the other properties file. The test ensures that the correct (overriden) values are returned. I think this should cover all of the new features. There was one strange thing that occurred to me: According to the examples in the documentation the elements that can be used in a definition file for ConfigurationFactory all have a className attribute that defines the configuration class to be used. These attributes have never been evaluated! (I was wondering about their existence anyway because the element name itself provides information about the class to use.) I have changed this so that now the attribute's value is taken into account; first to be consistent with the documentation and second because this was the easiest way to add support for my HierarchicalDOM4JConfiguration class. Now I am expecting your comments! Oli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration]More docs
Oliver, I would say that your English is better then 90% of the english speaking world, so don't feel hesitant writing docs. I recommend using the xdoc format as that is native to Maven, and I would add maybe some howto docs.. Maybe a: howto-configurationfactory.xml, howto-hierarchical.xml etc.. The createXMLReader is an interesting idea.. However, I think that maybe instead it would be better to have a ConfigurationXMLDocument that took in a Configuration object. I am somewhat hesitant to add more methods to the Configuration interface that arne't really directly related to retrieving configuration values. Especially if it releies on each concrete class implementing it, as that starts to raise the bar more and more for adding the underlying concrete implmentations... Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 4:32 PM To: Jakarta Commons Developer List Subject: [configuration]More docs Eric, I am willing to produce some more docs about my changes. What is the preferred way to do that? Changing the overview page? Of course a native speaker should review my results ;-) Some other point: The last patch includes the feature that each configuration object can be transformed in a XML document (or at least allows XML-like processing by firing SAXEvents) by using one of the ConfigurationXMLReader classes. This is certainly something that needs to be documented in some more detail, too. Do you think it would make sense to add a createXMLReader() method (or similar) to the Configuration interface? This method would be implemented in the concrete classes by returning the proper implementation of ConfigurationXMLReader. Then this feature could be accessed directly through the interface. Oli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] order of compositeconfiguration items
I can see using insertConfigurationAt().. I really see the semantics of CompositeConfiguration as being close to List.. Since under the covers a CompositeConfiguration is just a list.. A patch (plus tests) would be welcome... Eric -Original Message- From: Gerry Duprey [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 11, 2003 5:40 PM To: [EMAIL PROTECTED] Subject: [configuration] order of compositeconfiguration items Howdy, In addition to being able to addConfiguration(), has there been any thought to an insertConfigurationAt(Configuration, x)? I ask because I'm building up a composite configuration from several resources and the order that I build them is from lowest to highest priority (when resolving duplicate names). As things are now though, addConfiguration() treats the first configuration as the highest priority. Based on how I need to load things, this make life difficult (I have to cache all parts of the composite configuration into a Vector until done, then run through the vector backwards to install them). Certainly I can work around it, but a bit more flexibility in the order configurations are added/searched in the composite would be of some benefit. Thoughts? Gerry -- Gerry Duprey SchoolsOPEN, LLC 123 North Ashley, Suite 120 Ann Arbor, MI 48104 Phone (877) 483-1944 Ext. 401 Fax (734) 661-0819 Visit us Online at www.Schools-OPEN.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration]More docs
Wow...
I can't wait to read through your patch tomarrow.. Only have a minute, so I
thought I would address the XMLReaderProvider
Maybe it is just me, but something I don't like about java and interfaces is
that sometimes I get so lost in all the interfaces.. Everything implements
an interface and behave's differently depending on which interface is being
used etc..
I think you are 100% right, if we had 3 cases.. But with two cases, I feel
like since we still have an if statement, we aren't gaining much. If and
When we get the if/elseif/else structure, then I think that would be great..
Part of me wonders why it doesn't look like this:
return new ((XMLReaderProvider) config).createXMLReader();,
why the BaseConfigurationXMLReader is differnet. Why not have
BaseConfigurationXMLReader implement createXMLReader as well?
Eric
-Original Message-
From: Oliver Heger [mailto:[EMAIL PROTECTED]
Sent: Friday, November 14, 2003 8:12 PM
To: Jakarta Commons Developers List
Subject: Re: [configuration]More docs
Hi,
I followed Yoav's suggestion and created an example page with usage
examples for some of the features of ConfigurationFactory. I think if
another structure is preferred, the texts can easy be copied
and pasted.
The patch is in bugzilla with the bug id 24716.
Eric, I see your point with keeping the Configuration interface as
simple as it can be. A ConfigurationXMLDocument class is
surely a good
idea; it could also provide some other functionality like creating a
Document (dom4j or w3c), storing a Configuration object as
XML file, or
utility methods for Digester interaction.
There is only one thing I feel uneasy with: The new class
would have to
instantiate a specific ConfigurationXMLReader instance
depending on the
class of the actual Configuration object (there is one specific class
for HierarchicalConfiguration and one that handles the other
classes).
Code like
if(config instanceof HierarchicalConfiguration)
{
return new HierarchicalConfigurationXMLReader(config);
}
else
{
return new BaseConfigurationXMLReader(config);
}
would make every refactoring guru mad because such a problems
scream for
polymorphism. Would it be a solution to introduce a new interface,
something like XMLReaderProvider, with only a
createXMLReader() method?
Then we could have code like the following
if(config instanceof XMLReaderProvider)
{
return new ((XMLReaderProvider) config).createXMLReader();
}
else
{
return new BaseConfigurationXMLReader(config);
}
This is maybe a bit better. The base configuration classes would
implement this interface in a proper way. What do you think?
Oli
Shapira, Yoav wrote:
Howdy,
Suggestion: add an Examples page (xdocs/examples.xml) to the
nagivation
bar (xdocs/navigation.xml). Write some examples there, starting with
very basic ones that seem trivial to you. Maven will take care of
publishing it. This is consistent with many other commons
projects. If
you need any help with the mechanical parts (writing xdocs,
using maven
to publish the site, etc.) I'll be glad to help. And as Senor Pugh
said, don't worry about your English ;) Thanks,
Yoav Shapira
Millennium ChemInformatics
-Original Message-
From: Eric Pugh [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 10:50 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [configuration]More docs
Oliver,
I would say that your English is better then 90% of the english
speaking
world, so don't feel hesitant writing docs. I recommend
using the xdoc
format as that is native to Maven, and I would add maybe
some howto
docs..
Maybe a: howto-configurationfactory.xml,
howto-hierarchical.xml etc..
The createXMLReader is an interesting idea.. However, I think that
maybe
instead it would be better to have a
ConfigurationXMLDocument that took
in
a
Configuration object. I am somewhat hesitant to add more methods to
the
Configuration interface that arne't really directly related to
retrieving
configuration values. Especially if it releies on each
concrete class
implementing it, as that starts to raise the bar more and more for
adding
the underlying concrete implmentations...
Eric
-Original Message-
From: Oliver Heger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 11, 2003 4:32 PM
To: Jakarta Commons Developer List
Subject: [configuration]More docs
Eric,
I am willing to produce some more docs about my changes.
What is the
preferred way to do that? Changing the overview page? Of
course a native
speaker should review my results ;-)
Some other point: The last patch includes the feature that each
configuration object can be transformed in a XML document (or
at least
allows XML-like processing by firing SAXEvents) by using one of the
ConfigurationXMLReader
[Configuration] Formatting of dom4j digester tag
Oliver, I was looking through the docs, and the /examples.html was a great way to go! Something that kinda jumped out at me, having really looked at the examples is the case where we want to load up a HierarchicalDOM4JConfiguration: dom4j className=org.apache.commons.configuration.HierarchicalDOM4JConfiguration fileName=tables.xml/ It looks a little weird to have this optional attribute className. I am thinking that we should change instead to: dom4j fileName=gui.xml/ !--normal dom4j -- hierarchicalDom4j fileName=gui.xml/ !--heriarchical dom4j -- or hierarchical fileName=gui.xml/ !--heriarchical dom4j -- I am thinking that this might be a little cleaner.. do you foresee ever havign multiple classes providing the dom4j implementation? The className makes sense if we had 3 or more, but with just two, where the attribute is optional, it seems a little confusing.. any opinons? I am hoping to work towards getting the polish done on commons-configuration and then push for a move out of commons sandbox... Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Formatting of dom4j digester tag
Humm... I thinking that either hierarchical or hierarchicalDom4j.. I don't have a problem with long names, I think long and explicit is better then short and confusing! I lean towards removing the attribute from ConfigurationFactory to keep things as clean as possible. I think then that we should maybe lay out a road map of things to get done prior to getting out of sandbox: 1) Resolve the node name for hierarchical in dom4j. 2) Finish updating the docs. 3) Maybe get a jdbc configuration? I would love a JDBCConfiguration object, I haven't quite taken the time to put one together, but I recall someone mentioning they had one.. And then get the 1.0 release done as part of moving out of the sandbox... Are you by chance going to be attending the javapolis conference? (http://www.bejug.org/bejugPortal/appmanager/BeJUG/JP03) Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Sunday, November 16, 2003 7:06 PM To: Jakarta Commons Developers List Subject: Re: [Configuration] Formatting of dom4j digester tag Eric, I think you are right with that className attribute. I have only restored support for it (for in the actual implementation it was not even evaluated) because the examples in the overview.html all had a className attribute. And at this time this was the easiest possibility to include HierarchicalDOM4JConfiguration as a configuration source for ConfigurationFactory. From a user's point of view it is surely cleaner to have a separate XML element. Should I change the code in ConfigurationFactory to completely get rid off this attribute (in theory it can be set for all other elements as well, but this doesn't make much sense)? Which element name do you prefer? hierarchical, hierarchicalDom4j, hieraDom4j, ...? (I have always trouble with comming up with a meaningful name). Hey, I really would like to see commons configuration comming out of the sandbox! Oli Eric Pugh wrote: Oliver, I was looking through the docs, and the /examples.html was a great way to go! Something that kinda jumped out at me, having really looked at the examples is the case where we want to load up a HierarchicalDOM4JConfiguration: dom4j className=org.apache.commons.configuration.HierarchicalDOM4J Configuration fileName=tables.xml/ It looks a little weird to have this optional attribute className. I am thinking that we should change instead to: dom4j fileName=gui.xml/ !--normal dom4j -- hierarchicalDom4j fileName=gui.xml/ !--heriarchical dom4j -- or hierarchical fileName=gui.xml/ !--heriarchical dom4j -- I am thinking that this might be a little cleaner.. do you foresee ever havign multiple classes providing the dom4j implementation? The className makes sense if we had 3 or more, but with just two, where the attribute is optional, it seems a little confusing.. any opinons? I am hoping to work towards getting the polish done on commons-configuration and then push for a move out of commons sandbox... Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] Formatting of dom4j digester tag
Um.. I would suggest just removing the code.. My fear when it comes to undocumented features is that the next committer won't have any idea what is going on, and will accidentally break something, especially if we don't have a unit test backing it up! Yeah, the question about a singleton is a good one.. There is so much opinon back and forth about the value of singletons.. I like them b/c they are easy.. I hate them because inevitably someone want's two configurations etc.. The singleton pattern can be implemented by many different containers if you start going the COP/IOC way.. Basically, I guess if someone wants to provide a good singleton implementation that has unit testing, then I'd be happy to have it. If you are deep and down working on ConfigurationXMLDocument, then would you like to wait for that before looking to move out of sandbox? Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 11:14 AM To: Jakarta Commons Developers List Subject: Re: [Configuration] Formatting of dom4j digester tag Okay, then I will change the element name to hierarchicalDom4j, remove the support for the className attribute (well I'm not sure if I should really remove this or leave it as undocumented feature; it's about a view lines in ConfigurationFactory that won't hurt) and update the examples and the overview page. At the moment I am also working on the ConfigurationXMLDocument class that allows XML-like processing on Configuration objects including interaction with Digester. I will add a section about this to the examples page, too. Concerning the road map: Is there still interest for the configuration singleton? I think this would be a handy feature. The ConfigurationService class you have written for Turbine would do the major part, wouldn't it? Oh, and I unfortunately don't visit the javapolis conference. Oli Eric Pugh wrote: Humm... I thinking that either hierarchical or hierarchicalDom4j.. I don't have a problem with long names, I think long and explicit is better then short and confusing! I lean towards removing the attribute from ConfigurationFactory to keep things as clean as possible. I think then that we should maybe lay out a road map of things to get done prior to getting out of sandbox: 1) Resolve the node name for hierarchical in dom4j. 2) Finish updating the docs. 3) Maybe get a jdbc configuration? I would love a JDBCConfiguration object, I haven't quite taken the time to put one together, but I recall someone mentioning they had one.. And then get the 1.0 release done as part of moving out of the sandbox... Are you by chance going to be attending the javapolis conference? (http://www.bejug.org/bejugPortal/appmanager/BeJUG/JP03) Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Loading and Saving
I think it boils down to is anyone doing the work.. If Emmanuel is hot on getting this done in the very near future, then lets add it. Emmanuel, if you view this as a 2 week project to properly get done, then lets leave it for 1.0.1. There is no reason that 1.0.1 can't come out 2 or 3 weeks after 1.0. Heck, there isn't any reason why 1.1 can't come out 2 or 3 weeks after 1.0! Which is I think what we should name the next version that doesn't have vector and throws Exceptions on missing values.. Personally, I want the switch to be able to throws Exceptions or return nulls, and then dump the nulls in the next version. I wouldn't worry too much about backwards compatibilty. We're at the 1.0 stage, and don't have that many users.. I think, as long as we document them, that there are backwards compatiblities, then they are okay. Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 08, 2004 12:45 PM To: Jakarta Commons Developers List Subject: Re: [configuration] Loading and Saving Henning P. Schmiedehausen wrote: I like all of this. However, even more I'd like to get 1.0 finally out of the door. I'm really willing to tell our users, that they can rely only on the non-deprecated method signatures in the o.a.c.c.Configuration interface and that everything else can and will be changed post-1.0, but for the moment, getting this stuff released is my #1 prio. Releasing the 1.0 final is also my top priority, while I agree to sacrifice features for this (like automatic reloading, support for additional types more configuration formats) I don't want to sacrifice quality (API consistency, testing documentation), that's why I call for these changes now. I don't want to be tied to backward compatibility concerns once 1.0 is released because we didn't take the time to address these inconsistencies. I also like the proposal to make the various implementations pluggable. A small application that needs only PropertiesConfiguration should not be punished to drag all of the XML libraries around. Splitting c-c into a base package with maybe only commons-lang and commons-collections as dependencies and one or more optional packages would be a good thing. I haven't tested but I think it's already the case, you can use PropertiesConfiguration without including the XML libraries. However, we are already at rc1 state. Pulling the rc1 back would mean, that at least I would go ahead an do the Turbine 2.3.1 release on a snapshot which would IMHO a sad thing. Well, the merit of the rc1 is to provide and temporary official release that can sweep away the various unofficial snapshots and bring more testing and feedback on the project. But I don't consider it good enough in this state to become a final release. So please. Let's find an agreement on the getxxx semantics, do one more RC and the CfV the release. I don't mind if we revert to a null-when-missing semantic now and add a switch later for exception-when-missing. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Loading and Saving
That page is pretty cool! Any idea how to get the list of who the dependencies are on, both direct and indirect? I would rather go with a property that controls the behavior of throwing exceptions versus null. Especially if the plan is to change in the next version to always throwing Exceptions.. I can see a bit of confusion if we double the number of methods.. Do I use getBoolean or fetchBoolean? And getBoolean/getBooleanThrowExceptionIfMissing seems silly as well! And, I definitly agree w/ Henning on the no promises beyond Configuration interface. In fact, maybe we want to add a note on the homepage about it... I think it all boils down to, lets see who does what, and that is the path we take. How about we cut RC2 late next week? That gives a deadline for the various ideas floating about? I'll volunteer to do it next Thursday if that sounds good. That way we can look at a 1.0 in 2 weeks, and then Henning can cut turbine-2.3.1 and I can think about cutting turbine-2.4-M2. Eric -Original Message- From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 08, 2004 4:43 PM To: [EMAIL PROTECTED] Subject: Re: [configuration] Loading and Saving Eric Pugh [EMAIL PROTECTED] writes: nulls, and then dump the nulls in the next version. I wouldn't worry too much about backwards compatibilty. We're at the 1.0 stage, and don't have that many users.. I think, as long as we document them, that there are Don't be too humble. Apache Gump tells us that commons-configuration has seven direct and 71 (!) indirect dependees on commons-configuration: http://brutus.apache.org/gump/public/gump_stats/project_dependees.html So we should try to not upset or the users of 71 projects come knocking on our mailboxes. (BTW: commons-lang has 28/235 and commons-collections 73/257. So having a third the user base of commons lang is IMHO already quite some distribution). We simply should choose not to put all of our API in stone. I think we should be willing to guarantee everything that is in the Configuration interface for a while and the C'tors of the implementations. Apart from this: All bets are off. :-) For the matter of the switch: Emmanuel: How do you plan to implement this? Additional C'tors taking a boolean? Or a boolean setter? Personally, I'd still prefer the two methods for everyone approach that Hibernate does. getBoolean(String property) returns null if property does not exist and fetchBoolean(String propety) throws an Exception. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] Do we need to support Ant based builds?
Okay.. well, it sounds like the consensus is that Ant support is a Good Idea, so we'll keep it.. I'll play around with adding the Ant generation task to maybe our maven site goal so that we keep it up to date.. Mostly it's just an issue of keeping the script up to date with the Maven build.. Dependencies seem to get out of sync quite easily! Currently, the build is quite simple, and the maven ant plugin works fine for everything, so we'll keep it up to date! Thanks for all the feedback! Eric -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 11:17 AM To: [EMAIL PROTECTED] Subject: Re: [general] Do we need to support Ant based builds? On Tue, 21 Sep 2004, Dion Gillard [EMAIL PROTECTED] wrote: C'mon, that one doesn't even run tests! 8-) At least it has a bunch of dependencies, that's what non-trivial meant in my mail. http://brutus.apache.org/gump/public/db-commons-sandbox/db-common s-grafolia/gump_work/build_db-commons-sandbox_db-commons-grafolia.html does run unit tests. Hmm, in http://brutus.apache.org/gump/public/excalibur/excalibur-thread-i mpl/gump_work/build_excalibur_excalibur-thread-impl.html the unit tests fail to compile even though the project lists a dependency on JUnit, while Grafolia (which works) does not declare such a dependency. We really need help from people who understand Maven better than I do to take the final steps. It seems we are pretty close. Want to come over to [EMAIL PROTECTED], Dion? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Refactoring for file based configurations
+1 I like everything. I agree, last change pre 1.0! If I can't check in my FilterConfiguration, you can't check in your some cool feature :-). My only question, and maybe this is a just a nitpick.. Why move this locate method into ConfigurationUtils? Do you foresee it used by lots of different Configurations beyond those extending abstractfileConfiguration? I could see it just living in AbstractFileConfiguration... On the other hand, if it really is a nice generice find me a file method, then I can see it being quite useful, and, post 1.0, you may want to see if the FileUtils could use this: http://jakarta.apache.org/commons/io/apidocs/org/apache/commons/io/FileUtils .html At any rate, let's commit the darn thing and move onto the next RC! Eric Pugh -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 11:09 AM To: Jakarta Commons Developers List Subject: Re: [configuration] Refactoring for file based configurations Henning P. Schmiedehausen wrote: Don't think that I will have time to dig into this deeper but your changes all sound logical. On what code is this based? Did you fork off some point in the past or is this from HEAD? I didn't fork but I stopped updating my local copy about 3 weeks ago. As long as they pass the unit tests, I'd say: Go ahead. Do you plan this for 1.0 or post-1.0? I plan this for 1.0, this is the last fundamental change I'd like to operate before the final release. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Refactoring for file based configurations
If you have it all ready, lets get the refactoring checked in! Technically RC should be just to verify fixes and last minute stuff.. not a milestone on the way to 1.0! -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 7:35 PM To: Jakarta Commons Developers List Subject: Re: [configuration] Refactoring for file based configurations Henning P. Schmiedehausen wrote: Ok. Please make sure that the changes that I did over the weekend are still kept when you check in. Sure, don't worry :) How about putting out RC2 right now (with the Vector back and the throwExceptionWhenMissing property). then factoring your changes and release RC3 with these. If they work out, make the result 1.0? I would prefer to hold the rc2 until the refactoring is checked in, but I'm not fundamentally opposed to this. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Refactoring for file based configurations
Emmanuel, how long till you have the refactored loading stuff committed? If its just a day or two, lets get it in.. If Friday comes with out, then the lets cut an RC2. I know Henning and I are attending OSCOM next week starting the 28th, and it would be good to have Turbine and Torque released by then... Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 1:44 PM To: Jakarta Commons Developers List Subject: Re: [configuration] Refactoring for file based configurations Henning P. Schmiedehausen wrote: An RC right now would allow commons-configuration users to get their stuff in shape against a semi-released version and not current random snapshot of the day. I expect the File stuff to break a little in the beginning, delaying another RC at least one more week. So I'd vote for releasing the current stuff as RC2 and then put your file refactoring in. If you need it absolutely for torque and turbine then go ahead, but I'm worried to release a RC3 with significant structural changes when a RC is supposed to include only minor changes. Actually I wanted this for RC1 but I was on vacation when it was released ;) I'm reluctant to let a second RC out without this change. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Refactoring for file based configurations
Okay.. I should have an opportunity to help test in a large turbine based app tomarrow, so that will help verify everythign.. Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 2:53 PM To: Jakarta Commons Developers List Subject: Re: [configuration] Refactoring for file based configurations Eric Pugh wrote: Emmanuel, how long till you have the refactored loading stuff committed? If its just a day or two, lets get it in.. If Friday comes with out, then the lets cut an RC2. I know Henning and I are attending OSCOM next week starting the 28th, and it would be good to have Turbine and Torque released by then... Eric I can commit what I have now but I'll need some help on testing. I'll tag the tree before I start comiting, thus we will be able to spawn easily a RC2 branch if the refactoring is not completed by friday. Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] feature request
I think there is a bug out there about a ReloadableConfiguratoin.. One way you could implement something like this is having a decorator that implements the functionality.. Configuration c = new PollingConfiguration(myFileConfiguration); And then all your logic would be in the pollingConfiguraiton.. Go ahead and submit a bug, and if you have some code, feel free to send in a patch! (for post 1.0!) ERic -Original Message- From: Jung, Eric [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 22, 2004 7:18 PM To: Jakarta Commons Developers List Subject: [Configuration] feature request I looked at BugZilla and didn't see any feature requests for this, so I thought I'd ask here before I add it. Has this been requested before? I'd like Configuration to have the ability to poll its configuration source(s) for changes every n seconds. Right now I always end up writing this code again and again on top of Configuration to handle it. It is required because I have applications that cycle only once every few months. So I may want to make configuration changes to the app, but currently Configuration has no out-of-the-box means to poll for those changes. Of course, a push means would be better than polling, but I've no doubt this would be inordinately more complex, so I'm willing to settle for polling :) -Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Website maintainer?
Daniel, I know how frustrating it is to get your new project up and available.. Send me patchs and I'll try and do it (though I haven't done it before). Unfortunantly, I think you need commons-commit access which normally comes when 1) you are active in a commons project or 2) when your project is ready for promotion. I joined via path 2. Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, October 16, 2004 11:05 AM To: Jakarta Commons Developers List Subject: Website maintainer? Hi folks, I'm wondering who is maintaining the commons website. I've added two new components to the sandbox (i18n and contract) and I'd like to add a link and description to the website. Is anybody around who can do this for me or do I need commons commit access to do it myself? Cheers, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] RE: Commons Configuration Release 1.0
Fantastic Emmanuel.. I went to go and help you and all the work was done! Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 12:00 AM To: [EMAIL PROTECTED] Cc: Eric Pugh Subject: Re: Commons Configuration Release 1.0 I fixed the remaining issues tonight, you can go ahead and release this long awaited 1.0 :) Emmanuel Henning Schmiedehausen wrote: Hi, basically Eric and I agreed at OSCOM to relase as is. We could add a known issues item for this. We could easily make a release 1.0.1 a week or two after this. I will put a CfV on the commons list. Regards Henning On Sat, 2004-10-02 at 12:58, Emmanuel Bourg wrote: Hi ! No problem to let you manage the release, you are definitely more experienced in this exercice than us ;) There are just some issues reported on the RC2 that I'd like to see resolved before releasing the final version, that's Bug 30799 regarding properties inserted twice in the XML file, the JNDIConfiguration tweak suggested by Eric Jung to close the NamingEnumeration, and the auto save issue reported by Mark Roth. I will not have much time this weekend to work on [configuration], if someone can deal with the remaining issues before monday that's fine, otherwise I suggest to release on thursday or friday. Emmanuel Bourg Henning Schmiedehausen wrote: Hi Emmanuel, Eric and I talked at OSCOM about finally releasing c-c 1.0. Eric volunteered me as release manager. ;-) Do you have any reservations or problems with this? If not, I would CfV the 1.0 release on monday and do the tagging, releasing and key-signing. Regards Henning - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [i18n] New component - help needed
Danile, I just tossed in a fix. basically the parent project is broken.. not extending it works.. as far tas the script, just rerun on your box the entire script, and then upload the homepage. Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 8:12 PM To: Jakarta Commons Developers List Subject: [i18n] New component - help needed Hi folks, I've successfully added the I18n component to the commons sandbox. As I'm new to Maven I didn't managed to generate the API Javadocs. Can anyone have a look at this? Is this my fault as I assume? Seems that Maven can not find the source (but is actually building the jars without trouble). Any hints would be great! How can I integrate the link to the new component to the main commons page? Should I run the script on commons-sandbox top level? I'm afraid to do so as I may cause something bad. Regards, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] handling exceptions in AbstractConfiguration implementations
Hi Ricardo.. Sounds like you are working on something I've been wanting for a long time! At any rate.. I believe there is a ConfigurationRuntimeException that you could throw, even though it's not part of the API. I think the reason that most of the gets don't throw an exception is because 99% of the time if you throw an exception then the calling class will just have to rethrow it. In otherwords, say I am using a Configuration object in my code, and I do configuration.getDouble(key);. If getDouble throws an exception then I am going to have these try/catch cluases all over the place, cluttering the code. and, I really except getDouble() to allows work. If it doesn't, my application will just pass it on,not have some sort of fancy if getDouble fails, then try getString or something weird. I think what you can do is just wrap your HibernateException in a ConfiguratoinRuntimeException and toss that. JDBCConfiguration should probably be doning the same thing. Eric -Original Message- From: Ricardo Gladwell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 12:56 PM To: Jakarta Commons Developers List Subject: [configuration] handling exceptions in AbstractConfiguration implementations Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of getPropertyDirect calls the hibernate Session.get() method which can throw an exception. Looking at your implementation of the DatabaseConfiguration I can see that it simply consumes SQLExceptions thrown from the JDBC API, logging the stack trace. However, what if you want to be warned of exceptions being thrown by the underlying implementation of Configuration? I notice you already have a nestable ConfigurationException implemented. Surely, all Configuration methods should indicate they will throw this exception if they are expected to read/write data? Also, the AbstractConfiguration class does not describe this contract (logging all errors throw by underlying framework) or what should be returned in the event of an error? I assume you should return null values but this is not described anywhere. Kind regards, -- Ricardo Gladwell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [CONFIGURATION] [CfV] Commons Configuration Version 1.0
Please vote now: [X] +1 - Yes [ ] 0 - I don't care [ ] -1 - No - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] handling exceptions in AbstractConfiguration implementations
I tried hitting commons-resources.sf.net but no joy.. I think this licensing thing is going to bite a lot of projects.. I was thinking of settingup a sf project called hibernatecodethatiwantedatapache.sf.net where I could toss all these bits and pieces. Has Jakarta-Commons actually set up a parralel site on SF to work around these issues? ERic -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 2:15 PM To: Jakarta Commons Developers List Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations Problem with having Hibernate implementations is that the license is incompatible with the ASL. So you'll need to keep any incompatible code somewhere elselike I do with commons-resources at sf.net. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Ricardo Gladwell [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 8:07 AM Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations Eric Pugh wrote: Hi Ricardo.. Sounds like you are working on something I've been wanting for a long time! Of course, I was going to release it anyway so please find the source-code attached. Not sure it belongs in commons-configration API; probably better contributed to the hibernate project. If you can think of any improvements please mail the patches back to me for my own project :) In otherwords, say I am using a Configuration object in my code, and I do configuration.getDouble(key);. If getDouble throws an exception then I am going to have these try/catch cluases all over the place, cluttering the code. and, I really except getDouble() to allows work. If it doesn't, my application will just pass it on,not have some sort of fancy if getDouble fails, then try getString or something weird. Good point, although I'm still dubious about throwing RuntimeExceptions - those things shoot straight through everything like a silver bullet and can even crash some servlet engines. From my perspective, I'm not bothered if the Configuration object throws exceptions: I wouldn't catch such exceptions in my web application, instead letting them fly all the way to the exception screen. This way, I can see them occuring as I test my application through the browser. Obviously, sometimes when configuring your application you just want your configuration to work or keep on working untill if it encounters an errors. However, simply allowing your application to ignore exceptions until they create new exception elsewhere seems like a good way to create hard-to-fix bugs. Surely, it would be better to relay the errors and let the application decide what to do with them? I think what you can do is just wrap your HibernateException in a ConfiguratoinRuntimeException and toss that. JDBCConfiguration should probably be doning the same thing. Another alternative would be to have a getExceptions() method for all Configurations which stores exceptions occuring and stores them for later reporting. A good comprimise would be to allow all Configuration objects to have two modes: one where exceptions are thrown as soon as they occur and another one which stores exceptions as I suggested. Kind regards, -- Ricardo Gladwell -Original Message- From: Ricardo Gladwell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 12:56 PM To: Jakarta Commons Developers List Subject: [configuration] handling exceptions in AbstractConfiguration implementations Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of getPropertyDirect calls the hibernate Session.get() method which can throw an exception. Looking at your implementation of the DatabaseConfiguration I can see that it simply consumes SQLExceptions thrown from the JDBC API, logging the stack trace. However, what if you want to be warned of exceptions being thrown by the underlying implementation of Configuration? I notice you already have a nestable ConfigurationException implemented. Surely, all Configuration methods should indicate they will throw this exception if they are expected to read/write data? Also, the AbstractConfiguration class does not describe this contract (logging all errors throw by underlying framework) or what should be returned in the event
RE: [configuration] handling exceptions in AbstractConfiguration implementations
This is really driving me crazy.. I have tracked threads on general and jakarta-pmc mailing lists about this.. And everytime it comes down to I am not a lawyer and a bunch of FUD. We really need someone from the top of Apache to provide direction. I work a lot with hibernate code and can think of at least 4 projects that have hibernate code in them (at least as far as import statements). Of course, I guess this isn't the right mailing list.. I could try and push this to some sort of conclusion, but I don't want to be told no! right now you can just pick your interpretation! Argh, Eric -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 7:23 PM To: Jakarta Commons Developers List Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations One advantage for me is having the ability to reuse your existing application's configuration. I created a Hibernate, iBatis, Torque, DBUtils, and straight JDBC implementations for commons-resource for this very purpose. I moved the Hibernate impl over to sf.net because of license conflicts. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx - Original Message - From: Emmanuel Bourg [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 12:59 PM Subject: Re: [configuration] handling exceptions in AbstractConfiguration implementations I don't want to sound harsh, but what is the added value of using Hibernate here for such a simple data structure ? A direct JDBC implementation is good enough and spare a 1.5MB dependency. Emmanuel Bourg Ricardo Gladwell wrote: Hi All, I'm currently developing a sub-class of the AbstractConfiguration classthat uses Hibernate to access configuration properties (unimaginatively called Hibernate Configuration). I'm slightly concerned about the way sub-classes are suposed to handle exceptions: All the abstract method are defined as not throwing exceptions. All calls to hibernate, however, throw HibernateExceptions. So, for example, my implementation of getPropertyDirect calls the hibernate Session.get() method which can throw an exception. Looking at your implementation of the DatabaseConfiguration I can see that it simply consumes SQLExceptions thrown from the JDBC API, logging the stack trace. However, what if you want to be warned of exceptions being thrown by the underlying implementation of Configuration? I notice you already have a nestable ConfigurationException implemented. Surely, all Configuration methods should indicate they will throw this exception if they are expected to read/write data? Also, the AbstractConfiguration class does not describe this contract (logging all errors throw by underlying framework) or what should be returned in the event of an error? I assume you should return null values but this is not described anywhere. Kind regards, -- Ricardo Gladwell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] RE: Commons/Config
MessageHi Mark.. You should send these to the mailing list, as you can then have exposure to your question by lots of experts, and everybody can learn! I am CC the list back. First off, check out the RC2, that has many many fixes. And 1.0 is expected as soon as Henning has a chance to cut it. For your problem, I think everythign is relative to the working directory. So, what you can do is set up your file name as ../config/config_sub1.properties. This will get around your initial issue. I think the idea would always be to run relative from your working directory unless you provided a full path. Also, the latest version in CVS, which will be 1.0 Real Soon Now has a bunch of much better path resolution code, applied in a more global manner. Eric -Original Message- From: Mark.Woodman [mailto:[EMAIL PROTECTED] Sent: Saturday, October 09, 2004 2:19 AM To: [EMAIL PROTECTED] Subject: RE: Commons/Config Eric, I haven't seen any documentation that answers this question, so I was hoping you might be able to help. Is there a way to have a configuration file specify that internal resources should be found relative to the location of itself, rather than relative to the location of the working directory? The build we have of the config package (August 11) seems to always use the latter. If the working directory doesn't contain the config file we're using, we're up the proverbial creek. For example, lets say the working directory is: /app/bin And the config files live here: /app/config/config_main.xml /app/config/config_sub1.properties /app/config/config_sub2.properties And the contents of config_main.xml is: configuration properties fileName=config_sub1.properties/ properties fileName=config_sub2.properties/ /configuration When I try to load config_main.xml (and the working directory is /app/bin), the ConfigurationFactory tries to find /app/bin/config_sub1.properties and promptly throws an Exception. This seems to be a show-stopper for us. Is this expected behavior, or has it changed since August, or is there a way to tell the configuration to use paths relative to the config file? Thanks for your help, Mark __ Mark Woodman 719.234.0670 Intelligent Software Solutions Email: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/configuration/src/test/org/apache/commons/configuration TestBaseConfiguration.java
Good fix.. However, ins;t there a class in commons lang that does that for
us?
Eric
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, October 18, 2004 11:45 AM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-commons/configuration/src/test/org/apache/commons/configuration
TestBaseConfiguration.java
ebourg 2004/10/18 03:44:31
Modified:configuration/xdocs changes.xml
configuration/src/java/org/apache/commons/configuration
PropertyConverter.java
configuration/src/test/org/apache/commons/configuration
TestBaseConfiguration.java
Log:
Numeric properties can now be specified in hexadecimal format
(bug 28026)
Revision ChangesPath
1.58 +4 -0 jakarta-commons/configuration/xdocs/changes.xml
Index: changes.xml
===
RCS file: /home/cvs/jakarta-commons/configuration/xdocs/changes.xml,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- changes.xml 18 Oct 2004 10:19:26 - 1.57
+++ changes.xml 18 Oct 2004 10:44:31 - 1.58
@@ -8,6 +8,10 @@
body
release version=1.1-dev date=in CVS
+ action dev=ebourg type=add issue=28026
+Numeric properties can now be specified in hexadecimal format,
+for example number = 0xC5F0.
+ /action
action dev=oheger type=fix issue=31745
Fixed HierarchicalConfiguration.getKeys(String), it
returned an empty
iterator if the prefix string contained indices.
1.2 +47 -6
jakarta-commons/configuration/src/java/org/apache/commons/configur
ation/PropertyConverter.java
Index: PropertyConverter.java
===
RCS file:
/home/cvs/jakarta-commons/configuration/src/java/org/apache/common
s/configuration/PropertyConverter.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PropertyConverter.java 18 Oct 2004 09:54:37 - 1.1
+++ PropertyConverter.java 18 Oct 2004 10:44:31 - 1.2
@@ -84,7 +84,15 @@
{
try
{
-return new Byte((String) value);
+String string = (String) value;
+if (string.startsWith(0x))
+{
+return new Byte((byte)
Integer.parseInt(string.substring(2), 16));
+}
+else
+{
+return new Byte(string);
+}
}
catch (NumberFormatException e)
{
@@ -113,7 +121,16 @@
{
try
{
-return new Short((String) value);
+String string = (String) value;
+if (string.startsWith(0x))
+{
+return new Short((short)
Integer.parseInt(string.substring(2), 16));
+}
+else
+{
+return new Short(string);
+}
+
}
catch (NumberFormatException e)
{
@@ -142,7 +159,15 @@
{
try
{
-return new Integer((String) value);
+String string = (String) value;
+if (string.startsWith(0x))
+{
+return new Integer((int)
Long.parseLong(string.substring(2), 16));
+}
+else
+{
+return new Integer(string);
+}
}
catch (NumberFormatException e)
{
@@ -171,7 +196,15 @@
{
try
{
-return new Long((String) value);
+String string = (String) value;
+if (string.startsWith(0x))
+{
+return new Long(new
BigInteger(string.substring(2), 16).longValue());
+}
+else
+{
+return new Long(string);
+}
}
catch (NumberFormatException e)
{
@@ -258,7 +291,15 @@
{
try
{
-return new BigInteger((String) value);
+String string = (String) value;
+if (string.startsWith(0x))
+{
+return new BigInteger(string.substring(2), 16);
+}
+else
+{
+return new BigInteger(string);
+
[Configuration] VectorSupport for Configuration
Hi all, I think we should remove the Vector support now that we are past 1.0. Should we add a VectorConfiguration class that decorates a regular Configuration and adds in the Vector methods? Or just not worry about it? Alternatively, should a VectorConfiguration live in the Turbine 2.3 source tree? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Configuration] VectorSupport for Configuration
Okay.. I was hapilly wiiping out Vectors Ran into this method: ExtendedProperties.getExtendedProperties(), where it says convert lists into vectors.. What is it about ExtendProperties that I don't know about? ERic -Original Message- From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] Sent: Monday, October 18, 2004 9:29 PM To: [EMAIL PROTECTED] Subject: Re: [Configuration] VectorSupport for Configuration Eric Pugh [EMAIL PROTECTED] writes: I think we should remove the Vector support now that we are past 1.0. Should we add a VectorConfiguration class that decorates a regular Configuration and adds in the Vector methods? Yep, nuke it! Or just not worry about it? Alternatively, should a VectorConfiguration live in the Turbine 2.3 source tree? Turbine 2.x (x 3) will solely use getList(). I was just worrying about current Turbine 2.x (x = 3) users that want to upgrade their application dependencies from mumble-SNAPSHOT to 1.0 and suddently find methods gone. The 1.0 release avoids this and for 1.1, we will be better off without getVector(). Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email]RE: [GUMP@brutus]: Project commons-email (in module jakarta-commons-sandbox) failed
Hi guys.. I just fixed it... I am just starting to learn about gump, which is a continous integration tool. It needs to know about all dependencies, so when commons-validator and oro where added, gump gave up the ghost! The fix is here: http://cvs.apache.org/viewcvs.cgi/gump/project/jakarta-commons-sandbox.xml However, we are not out of the woods yet... Corey, the unit tests depend on a public email server being up and running. However, due to spammers etc, most prevent relaying. So we really need a Mock SMPT server. Dumbster would work. Corey, if you have time, but not lots, if you can compile Dumbster, I'll do the integration work. better yet would be a patch with both! Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 5:48 AM To: Jakarta Commons Developers List Subject: Re: [EMAIL PROTECTED]: Project commons-email (in module jakarta-commons-sandbox) failed I dont know how to fix this, but yes, I added email validation using commons-validator and I believe this is the problem that is causing the build to fail. -Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-commons/configuration/src/java/org/apache/commons/configuration AbstractConfiguration.java CompositeConfiguration.java Configuration.java
Unfortunantly, it only works when I can slip the change in without anyone knowing... ERic -Original Message- From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 12:31 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-commons/configuration/src/java/org/apache/commons/configuration AbstractConfiguration.java CompositeConfiguration.java Configuration.java [EMAIL PROTECTED] writes: + action dev=ebourg type=remove Hehe, so they will blame Emmanuel when everything breaks. Clever move. ;-) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email]RE: [GUMP@brutus]: Project commons-email (in module jakarta-commons-sandbox) failed
Great.. What do you mean by 'original'? I'm not too fussed about code formats as long as it all matches. My rule of thumb is to make my IDE do whatever the existing code does. If you are looking to do a big reformat of the code, make that a seperate patch. The reason is that when the reformat happens it causes lots of noise in the CVS diffs, so any actual code functionality changes get lost. So, maybe submit first the code change, and then the reformatting change. Thanks! Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 12:06 PM To: [EMAIL PROTECTED] Cc: Jakarta Commons Developers List Subject: Re: [email]RE: [EMAIL PROTECTED]: Project commons-email (in module jakarta-commons-sandbox) failed Im on it :-) I have also reformatted the code to the 'original' code as specified on the website. Hopefully be in the bugzilla soon. Corey On Tue, 19 Oct 2004 10:02:44 +0100, Eric Pugh [EMAIL PROTECTED] wrote: Hi guys.. I just fixed it... I am just starting to learn about gump, which is a continous integration tool. It needs to know about all dependencies, so when commons-validator and oro where added, gump gave up the ghost! The fix is here: http://cvs.apache.org/viewcvs.cgi/gump/project/jakarta-commons-sandbox.xml However, we are not out of the woods yet... Corey, the unit tests depend on a public email server being up and running. However, due to spammers etc, most prevent relaying. So we really need a Mock SMPT server. Dumbster would work. Corey, if you have time, but not lots, if you can compile Dumbster, I'll do the integration work. better yet would be a patch with both! Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 5:48 AM To: Jakarta Commons Developers List Subject: Re: [EMAIL PROTECTED]: Project commons-email (in module jakarta-commons-sandbox) failed I dont know how to fix this, but yes, I added email validation using commons-validator and I believe this is the problem that is causing the build to fail. -Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [feedparser] Getting Brad Neuberg CVS commit
If he is already a Jakarta committer, then sandbox commit privliges is automatic, just need to ask for it. Otherwise, if not, then you need to call for a [vote]. Eric -Original Message- From: Kevin A. Burton [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 1:01 AM To: Jakarta Commons Developers List Subject: [feedparser] Getting Brad Neuberg CVS commit Hi gang. Brad Neuberg has been working with me on the Jakarta Feed Parser for the last 6 months, and has proved himself capable of committing to CVS via the patch mechanism. He has implemented large changes to the feed parser, such as heuristics for more advanced weblog provider probing, unit test infrastructure, and more. He has also shown that he can communicate on the Jakarta Commons mailing list concerning patches and design changes, as he has been a member on this list for the last five months. Brad is currently working on landing a large set of patches, which he will discuss on this list. It would help him and I if he had CVS access. Can I get Brad CVS access to FeedParser in the sandbox? Kevin -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] ConfigurationFactory namespaces
Simplicity I think is always a good idea.. I don't use it.. I will say, I am not too keen on the ConfiguraitonFactory anyway... I think I made a hash of things when first writing it... Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 3:52 PM To: Jakarta Commons Developers List Subject: [configuration] ConfigurationFactory namespaces While reviewing ConfigurationFactory I stumbled on the namespace logic, may I ask who is actually using it ? It looks like an unnecessary complexity to me, imho it's easier to have several configuration descriptors rather than a single namespaced descriptor. What do you think ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [feedparser] Getting Brad Neuberg CVS commit
I know it feels like a chicken and an egg sort of problem... One of the historical aspects of commons is that half the code came from other projects, and half started from scratch. At least for the code that came from other projects meant that they already had committers involved, facilitating access. And those started from scratch where started by people involved in Commons already. I always recommend that someone pick up one or two projects to be involved with. That way, as traction is lost on one, progress can be made on the other, and you don't get too siloed... I am sure that with a periond of involvement the demonstrates his abilities and that he gets the Apache Way that he will gain access. We just all need to get to know him! Eric -Original Message- From: Craig McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 2:26 AM To: Jakarta Commons Developers List Subject: Re: [feedparser] Getting Brad Neuberg CVS commit On Wed, 20 Oct 2004 17:14:33 -0700, Kevin A. Burton [EMAIL PROTECTED] wrote: Brad is working full time on feedparser and you're essentially telling him he can't get CVS access until its 1.0. How are we supposed to GET it to 1.0 it he can't get CVS access? That's certainly not clear from the email history. For example, you could help this cause a lot if you mentioned (in your CVS commit messages) which one were applied because Brad did them instead of you. Nobody can tell that he did *any* of the work. Do you see the problem here? I think the issue is that right now for the jakarta sandbox if you give Brad access then you're giving him access to a number of other projects. He doesn't want access to other projects he just wants access to FeedParser. The deeper issue is that you seem to expect Apache to work like SourceForge, which it doesn't. Committer access is earned (based on demonstrated contributions), not requested -- and it's voted on by other committers (in this particular case, those who commit to Jakarta Commons projects), not granted to non-current-committers simply because of asking. The fact that jakarta-commons-sandbox is all under the control of a single set of karma is an unfortunate fact of our current CVS implementation, but it makes absolutely no difference to the case. Any prospective Commons committer who couldn't be trusted to play by the rules shouldn't be a committer on *any* Apache project. On the other hand, granting sandbox-wide or commons-wide (which happens when sandbox projects get promoted) karma is a key tool in increasing the community of active developers on individual packages, because it reduces the barrier to jump in and help. Kevin Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] ConfigurationFactory namespaces
Re: [configuration] ConfigurationFactory namespacesI agree with everything excelpt the last one, merging the two.. CompositeConfiguration is a very simple holder for configurations. You can easily use it programatically for example. However, ConfigurationFactory brings a lot more with it.. Including with what you propose the ability to reload itself.. Something to think about is that if ConfigurationFactory is going to start reloading itself, then maybe we need to think about how we are going to bolt in out event handling stuff. On a related note, now that Vector has been removed, and you have tossed in a bunch of small features and stuff that had been sitting around. Should we think about a 1.1 release? I know, it seems soon, but... Release early/release often... Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Thursday, October 21, 2004 8:45 AM To: Jakarta Commons Developers List Subject: Re: [configuration] ConfigurationFactory namespaces I don't use ConfigurationFactory but it's definitely useful as a central place to configure an application. I think we could even push the concept a bit further, after all, the configuration descriptor read by ConfigurationFactory *is* a configuration, it's even a file based configuration that should be automatically reloaded when the file is changed. So, what about the following ideas: - remove the namespace handling - make ConfigurationFactory implement FileConfiguration (it already has the set/getBasePath() and setGetFileName() methods, load() is easy to implement with the current code and there is no need to implement save() since it's read only) - add a composite element to load another composite configuration descriptor - not sure about this one, but ConfigurationFactory and CompositeConfiguration could maybe be merged... Emmanuel Bourg Eric Pugh wrote: Simplicity I think is always a good idea.. I don't use it.. I will say, I am not too keen on the ConfiguraitonFactory anyway... I think I made a hash of things when first writing it... Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 20, 2004 3:52 PM To: Jakarta Commons Developers List Subject: [configuration] ConfigurationFactory namespaces While reviewing ConfigurationFactory I stumbled on the namespace logic, may I ask who is actually using it ? It looks like an unnecessary complexity to me, imho it's easier to have several configuration descriptors rather than a single namespaced descriptor. What do you think ? Emmanuel Bourg
RE: [configuration] Concerns with ConfigurationRuntimeException
I think both arguments are valid. It depends on your use case. One of the
obstacles with an interface like Configuration is that you don't know who is
going to implement it. And some are reliable, and some are not. For the
same reasons that the Map,Set,List interface don't throw checked exceptions,
so Configuration doesn't throw. Especially since I think that the most
common use would be:
try {
conf.getString(hi);
}
catch (ConfigurationException ce){
throw new RuntimeException(ce)
}
and so on.. It most apps the graceful shutdown aspects are never
implemented. ON a webapp I often just bubble the error up and say try
again.. However, there are apps, like a public facing app, where you
can't do that.
Could we have two interfaces? Configuration and StrictConfiguration?
StrictConfiguration would declare checked methods?
Eric
-Original Message-
From: Ricardo Gladwell [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 21, 2004 2:11 PM
To: Jakarta Commons Developers List
Subject: Re: [configuration] Concerns with ConfigurationRuntimeException
Emmanuel Bourg wrote:
Let me know if I missed an exception.
AFAIK, all actions throw the runtime exception ConversionException.
I'm not fond of this. It only affects the configurations using an
unreliable communication channel to access the properties, that's
JNDIConfiguration and DatabaseConfiguration, the most widely used
configurations are file based and not affected by this issue, why
annoying their users ? Also this may prevent us from making
Configurations implement the Map interface, I still want to try this.
I would argue that all communcation channels have the potential to be
unreliable especially when you consider the IO API can be extended to
read/write data from variety of source types. We cannot exclude the
possiblity of, for example, reading configuration information over
(unreliable) network connections. I don't this is an argument against
reporting exceptions in the underlying layer. Otherwise, would the
various IOException and SQLException also be runtime exceptions?
I think, rather than force users to exit their programs on a
configuration error we should give them the option of either exiting
gracefully themselves or handling configuration exceptions unless we can
guanrantee that no exceptions will be thrown be by the code under all
circumstances (i.e. if disk is full, if hard disk is corrupted, etc) in
which case *we* have to handle the exception and recover from it. There
are many reasons for doing this, more importantly, so that users can
handle and recover from configuration read/write exceptions themselves.
Another option would be to create an exception reporting mechanism
within the Configuration interface. Perhaps a method call
getExceptionsThrown() that returns a list of exceptions thrown during
the last few operations. Of course, this does mean that we are
re-creating the exception throwing mechanism implemented within
Java itself.
I don't want to declare a ConfigurationException on every method of the
Configuration interface, logging data access errors is fine imho, but
there are some unexpected and undocumented runtime exceptions that
should be removed (the most important is in
JNDIConfiguration.getKeys()). The case of ConversionException should
also be examined.
It depends on why you are opposed to adding ConfigurationException to
all methods declartions in Configuration. If it's because it would
clutter the code with various try/catch blocks for users then I would
argue that this should not be an issue: reporting and handling
exceptions is a hassle but there is a very specific reason we have them.
I think the users would object more to the fact that
Kind regards,
-- Ricardo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[email] Dumbster failing
Hi all, I am getting some java security issues with the current unit tests and dumbster. Can any one else (corey ;-) ) verify that they work properly? I thought it was my SMTP server, but I stopped that. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] tests configuartion
You probably where caught between my first commit and my last one! -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Sunday, October 24, 2004 10:43 PM To: Jakarta Commons Developers List Subject: Re: [email] tests configuartion Ah fixed .. I just cvs updated. On 24 Oct 2004, at 22:38, Mark Lowe wrote: I've been working on a patch but I cant get the existing tests to run, I've changed the configuration details in the email configuration class. But compiling the tests fail as nothing is known about this mock dumpster smtp server. The patch I'm working on provides an option to set a resolve media option and then will embed any media contained in the HTML message. If works for images, but need to check for other media and background images. But its gonna be hard to submit anything as a working patch if the head version wont compile. Can any body point me in the right direction to getting these tests building? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Dumbster failing
Go ahead and before doing any coding, send me a single patch with all the formatting chanes. No code changes! Then in the comments for the commit I can specify Code formatting cleanup, no changes. Just to confirm, your checkstyle plugin is using the standard jakarta formatting? Which, since I can't find anything to the contrary, is the Sun format. I think since email came from the Turbine project, it was formatted with the turbine format. Here are some links on the correct format to use: http://jakarta.apache.org/commons/patches.html http://jakarta.apache.org/site/library.html Thanks! We'll get there! It's nice to see new life in [email]. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 5:11 AM To: Jakarta Commons Developers List Subject: Re: [email] Dumbster failing Ok, I will switch my build to maven from Ant (although Maven seemed not to like dumbster too much last time I tried it). I will get the get the tests going and resubmit. I think I'm going to have to start again from the cvs, cause my code tree is becoming too different from the committed one. I do have one request though, can we please fix the formatting!! :-) My checkstyle plugin goes bonkers when i update from the cvs. I realise this is partly my fault (the first set of tests had the wrong style). How do you suggest we deal with this? Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] Oliver Heger as Committer
Hi all, I would like to nominate Oliver Heger as a committer to Jakarta Commons. Oliver has been very active in the [configuration] project[1], and I feel gets the Jakarta way. He has partipated in doing a lot of the icky bug finding and fixing in [configuration] and will be an asset in designing the next version of [configuration]. A bit about him: I was born in 1973 in Germany. I have a diploma in computer science. From 1999 to 2003 I worked as a developer for a small software company. My main area of work were internet applications based on the J2EE platform. Since December 2004 I work for the University of Marburg, Germany in the Institute of Medical Informatics and for the university hospital. [ ] Yes, bring him in! [ ] Don't care [ ] No Eric [1] http://nagoya.apache.org/eyebrowse/SearchList?listId=listName=commons-dev%4 0jakarta.apache.orgsearchText=oliver+hegerdefaultField=senderSearch=Searc h - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] Moving test resources to /src/test-resources
Hi all, I am using the updated Maven Eclipse plugin, and one of the difficulties that arises is that Eclipse (and therefore Maven) want each directory, if included as resources on Eclipse's classpath, to be different. Right now, in configuration we include the /conf directory a ton of times. What I want to do is bring [configuration] into line with other mavenenized projects where test resources are all in /src/test-resources. And the jar resources would remain in /conf. Basically just digesterRules.xml. However, when I started this, I ran into a couple unit test failures. Should I do this, and then fix the errors? I have a bunch of questions about some of the new tests that would be better answered if I could commit the changes... Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] Oliver Heger as Committer
[X] Yes, bring him in! [ ] Don't care [ ] No - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Moving test resources to /src/test-resources
I dug in a bit more, and actually, only one unit test fails, TestPropertiesConfiguration.testLoadViaPropertyWithBasePath2. When I change the basepath's to use src/test-resources: private String testBasePath2 = new File(src/test-resources).getAbsoluteFile().getParentFile().getAbsolutePath (); the resulting file is c:\java\cvs\jakarta-commons\configuration\src. I think this is wrong, becase I don't see how the unit test later would work.. I get a NPE, and it seem reasonable.. So, if no one has an object, I'd like to apply this change. All the unit tests (99.76%) pass. ERic -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 12:10 PM To: Commons-Dev Subject: [configuration] Moving test resources to /src/test-resources Hi all, I am using the updated Maven Eclipse plugin, and one of the difficulties that arises is that Eclipse (and therefore Maven) want each directory, if included as resources on Eclipse's classpath, to be different. Right now, in configuration we include the /conf directory a ton of times. What I want to do is bring [configuration] into line with other mavenenized projects where test resources are all in /src/test-resources. And the jar resources would remain in /conf. Basically just digesterRules.xml. However, when I started this, I ran into a couple unit test failures. Should I do this, and then fix the errors? I have a bunch of questions about some of the new tests that would be better answered if I could commit the changes... Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Moving test resources to /src/test-resources
That is one reason.. The problem became apparent when putting some new features into the Eclipse plugin for Maven. [1] We'll be making it backwards compatilbe in order not to break a project like [configuration]. but more to the point, the /conf directory has become huge, with a mix, well okay, mostly, test resources, plus a config file or two. By making this change we explicity list our test resources, they are in /src/test-resources. At this point, I have everything working, so I just am trying to build consensus that this is good. I personally think that it sorts things out better. Eric [1] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] by=threadfrom=913802 -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 3:31 PM To: Jakarta Commons Developers List Subject: Re: [configuration] Moving test resources to /src/test-resources I'm not sure to understand the issue, why do you need to import /conf in your classpath ? That's for running the unit tests directly from Eclipse ? Emmanuel Bourg Eric Pugh wrote: Hi all, I am using the updated Maven Eclipse plugin, and one of the difficulties that arises is that Eclipse (and therefore Maven) want each directory, if included as resources on Eclipse's classpath, to be different. Right now, in configuration we include the /conf directory a ton of times. What I want to do is bring [configuration] into line with other mavenenized projects where test resources are all in /src/test-resources. And the jar resources would remain in /conf. Basically just digesterRules.xml. However, when I started this, I ran into a couple unit test failures. Should I do this, and then fix the errors? I have a bunch of questions about some of the new tests that would be better answered if I could commit the changes... Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[configuration] Any reason why JNDIConfiguration is readonly?
Anyone have a good reason whe JNDIConfiguration doesn't support setting properties? I was thinking of going for just a simple string storing of properties, not binding in Datasources or anything funky like that... Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Moving test resources to /src/test-resources
I'd actually like to keep them off of the classpath (src/test/resouces) because many of the file don't go in the classpath, they are meant to be read off the filesystem. I think it is simpler to either just copy the ones to the classpath that need it, or take the approach that if they are supposed to be in the classpath, then put them in /src/test to begin with! Eric -Original Message- From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 4:29 PM To: [EMAIL PROTECTED] Subject: Re: [configuration] Moving test resources to /src/test-resources Eric Pugh [EMAIL PROTECTED] writes: By making this change we explicity list our test resources, they are in /src/test-resources. BTW: I would very much prefer src/test/resources or src/test/conf. With src/test being on the classpath anyway, the latter might even work without any changes. Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED]+49 9131 50 654 0 http://www.intermeta.de/ RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire Linux, Java, perl, Solaris -- Consulting, Training, Development Fighting for one's political stand is an honorable action, but re- fusing to acknowledge that there might be weaknesses in one's position - in order to identify them so that they can be remedied - is a large enough problem with the Open Source movement that it deserves to be on this list of the top five problems. -- Michelle Levesque, Fundamental Issues with Open Source Software Development - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Any reason why JNDIConfiguration is readonly?
Well.. I started on the bind/rebind stuff. and am having a really hard time of it... I can bind a property like this newprop just fine.. However, a property like my.newprop fails.. I think I need to crawl the tree and find the correct context and then set that... argh.. I don't just want to save in a temporary storage because I want to be able to persist via JNDI configuration changes. Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 5:54 PM To: Jakarta Commons Developers List Subject: Re: [configuration] Any reason why JNDIConfiguration is readonly? Eric Pugh wrote: Anyone have a good reason whe JNDIConfiguration doesn't support setting properties? I was thinking of going for just a simple string storing of properties, not binding in Datasources or anything funky like that... Eric How to you plan to implement this ? By playing with the bind/rebind/unbind functions of the Context interface, or by storing the new properties into a Map ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Dumbster failing
Not a problem. I appreciate your working with me on this. I am looking forward to getting [email] whipped into shape! ERi -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 7:21 PM To: [EMAIL PROTECTED] Cc: Jakarta Commons Developers List Subject: Re: [email] Dumbster failing Ok, I have the tests all up and running with Maven. I have also made some minor mods, based on the tests or improving the input checking (this is why some of the tests are failing, there where against my changes not the HEAD version sorry) So once we get this formatting issue sorted, I will submit to you the new patch. This should raise the test coverage to 90+% for all (non-deprecated) classes. Thanks, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[email] was RE: Validator inside of Email.java (RE: [email] Dumbster failing)
HumI'll answer the easy question first.. I think the @author tags should stay since it is an option. The PMC justs asks that projects make a decision on it one way or the other. So, for [email], I'll register myself on the yes they should stay side. The reason is that it helps figure out who had impact on what code, and at least for me, gives me the warm fuzzy's! It doensn't change copyright or anything, that remains with ASF. I belive it encourages contribution to see your name in lights and I would like them to stay. So, on the second side.. I guess, to what extent do we validate email information? I agree that requiring commons-validator seems a bit much for a small project like [email] just to use it. On the other hand, it does wrap the functionatliy up. Can you think of way to have our cake and eat it too? In other words, what is involved in maybe adding some sort of email validator decorate/helper class? Maybe something in a contrib directory showing how to do it.. [email] should remain small, and having a dependency on commons-validator is a lot... Eric PS, please tag your emails with [email], many folks filter on that type of tag in commons! -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 9:25 AM To: 'Jakarta Commons Developers List' Subject: RE: Validator inside of Email.java (RE: [email] Dumbster failing) Want to say: A object represented by a clazz (subclass) of Email should be a valid Email. The validation should be done *before* creating an object of that class. -Matthias -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 9:09 AM To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: Validator inside of Email.java (RE: [email] Dumbster failing) Hi Eric, I just update my email sources. and looked abit on the patches you are submitting. Cool to have some unittest. Btw. I saw that EmailValidator of Commons Validator is used inside of Email.java; Does it realy make sence to validate an e-mail inside that class? shouldn't this work be done outside? eg. enter e-mail via Struts (validate it) in action.clazz passing the String to the class that is using [email] ? Just my thought. Btw. what should we do with the @author tags? since some projects of Apache/Jakarta are removing them. Regards, Matthias -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 11:35 PM Cc: Jakarta Commons Developers List Subject: RE: [email] Dumbster failing Not a problem. I appreciate your working with me on this. I am looking forward to getting [email] whipped into shape! ERi -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 7:21 PM To: [EMAIL PROTECTED] Cc: Jakarta Commons Developers List Subject: Re: [email] Dumbster failing Ok, I have the tests all up and running with Maven. I have also made some minor mods, based on the tests or improving the input checking (this is why some of the tests are failing, there where against my changes not the HEAD version sorry) So once we get this formatting issue sorted, I will submit to you the new patch. This should raise the test coverage to 90+% for all (non-deprecated) classes. Thanks, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Validator inside of Email.java (RE: [email] Dumbster failing)
I think the question is the extra dependency.. Is it worth it? And, is there a way to make it optional? I actually am now back to the it should be optional as the validator class for emails has bugs against it for new email types. I think 4 letter suffixes don't pass for example.. However, for other types that don't require an extra dependency, I see it being worth having the extra checks. -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 10:04 AM To: Jakarta Commons Developers List Subject: Re: Validator inside of Email.java (RE: [email] Dumbster failing) Matthias, I definately agree with you, inputs (emails in this case) should be validated before submission to a low level api such as [email]. However I added the validation just to make sure. I guess you could call it 'defensive' coding. I am happy to remove this and numerous other input checks that I have added to the email project if this is the general consensus, however I will strongly recommend that it not be removed. As saying goes its better to be safe then sorry right? Regards, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Anyone interested?
I guess it depends on the scope of the extra dependencies and functionality. This sounds like it's within the scope of [email]. It isnt called [sendemail]!Also, is this starting to intrude on the space that James has? Not looking to create a mail server, or anything. You may want to look at http://james.apache.org/ for ideas. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 10:27 AM To: Jakarta Commons Developers List Subject: [email] Anyone interested? Is anyone interested in a set of wrapper classes around the rest of the Mail API, naming for the receiving of email? As email is intended to be small maybe this would consistute a new project? Just interested to hear anyones thoughts (positive or negative welcome :-D) -Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Anyone interested?
Well.. As we add functionalty, it will drag along the dependencies. Which is okay if they aren't mandated. For example, in [configuration] you need very little for the base function. But, as you add in Configuration objects backed by JNDI, Databases, Servlet web.xml, etc, you need more and more. This is address partly by just documentation: http://jakarta.apache.org/commons/configuration/dependencies.html So, I am okay I guess with adding configuration/digester/etc. As long as the core API doesn't require it. I guess it comes down to the fact that things like configuration are orthongonal (?) to what email is. Lets add the functionality, but lets not mandate it. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 11:57 AM To: Jakarta Commons Developers List Subject: Re: [email] Anyone interested? I definately don't want to create a mail server :-) Actually I was thinking of something similar to a simple set of functions similar to the way that PHP has wrappers on the IMAP lib (ftp://ftp.cac.washington.edu/imap/) Maybe James takes care of this already, I am not certain. As to adding XML config, I am for it, but there was a recently discussion about this and it seemed that is may not be wanted. My major concern with adding it would be that my first stop would be use digester for parsing the XML file and that adds dependancies again!! Is there anyway anyone can think of to keep the [email] project as is (small and compact) and yet add all of these optional or nice to have functions? This way those that wanted the small compact version wouldnt be burdened with all the extra dependancies and features that they have no need for. -Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Anyone interested?
Bases on the release early, release often criteria, maybe it makes sense to get the rest of Corey's unit tests patches in, and spend a bit of time verifing all the javadocs etc. Then do a 1.0 of whats there. That way we don't have to be quite as contrained by the existing API, as projects that depend on email will have a nice released version that they can use. This also might be the time to migrate out of the sandbox? -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:44 PM To: 'Jakarta Commons Developers List'; 'Corey Scott' Subject: RE: [email] Anyone interested? my +1 too -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 3:29 PM To: Jakarta Commons Developers List Subject: Re: [email] Anyone interested? I think this is a great idea!! -Corey Hi, These ideas are all very interesting. I would just caution against falling into the same pits experienced by [configuration] and [math]: that is, endlessly debating/adding features, refactoring, etc, before ever making a release. It might be good to get a 1.0 release out there and then discuss/act upon these new ideas for 1.1 or 2.0. Release early, release often is always my vote ;) Yoav Shapira http://www.yoavshapira.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [configuration] Any reason why JNDIConfiguration is readonly?
It should be.. However, I found it a real pain.. I think I need to really sit down and learn JNDI.. Write some unit tests of parsing the tree etc.. I thought it would be a simple matter, ended up not being. Not, I think, because of complexity, but just my own knowhow of JNDI. Does anyone have a good reference to what the various things in JNDI are? Name and Contexts etc...? Most of the howto's I found seem too basic for me.. Eric -Original Message- From: Oliver Heger [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 7:49 AM To: Jakarta Commons Developers List Subject: Re: [configuration] Any reason why JNDIConfiguration is readonly? Hmm, navigating through a tree based on a configuration key, creating missing nodes if necessary and finally storing the value... Similar code is contained in HierarchicalConfiguration and I suppose in XMLConfiguration, too, to update the internally used DOM tree. I wonder if this could be generalized. Oliver Eric Pugh wrote: Well.. I started on the bind/rebind stuff. and am having a really hard time of it... I can bind a property like this newprop just fine.. However, a property like my.newprop fails.. I think I need to crawl the tree and find the correct context and then set that... argh.. I don't just want to save in a temporary storage because I want to be able to persist via JNDI configuration changes. Eric -Original Message- From: Emmanuel Bourg [mailto:[EMAIL PROTECTED] Sent: Monday, October 25, 2004 5:54 PM To: Jakarta Commons Developers List Subject: Re: [configuration] Any reason why JNDIConfiguration is readonly? Eric Pugh wrote: Anyone have a good reason whe JNDIConfiguration doesn't support setting properties? I was thinking of going for just a simple string storing of properties, not binding in Datasources or anything funky like that... Eric How to you plan to implement this ? By playing with the bind/rebind/unbind functions of the Context interface, or by storing the new properties into a Map ? Emmanuel Bourg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Align Commons Build and Commons Sandbox Build?
Hi all, Running into some annoying Maven problems w/ [email]. Dug into it and discovered that the jakarta-commons/commons-build is quite different from jakarta-commons-sandbox/sandbox-build files. This means that a project graduating from sandbox will build differently then expected. I'd like to change sandbox-build POM to match commons-build POM. Opinions? Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] test cases
All but the EmailTest should run.. Dumbster [1] fakes out your SMTP server, so you don't even need one. Of course, I am not sure what happens if you have a real smtp server running on port 25 and you use Dumbster. I assume you are running under Maven? Run maven test and most should work. Eric [1] http://www.quintanasoft.com/dumbster/ -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 1:49 PM To: Commons dev list Subject: [email] test cases Should these test cases work (after editing the EmailConfig test class)? I had most of them working yesterday enough to mail me the test mails, but today i cant get them doing anything. I have an smtp service running locally, but is this being done by this dumpster thing now? Anything you could do to help be get these cases working would be great. All of them are related to the Test classes themselves not the actual code they are testing. Once I have a clearer idea what could be up i'll be able to enter a bug report, but i don't even have that amount of clarity yet. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Align Commons Build and Commons Sandbox Build?
Okay.. I will go ahead and make the changes.. I think, so that you don't have to check out both, that they are seperate. But, they should still be pretty simiar in terms of what the basic POM offers. ERic -Original Message- From: Tim Reilly [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 9:29 PM To: Jakarta Commons Developers List Subject: Re: Align Commons Build and Commons Sandbox Build? On Wed, 27 Oct 2004 11:15:25 +0200, Eric Pugh wrote: Hi all, Running into some annoying Maven problems w/ [email]. Dug into it and discovered that the jakarta-commons/commons-build is quite different from jakarta-commons-sandbox/sandbox-build files. This means that a project graduating from sandbox will build differently then expected. I'd like to change sandbox-build POM to match commons-build POM. Opinions? Eric I've lost track of what's going on. I see some sandbox projects build off commons-build and some off sandbox-build? Which is correct? If they are synchronized that would be great. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] and net
Thanks.. I'll take a look at it. One of our objectives of 1.0 is to get something out soon. So we may put integration/reuse of net stuff for 1.1. But anything that gives ideas is great! -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich Sent: Thursday, October 28, 2004 3:40 AM To: [EMAIL PROTECTED] Subject: Re: [email] and net to the people of thinking of releaseing email: I think a lot more work is in net's smtp package such as simple emailer. So, maybe build on that,that is a superset. just in case you missed it. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] test cases
Also, isn't there a debug setting that you can use so you see the output of the STMP connection? Try that as well.. -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 4:14 PM To: Jakarta Commons Developers List; Mark Lowe Subject: Re: [email] test cases Do you have anymore info on why the tests are failing? If it the previous set of tests (before last nights updates) then it is probably due to some validation that was missing in one of the patches and should now be there. Namely, throwing exceptions on bad inputs like a null message. Other than that it I am can only think of a few places i have come accross this: 1) it may be an issue caused by the server requiring authentication and it not being set. 2) I thought that I had some problem running the tests with maven at one time, I never confirmed this, so this is unlikely 3) it may just be the tests that were testing the email validation and since that was removed they are failing as SMTP servers (atleast dumbster) is NOT throwing a messaging exception on invalid addresses I had expected. All that said, I have not being experiencing these troubles, I even rechecked out the project and applied the last patch that I submitted into a new project and it was all still ok. I will check it out again and see what I can find. Regards, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] test cases
I can see the value of *actually* recieving the email. I think we could add it commented out to project.xml. And a FAQ entry (xdocs/faq.fml) about swapping between dumbster and really sending emails... Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 3:23 AM To: Jakarta Commons Developers List; Mark Lowe Subject: Re: [email] test cases It doesnt use smtp.jar, right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 31934] - [mail] No smtp.jar in dependencies list
However, doesn't dumbster do that? From the examples (http://www.quintanasoft.com/dumbster/#Examples) server.stop(); assertTrue(server.getReceievedEmailSize() == 1); Iterator emailIter = server.getReceivedEmail(); SmtpMessage email = (SmtpMessage)emailIter.next(); assertTrue(email.getHeaderValue(Subject).equals(Test)); assertTrue(email.getBody().equals(Test Body)); Couldn't we do it right there? Do something like write out the content to /target/emailout/ Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 3:32 AM To: Jakarta Commons Developers List Subject: Re: DO NOT REPLY [Bug 31934] - [mail] No smtp.jar in dependencies list We may also find that the mail.jar has an API for retrieving messages from a mail server, may be can use this rather than adding a new jar? What do you feel about saving the output of the tests to a file (mail messages) only. This way one could check the output without and connection and without spamming yourself. Thanks, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] test cases
Alright.. I've made some progress. I refactored all the unit tests to extend from BaseEmailTestCase. BaseEmailTestCase contains the various bits of shared code. It also starts and stops dumbster. So, on to my problem... I added an example of Dumster being quried for the email, and validating the subject. It also writes the email out to /target/test-emails as a .txt file. Look at TestEmail.testSend. If you JUST run that method, everything works great. If you run everything, dumbster seems to fail. I am still digging through it. At any rate, Mark, would writing the email out like that solve your needs? I know it's frustrating getting everything setup, but don't give up! Eric -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 12:16 PM To: Jakarta Commons Developers List Subject: Re: [email] test cases Thinking about it , if a simple swing app could be fired up (like junit (test:ui)) then that could be used for testing the output without using an smtp server, perhaps even just something that can render and output to a image or pdf. I'll have a read around. On Fri, 29 Oct 2004 11:39:29 +0200, Mark Lowe [EMAIL PROTECTED] wrote: The smtp jar does seem required to run the tests and only have them failing rather than throwing errors. The mail api seems to have trouble throwing a UnsupportedEncodingException. But this isn't really a test case issue, as the unit test correctly report that no exception is thrown. Mark On Fri, 29 Oct 2004 11:20:54 +0200, Eric Pugh [EMAIL PROTECTED] wrote: I can see the value of *actually* recieving the email. I think we could add it commented out to project.xml. And a FAQ entry (xdocs/faq.fml) about swapping between dumbster and really sending emails... Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 3:23 AM To: Jakarta Commons Developers List; Mark Lowe Subject: Re: [email] test cases It doesnt use smtp.jar, right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] test cases
By playing games with starting and stopping dumbster, it now outputs the text in /target/test-emails. The other sending targets fail due to missing content errors. I am now getting 8 failures and 1 error. I have pasted below the errors that I am getting. It would be nice if someone can verify that they are getting the same ones! Since we are getting known errors, I tweaked maven to ignore errors and failures so you can generate the docs by just running maven site. Eric Failure details testSetFrom2 Should have thrown an exception junit.framework.AssertionFailedError: Should have thrown an exception at org.apache.commons.mail.EmailTest.testSetFrom2(EmailTest.java:420) testAddTo2 Should have thrown an exception junit.framework.AssertionFailedError: Should have thrown an exception at org.apache.commons.mail.EmailTest.testAddTo2(EmailTest.java:582) testAddCc2 Should have thrown an exception junit.framework.AssertionFailedError: Should have thrown an exception at org.apache.commons.mail.EmailTest.testAddCc2(EmailTest.java:822) testAddBcc2 Should have thrown an exception junit.framework.AssertionFailedError: Should have thrown an exception at org.apache.commons.mail.EmailTest.testAddBcc2(EmailTest.java:1050) testAddReplyTo2 Should have thrown an exception junit.framework.AssertionFailedError: Should have thrown an exception at org.apache.commons.mail.EmailTest.testAddReplyTo2(EmailTest.java:1291) testSend Unexpected exception thrown junit.framework.AssertionFailedError: Unexpected exception thrown at org.apache.commons.mail.HtmlEmailTest.testSend(HtmlEmailTest.java:204) testGetSetMsg N/A java.lang.NullPointerException at java.lang.String.indexOf(String.java:1236) at java.lang.String.indexOf(String.java:1218) at org.apache.commons.mail.HtmlEmailTest.testGetSetMsg(HtmlEmailTest.java:88) testSend Unexpected exception thrown junit.framework.AssertionFailedError: Unexpected exception thrown at org.apache.commons.mail.MultiPartEmailTest.testSend(MultiPartEmailTest.java: 185) testSetMsg expected: but was:null junit.framework.ComparisonFailure: expected: but was:null at org.apache.commons.mail.MultiPartEmailTest.testSetMsg(MultiPartEmailTest.jav a:86) -Original Message- From: Eric Pugh [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 1:39 PM To: Jakarta Commons Developers List; Mark Lowe Subject: RE: [email] test cases Alright.. I've made some progress. I refactored all the unit tests to extend from BaseEmailTestCase. BaseEmailTestCase contains the various bits of shared code. It also starts and stops dumbster. So, on to my problem... I added an example of Dumster being quried for the email, and validating the subject. It also writes the email out to /target/test-emails as a .txt file. Look at TestEmail.testSend. If you JUST run that method, everything works great. If you run everything, dumbster seems to fail. I am still digging through it. At any rate, Mark, would writing the email out like that solve your needs? I know it's frustrating getting everything setup, but don't give up! Eric -Original Message- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 12:16 PM To: Jakarta Commons Developers List Subject: Re: [email] test cases Thinking about it , if a simple swing app could be fired up (like junit (test:ui)) then that could be used for testing the output without using an smtp server, perhaps even just something that can render and output to a image or pdf. I'll have a read around. On Fri, 29 Oct 2004 11:39:29 +0200, Mark Lowe [EMAIL PROTECTED] wrote: The smtp jar does seem required to run the tests and only have them failing rather than throwing errors. The mail api seems to have trouble throwing a UnsupportedEncodingException. But this isn't really a test case issue, as the unit test correctly report that no exception is thrown. Mark On Fri, 29 Oct 2004 11:20:54 +0200, Eric Pugh [EMAIL PROTECTED] wrote: I can see the value of *actually* recieving the email. I think we could add it commented out to project.xml. And a FAQ entry (xdocs/faq.fml) about swapping between dumbster and really sending emails... Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 3:23 AM To: Jakarta Commons Developers List; Mark Lowe Subject: Re: [email] test cases It doesnt use smtp.jar, right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
RE: [email] test cases
Cool.. I think you know then the path to fix the rest? The unicode seems to make sense to me. On the second part, is there ever a time we would want to send a null message? I can't think of one really, and the point of Email is to hide the complexity from you, so that sounds good to me.. Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 4:05 PM To: Jakarta Commons Developers List Subject: Re: [email] test cases Guys, I need some guidance. The test cases mentioned are failing for a couple of reasons. The ones that are failing are doing so because the personal names are still using ? instead of an invalid unicode character, we can replace them with something like \uc5ec (this is korean i believe) they will then pass properly. One of the others is failing due to lack of content and this is because the functions are allowing this to set, I would like to propose changing the (MultipartEmail) setMsg, setHTML, etc. to throw a MessagingException on null message. This will bring them in line with HtmlEmail which is already doing this. This would also mean changing the test array of strings (thanks eric!!!) by removing the null. If this is all ok, I will happily generate a patch for these changes. Thanks, Corey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] test cases
Since I can't seem to apply a patch cleanly this week, sure, send it all in one. I have thought about the string compare approach, but often that can be very brittle. It's so easy for some environmental thing to happen and cause and extra or whatnot to creep in, and then it fails. Also, its a bunch more external files to keep up to date. However, w/ dumbster, we can manualy check stuff within the test. If you look at the EmailTest, I check the subject. We could do something like assertTrue(getBody().indexOf(my message)0) and that would work. Try the .eml, and lets see! Eric -Original Message- From: Corey Scott [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 5:11 PM To: [EMAIL PROTECTED] Cc: Jakarta Commons Developers List Subject: Re: [email] test cases We have quite a few style violations that have crept back in, do you mind if i fix those as well? Do you recommend a separate patch? If it is ok with you, i would rather submit one patch for all of it cause stuff keeps getting lost :-) Thanks for the advice, Corey PS. I will try to take you lead with the validation of the email contents from dumbster. I think that we might also find that if we say emails to .eml (i think) then most windows clients should open them up automatically. What do you think about making a set of expected outputs (files) and then doing a plain string compare? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Remove commons-xo from Gump?
Hi all, I'd like to broach removing commons-xo from Gump. It is currently listed as having 2 dependees, and I am pretty sure that is referring to jakarta-turbine-3 and jakarta-turbine-2. Jakarta-turbine-2 just removed the commons-xo dependency, and jakarta-turbine-3 will soon follow suit. In fact, on a more general topic, I would argue that any sandbox project should not be in Gump, but I'll save that for another day.. So, commons-xo out of gump? I'll make sure it doesn't break anyone. Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
