Re: [dbutils] Opinions on 1.1 RC1
Henri, I haven't been keeping up with DBUtils lately but it would be great to get an official 1.1 released so we don't have to use the nightlies. The API diff you posted looked fine to me. The website hasn't been updated in a long time though. I can drop in the RC1 jar at work on Monday for some quick tests. Thanks, David http://thingsidontneedtobehappy.com/ --- Henri Yandell [EMAIL PROTECTED] wrote: I've prepared 1.1-RC1 for DbUtils. http://people.apache.org/~bayard/commons-dbutils/1.1-RC1/ It was built under 1.4 on OS X. 'ant clean test' passes under 1.3. Any obvious problems before I call a vote? Hen __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DbUtils] Generic BasicRowProcessor toBeanList
Not only do you lose compatibility you also ugly up the code with generics and introduce a bunch of complexity. I have heard from many dbutils users that they like the package because it's simple and easy to use. If people would like to use another library because dbutils doesn't have generics, we're not stopping them. Many of us enjoy how simple dbutils is to use today. I'm using it in Java 1.4 and 1.5 projects at the moment with no problems. David - Original Message From: Thomas Mueller [EMAIL PROTECTED] To: commons-dev@jakarta.apache.org Sent: Wednesday, July 12, 2006 1:26:33 AM Subject: Re: [DbUtils] Generic BasicRowProcessor toBeanList You would lose backwards compatibility with 1.3 and 1.4. Sure, at least at compile time (I'm sure about runtime, as I said I'm not a generics expert). The 'generic' version(s) could be in another package or class clearly marked as that. For example org.apache.commons.dbutils.generic.BasicRowProcessor or org.apache.commons.dbutils.GenericBasicRowProcessor It looks a little verbose, and maybe somebody finds a better solution. But at some point you have to make the switch to JDK 1.5. This here may not be the most important case, but you have to start somewhere. Otherwise, people will use another library (= not use the commons libraries) for JDK 1.5. Thomas -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! Feel free mit GMX DSL! http://www.gmx.net/de/go/dsl - 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: [dbutils] toMap conversion (bug)
We don't use LinkedHashMap because we depend on Java 1.3 not 1.4. Nobody
really uses 1.3 anymore so it wouldn't be so bad to use LinkedHashMap in a
future release.
David
--- Tomáš Procházka [EMAIL PROTECTED] wrote:
Hi.
I found some problem with toMap conversion, it use HashMap, but this
collection not preserve order of items, which is sometimes useful. Why
you don't use LinkedHashMap in
http://cvs.apache.org/viewcvs.cgi/jakarta/commons/proper/dbutils/trunk/src/java/org/apache/commons/dbutils/BasicRowProcessor.java?view=markup
on the line:
private static class CaseInsensitiveHashMap extends HashMap {
What is yours opinion?
--
Tomas Prochazka
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Get Firefox!
http://www.mozilla.com/firefox/
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][POLL] What JDK Version are you using?
Niall, I code to the 1.4 API but deploy on 1.5 when possible. Moving off 1.3 is safe because: 1. 1.3 is not supported by Sun anymore. 2. Struts requires 1.4 and Validator is primarily used by Struts folks. Sure there are some that use it standalone but the percentage of total users is miniscule. 3. 1.3 users will always have the older releases of Validator to use. They won't get the new features but they should be used to that since they're using Java 1.3. David --- Niall Pemberton [EMAIL PROTECTED] wrote: What JDK version are you using? - [ ] JDK 1.2 [ ] JDK 1.3 [X] JDK 1.4 [X] JDK 1.5 (or JDK 5) - I'm mainly interested in the impact of moving Commons Valdator a minimum dependency of JDK 1.4 to use the RegExp support rather than depending on ORO. However, other commons components may be interested in your answer, so it would be useful if you could indicate which Commons components you are using (or interested in using), especially Validator :-) tia Niall Get Firefox! http://www.mozilla.com/firefox/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] New routines package and plans
Re the ORO dependency: It can be avoided if we use the Java 1.4 java.util.regex package. It's much faster than ORO in the testing I did a year ago. I would love to drop the ORO dependency to make the Validator distro lighter. David --- Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/22/06, Niall Pemberton [EMAIL PROTECTED] wrote: Commons validator serves two functions: 1) To provide validation routines 2) To provide a mini validation framework I'd like to more clearly separate out these two aspects, so as a first step in this process I have created a new routines package with the intention that validation routines, which can be used on their own, with no other dependencies are all moved into that package. snip/ I'd be interested in the separation to the point of a routines jar, needing nothing beyond the JDK (just as the routines package you've created does as of today). The next stage would be to move other validators (i.e. credit card, ISBN, Email and URL) into this package (with some refactoring). snap/ Do you think this will need to pull in the oro dependency? Can it be avoided? ;-) Once thats done, I'd like to start work on tackling the framework's short comings. I've probably used up my open source cycles for a little while - but I hope to keep returning chipping away at this. Opinions/comments welcome. snip/ Good stuff, IMO. -Rahul Niall Get Firefox! http://www.mozilla.com/firefox/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DbUtils] Dynamic wrappers for JDBC interfaces
I think this task is already completed. Take a look at the ProxyFactory class: http://jakarta.apache.org/commons/dbutils/xref/org/apache/commons/dbutils/ProxyFactory.html David --- Neeraj Kulkarni [EMAIL PROTECTED] wrote: Hi, The DbUtils website mentions one of the tasks as Dynamic Wrappers for JDBC Interfaces. http://jakarta.apache.org/commons/dbutils/todo.html Can someone provide more detains on what exactly is required to be done? Thanks Neeraj Get Firefox! http://www.mozilla.org/firefox/ __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] Towards a release
If I remember right, 1.2 (HEAD) includes form inheritance which wasn't widely tested. Niall might remember more details. I think releasing 1.2.0 from HEAD would be fine so we don't have to go through the error prone process of maintaining two branches. Thanks for picking up the Validator torch! David --- Don Brown [EMAIL PROTECTED] wrote: I'd like to get a release of commons-validator out the door, as Struts 1.3 would like to use some of its new bug fixes and features. I'm pretty new to validator, so I'm not familar with its history. Any reason we haven't released 1.2? In the past when I fixed bugs, folks backported them to the 1.1.x branch; why not just roll 1.2 or at least roll it in addition to a bug fix release for 1.1.x? There are a couple more validator open bugs that I can sew up, if I saw a release as a near-term possibility. LMK, thanks, Don Get Firefox! http://www.mozilla.org/firefox/ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] SystemDataSource
For some reason the website is distributed with the C3P0 download. It contains great docs on how to setup the parameters. I've been using it in production with Hibernate for over a year and it works great. David --- Henri Yandell [EMAIL PROTECTED] wrote: On 8/4/05, David Graham [EMAIL PROTECTED] wrote: Why not just use a real DataSource from C3P0 or Proxool? They're fully featured and easy to setup. DbUtils was already in the classpath :) They'd be getting replaced by the target containers DataSource, I just needed something to get the code deployed before the target container has been chosen. Also, we should not use properties named jdbc.* as they are potentially used by drivers. Thanks, will change that. http://sourceforge.net/projects/c3p0 No real website :) http://proxool.sourceforge.net/ Now this I like. You're right that I should be doing the slightly more work of hooking this up (previously it would have been poolman or simple-jndi) instead of my proposed simple dbutils approach. Hen Get Firefox! http://www.mozilla.org/firefox/ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] SystemDataSource
Why not just use a real DataSource from C3P0 or Proxool? They're fully
featured and easy to setup. Also, we should not use properties named
jdbc.* as they are potentially used by drivers.
http://sourceforge.net/projects/c3p0
http://proxool.sourceforge.net/
David
--- Henri Yandell [EMAIL PROTECTED] wrote:
Just had need to hack together a simple DataSource class and wondered
if it would fit nicely in dbutils. Name is either SystemDataSource
(after SystemClassLoader) or DriverManagerDataSource, it uses Java -D
properties and the DriverManager, so is very lightweight and something
nice to start with before moving up to a container that supplies a
real DataSource.
I imagine there are MockDataSources out there that are similar too for
unit testing, but nothing in DbUtils yet.
(code follows, it's pretty dumb)
public class SystemDataSource implements DataSource {
private String driver = System.getProperty(jdbc.driver);
private String username = System.getProperty(jdbc.user);
private String password = System.getProperty(jdbc.password);
private String uri = System.getProperty(jdbc.uri);
public SystemDataSource() {
DbUtils.loadDriver(driver);
}
public Connection getConnection() throws SQLException {
return DriverManager.getConnection(this.uri, this.username,
this.password);
}
public Connection getConnection(String username, String password)
throws SQLException {
return DriverManager.getConnection(this.uri, username,
password);
}
public PrintWriter getLogWriter() throws SQLException {
return DriverManager.getLogWriter();
}
public void setLogWriter(PrintWriter logWriter) throws SQLException
{
DriverManager.setLogWriter(logWriter);
}
public void setLoginTimeout(int timeout) throws SQLException {
DriverManager.setLoginTimeout(timeout);
}
public int getLoginTimeout() throws SQLException {
return DriverManager.getLoginTimeout();
}
}
Get Firefox!
http://www.mozilla.org/firefox/
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: need help from a commons committer
Patches aren't committed just because they're available. They need to make sense in the overall project and add some value. Please see my comments in bugzilla related to why this hasn't been added. David --- Kyle Miller [EMAIL PROTECTED] wrote: I have posted a couple of emails trying to get some dbutils enhancements accepted. Unfortunately it looks like there is no one activily developing / supporting DBUtils. There doesn't look like there has been an update to the code since 02/19/2005 from David Graham. I originally submitted this enhance 02/09/2005. The release 1.0 came out on 2003-11-10, release 1.1 has been in dev ever since. There are currently 5 enhancement requests including mine, a couple have code attached and the others are requests for enhancements. I would like to get my enhancements accepted (http://issues.apache.org/bugzilla/show_bug.cgi?id=33477) as it would add stored procedure support to DBUtils which currently doesn't have any support for stored procedures. I would also like to implement the other enhancement requests, but I'm not going to if there is no one to review / accept them. I think we should implement the outstanding enhancements and patches and make a 1.1 release. Though I will help from someone whom is a committer. Is anyone willing to help me? Get Firefox! http://www.mozilla.org/firefox/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SVN From Eclipse is too slow
I can top that one. Subclipse deleted a file from the repository when all I tried to do was commit a change. It was lucky I noticed the delete and recommitted the file. I also have the horrible performance problems. David --- Gary Gregory [EMAIL PROTECTED] wrote: Hello: I see an even worse behavior: I have all of proper trunk of Jakarta Commons loaded in one project with Eclipse 3.1M6. Before any commits it seems to do a refresh of the whole project, which takes *forever*. I am not sure if this is an SVN problem rather than a Subclipse problem. Gary -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Thursday, April 21, 2005 9:09 PM To: Jakarta Commons Developers List Subject: SVN From Eclipse is too slow Is it just me or is SVN itself mind bogglingly slow? I am doing an Update on commons/jelly from inside eclipse 3.1M4 and it takes a lot longer than CVS ever did. -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] External and Internal API's
Eclipse also has a special way of sharing classes with other plugins. You can prevent outside plugins from using internal packages by tweaking the export definition in plugin.xml: runtime library name=something.jar export name=*/ /library /runtime That seems to be the primary benefit to adding an internal package prefix. Without the extra functionality provided by Eclipse it's only use is for documentation. In that case, you may as well just add a note to the javadoc like, This class is not part of the public API instead of mangling the package names. David --- Mark Diggory [EMAIL PROTECTED] wrote: I've been working with the Eclipse SDK quite a bit lately, Eclipse has a coding standard where they divide the API up into external and internal API's. Internal API's are subject to change, while External API's are more stable and regulated. The division of these API's is usually: External API: org.foo.bar Internal API: org.foo.bar.internal Theses are similar to Interface and Implementation but without the association to OO Class/Interface terms already having specific definitions. I think this is very savvy concept for managing the codebase. I wonder if this is an idea that would be of benefit if implemented in the commons? Is this approach already used in some commons components? -Mark __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] Most tests are failing
All of the tests pass for me after you applied the latest patch. Thanks! David --- Niall Pemberton [EMAIL PROTECTED] wrote: David, It is failing because of the changes I rolled back for Field - I didn't roll back the associated change to Arg. Sorry about that, I did think Iwas going to be applying a solution for Bug 31194 at the end of last year. I have it all ready to go (I've just attached a patch showing what I'm currently proposing to the bugzilla ticket). http://issues.apache.org/bugzilla/show_bug.cgi?id=31194 My preference is to apply the latest change I've put forward and that should resolve 31194 and the problems you're having with testing. If you don't want to or don't have time to consider this and want me to hold off - I can revert back the changes to Arg. It would be good IMO to put 31194 to bed, but let me know. Niall - Original Message - From: David Graham [EMAIL PROTECTED] Sent: Saturday, February 12, 2005 8:52 PM Thanks Niall. Once all the tests pass I can commit some minor changes I'm working on. David --- Niall Pemberton [EMAIL PROTECTED] wrote: This is may be because I rolled back the changes to Field for Bug 31194 http://issues.apache.org/bugzilla/show_bug.cgi?id=31194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[validator] Most tests are failing
Most of Validator's JUnit tests fail with the stack trace below. Is it just that I am missing a classpath setting or is the code actually broken? They fail when running from Eclipse and 'maven dist'. Thanks, David java.lang.ArrayIndexOutOfBoundsException: -1 at org.apache.commons.digester.Digester.createSAXException(Digester.java:2792) at org.apache.commons.digester.Digester.createSAXException(Digester.java:2818) at org.apache.commons.digester.Digester.endElement(Digester.java:1070) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1712) at org.apache.crimson.parser.Parser2.content(Parser2.java:1963) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691) at org.apache.crimson.parser.Parser2.content(Parser2.java:1963) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691) at org.apache.crimson.parser.Parser2.content(Parser2.java:1963) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691) at org.apache.crimson.parser.Parser2.content(Parser2.java:1963) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:667) at org.apache.crimson.parser.Parser2.parse(Parser2.java:337) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448) at org.apache.commons.digester.Digester.parse(Digester.java:1591) at org.apache.commons.validator.ValidatorResources.init(ValidatorResources.java:158) at org.apache.commons.validator.ValidatorResources.init(ValidatorResources.java:123) at org.apache.commons.validator.TestCommon.loadResources(TestCommon.java:54) at org.apache.commons.validator.RequiredNameTest.setUp(RequiredNameTest.java:77) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:421) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:305) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:186) __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] Most tests are failing
Thanks Niall. Once all the tests pass I can commit some minor changes I'm working on. David --- Niall Pemberton [EMAIL PROTECTED] wrote: This is may be because I rolled back the changes to Field for Bug 31194 http://issues.apache.org/bugzilla/show_bug.cgi?id=31194 although I thought that only FieldTest (which I didn't roll back the changes for) would fail because of this. I was going to change FieldTest if/when it was agreed what I was proposing for 31194. I'll give the tests a run and see if I get the same as you. It will take me longer than usual, since I haven't moved to using SVN for Validator yet. Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: commons-dev@jakarta.apache.org Sent: Saturday, February 12, 2005 8:02 PM Subject: [validator] Most tests are failing Most of Validator's JUnit tests fail with the stack trace below. Is it just that I am missing a classpath setting or is the code actually broken? They fail when running from Eclipse and 'maven dist'. Thanks, David java.lang.ArrayIndexOutOfBoundsException: -1 at org.apache.commons.digester.Digester.createSAXException(Digester.java:2792) at org.apache.commons.digester.Digester.createSAXException(Digester.java:2818) at org.apache.commons.digester.Digester.endElement(Digester.java:1070) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1712) at org.apache.crimson.parser.Parser2.content(Parser2.java:1963) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691) at org.apache.crimson.parser.Parser2.content(Parser2.java:1963) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691) at org.apache.crimson.parser.Parser2.content(Parser2.java:1963) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691) at org.apache.crimson.parser.Parser2.content(Parser2.java:1963) at org.apache.crimson.parser.Parser2.maybeElement(Parser2.java:1691) at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:667) at org.apache.crimson.parser.Parser2.parse(Parser2.java:337) at org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:448) at org.apache.commons.digester.Digester.parse(Digester.java:1591) at org.apache.commons.validator.ValidatorResources.init(ValidatorResources.ja va:158) at org.apache.commons.validator.ValidatorResources.init(ValidatorResources.ja va:123) at org.apache.commons.validator.TestCommon.loadResources(TestCommon.java:54) at org.apache.commons.validator.RequiredNameTest.setUp(RequiredNameTest.java:77 ) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu nner.java:421) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner. java:305) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner .java:186) __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrency and starting a synchronized block
--- Stephen Colebourne [EMAIL PROTECTED] wrote: From: Torsten Curdt [EMAIL PROTECTED] Regarding the FastHashMap: since the use is more or less discouraged ...why not deprecate it? Because it works on everything that its been tried on. It's more like no one has ever noticed it breaking. I'm not certain whether we know it actually works. No-ones ever reported a bug, its just that with all the double-checked locking theoretical ideas we have to be cautious. I believe that other parts of commons, including some used by struts, use FastHashMap for example. Unfortunately, Commons Validator still uses FastHashMap in some protected instance variables where changing them to Map references might break subclasses. We have deprecated their usage and will be removing them in future releases. David Stephen __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: concurrency and starting a synchronized block
A call to Map.get() may depend on state that can be corrupted by a
concurrent call to Map.put(). You don't know without learning the
implementation details of get(). So, you need to synchronize around both
operations:
synchronized(map) {
Object o = map.get(key);
if (o == null) {
map.put(key,new Object());
}
}
Have you identified this one synchronized block as a bottleneck in your
application with performance testing? If not, then why are you worrying
about making micro optimizations that may or may not benefit the
application?
FastHashMap states it is not portable in its javadoc so it should never be
used. Using non-portable classes defeats the entire purpose of using
Java.
David
--- Torsten Curdt [EMAIL PROTECTED] wrote:
Guys, forgive me if this too off topic...
...but I thought it is somehow related to
collections that's why I am bringing it up
here anyway. I bet someone of you will know
Consider this code...
Object o = map.get(key);
if (o == null) {
synchronized(map) {
map.put(key,new Object());
}
}
99% of the time the gets on the map are going
to return an object. That's why I would like
to avoid synchronizing the get access.
Now since a put might corrupt the data it
has to be synchronized.
Since the get, the comparison and the put
are not in a synchronized block I might loose
objects ...but for this particular usecase
that's ok.
Now what really got me thinking is the
concurrent sychronized and non-synchronized
access.
What happens when Thread A is in doing a
get while Thread B is entering the
sychronized block for the put?
I assume that since the map object is not
locked it will go straight into the put
and bang ...right?
Somehow this looks like the optimal usecase
for the FastHashMap from collections ...but
since this code needs to be very portable
this might be a problem because of the
double-checked locking idiom.
Another option would be using the StaticBucketMap.
What do you guys think?
If you consider this too OT please reply off list.
cheers
--
Torsten
ATTACHMENT part 2 application/pgp-signature name=signature.asc
__
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP
--- Craig McClanahan [EMAIL PROTECTED] wrote:
Calling BasicDataSource.close() will only close the connections still
in the pool -- not the ones that have been checked out. It is
designed to be called only when your app is ready to shut down.
For normal usage, the best approach is something like this:
DataSource ds = ... get your data source reference;
Connection conn = null;
try {
conn = ds.getConnection();
... use the connection as needed ...
conn.close(); // Returns this connection to the pool
} catch (SQLException e) {
... deal with any exception ...
} finally {
if (conn != null) {
try {
conn.close();
} catch (SQLException e) {
...
}
}
}
It's this kind of drudgery that prompted me to volunteer on DbUtils.
Check it out if you're tired of JDBC resource cleanup.
http://jakarta.apache.org/commons/dbutils/
David
That way, you're always returning the connection to the pool, even if
an exception occurs while you're using it.
BTW, your MySQL admin will show active connections for all the entries
in the pool, as well as those that have been checked out and are in
use.
Craig
On Thu, 10 Feb 2005 10:14:17 -0800, Paul Hsu [EMAIL PROTECTED]
wrote:
Hi,
I have one question about DBCP. I like to know if any one have used
BasicDataSource.close(). In my program I set up a BasicDataSource and
get connection from MYSQL, I call BasicDataSource.close() right after
get connection, I still see the connectioin from MYSQL admin. I just
wonder this function is working?
thanks,
Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] Stored Procedure Runner and Bean Reuse Handler code submission
Open a new bugzilla ticket then attach the files to that. You can't attach files when you create the ticket so you'll need to save and go back to it to attach the files. Thanks, David --- Kyle Miller [EMAIL PROTECTED] wrote: I attached the files but they did not make it to the list. How do I submit multiple source files? --- Kyle Miller [EMAIL PROTECTED] wrote: I have attached two additions I think would be useful for DBUtils. First is a StoredProcRunner, I have it extending QueryRunner but only because I didn't want to change anything already in CVS. It is only a first cut and probably won't work for all Stored Procedures but it did work for mine, and I figured it would be a good place to start. I have also included a BeanReuseHandler so that QueryRunner can reuse a bean instead of creating a new one for every query. It was useful when I had to do a query, then some offline scrubbing before I had to do another query and add more info to the bean. I have also included junit tests, if you would like me to change anything I am willing, else I hope you find it useful. Kyle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] Stored Procedure Runner and Bean Reuse Handler code submission
Also, make sure the Apache 2.0 license header is in the source files like the other files in cvs. Thanks, David --- David Graham [EMAIL PROTECTED] wrote: Open a new bugzilla ticket then attach the files to that. You can't attach files when you create the ticket so you'll need to save and go back to it to attach the files. Thanks, David --- Kyle Miller [EMAIL PROTECTED] wrote: I attached the files but they did not make it to the list. How do I submit multiple source files? --- Kyle Miller [EMAIL PROTECTED] wrote: I have attached two additions I think would be useful for DBUtils. First is a StoredProcRunner, I have it extending QueryRunner but only because I didn't want to change anything already in CVS. It is only a first cut and probably won't work for all Stored Procedures but it did work for mine, and I figured it would be a good place to start. I have also included a BeanReuseHandler so that QueryRunner can reuse a bean instead of creating a new one for every query. It was useful when I had to do a query, then some offline scrubbing before I had to do another query and add more info to the bean. I have also included junit tests, if you would like me to change anything I am willing, else I hope you find it useful. Kyle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] component proposal
DbUtils is a small JDBC helper library. We don't implement features that already exist in the standard Java distro. David --- Anaximandro (Woody) [EMAIL PROTECTED] wrote: Hi folks, I dono if you are open for this idea or if this topic was already discussed but let me explain: I´m working on a project where I decide to use the pattern Data Transfer Rowset (a fast lane reader) given by Marinescu on book EJB Design Patterns. When I decided this (four months ago) I do some research and look for some open source implementations but the only implementation I found was the sun CachedRowset implementation (with SCSL license and, for java 1.4.2, the sources is unavailable). The version done by sun was done for use with java 1.4.2 (and I was using WAS 4, with java 1.3.1!!!) I faced many problems with this (and my envinronment) and, yet now, does not exist a CachedRowset implementation ... Months ago, when sun releases tiger, I try to see the sources looking for the CachedRowsetImpl but this source is not given yet (and, as I see, never will). I know there is another implementation, but is not open source too (is from oracle, with huge bugs). I think this is the right place to a component like this. I'm right? I have some work done in this direction and wanna knows if can I help (with hands on). Tks Woody - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all][VOTE] svn migration
+1 David --- Tim O'Brien [EMAIL PROTECTED] wrote: Alright a sufficient amount of time has passed for public comments and testing. This is a vote thread for migrating commons to SVN. If this vote passes, I'll contact Justin and schedule the least disruptive migration time possible. Tim O'Brien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Distributions to include dependencies?
It would certainly be helpful to our users to include the dependencies in
the distro. Otherwise, it's like trying to drive a car without the
wheels.
David
--- Henri Yandell [EMAIL PROTECTED] wrote:
Not a huge issue for things like Lang which have no dependencies, but
for other things like Digester I think it would be a lot better if the
binary tar.gz contained the jars it depends on?
So when I download digester-1.6, the tar.gz contains jars for
logging-1.0.3 and beanutils-1.7. We're not forcing those versions on
people, just providing them to save lots of searching around or
waiting while iBiblio responds.
It seems pretty easy to do too from a maven.xml point of view:
?xml version=1.0?
project xmlns:j=jelly:core xmlns:ant=jelly:ant
!--
description=Adds dependencies to distributions
--
postGoal name=dist:prepare-bin-filesystem
ant:mkdir dir=${maven.dist.bin.archive.dir}/dependencies/
j:forEach var=dep items=${pom.dependencies}
j:if test=${dep.getProperty('distributable')=='true'}
copy todir=${maven.dist.bin.archive.dir}/dependencies
file=${maven.repo.local}/${dep.getGroupId()}/jars/${dep.getArtifact()}/
/j:if
/j:forEach
/postGoal
/project
You'd just add:
properties
distributabletrue/distributable
/properties
to a dependency.
Anyone interested?
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
=
Get Firefox!
http://www.mozilla.org/firefox/
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
--- Matt Sgarlata [EMAIL PROTECTED] wrote: David Graham wrote: --- Daniel Florey [EMAIL PROTECTED] wrote: BTW: Another advantage of this approach would be that imports would indicate which version of the component is in use. I had a lot of trouble to find out, which version of jdom was in use by some libraries as this was not indicated by the name of the jar. The version may be listed in the manifest file. This is really pushing the limits of my classloading knowledge, but doesn't the Manifest just say which version you need to run? If two incompatible versions are specified by two different JARs, then you're still up a creek, right? If I understand this correctly, all the Manifest can do is make your application puke on startup instead of puking at runtime. It doesn't solve the problem of running two versions of a class at the same time. I've never used the version as anything other than a helpful marker so I can look at what version of my software is in use. So, I don't know if any apps or the JVM enforce versioning as you describe. David Daniel __ Do you Yahoo!? Jazz up your holiday email with celebrity designs. Learn more. http://celebrity.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] Problem with common DBUtil Bean
First, you need to alias the column names in the sql to avoid having to
use the horrible underscore in your java method names:
select index_id as indexID, document_type as documentType, date_entered as
dateEntered from MyTable
DBUtils 1.0 didn't contain very intelligent column to bean property
mapping. Oracle's JDBC driver returns NUMBER columns as BigDecimal so
changing your indexID from a long to a BigDecimal should fix the problem.
However, working with longs is easier so I suggest you download the latest
nightly build of DBUtils. Since 1.0 was released we made the type mapping
a bit smarter so your long indexID should be populated correctly.
David
--- spframe live [EMAIL PROTECTED] wrote:
I have
Table with these column name and types
INDEX_ID NUMBER,
DOCUMENT_TYPE VARCHAR2(3),
DATE_ENTERED DATE,
SELECT index_id, document_type, date_entered from MyTable;
and database has required data.
public MyBean class {
public long index_ID;
public String document_Type ;
public java.sql.Date date_Entered ;
public MyBean(){
super();
}
public long getIndex_ID() {
return index_ID;
}
public void setIndex_ID(long index_ID) {
this.index_ID = index_ID;
}
public java.sql.Date getDate_Entered() {
return this.date_Entered;
}
public void setDate_Entered(java.sql.Date date_Entered) {
this.date_Entered = date_Entered;
}
public String getDocument_Type() {
return document_Type;
}
public void setDocument_Type(String document_Type) {
this.document_Type = document_Type;
}
}
public SomeTestCalss {
public void someTestmethod(){
// some how got connetion/ result set statement this is tested ok
callst.execute();
//Casting the returned parameter, OracleTypes.CURSOR to a JDBC
ResultSet
rset = (ResultSet)callst.getObject(1);
rset = StringTrimmedResultSet.wrap(rset);
SqlNullCheckedResultSet sqlncrswrap = new
SqlNullCheckedResultSet(rset);
sqlncrswrap.setNullDate(null) ;
sqlncrswrap.setNullInt(0) ;
sqlncrswrap.setNullString();
rset = ProxyFactory.instance().createResultSet(sqlncrswrap);
// Pass wrapped ResultSet to processor
results = BasicRowProcessor.instance().toBeanList(rset,MyBean.class);
Iterator iter = mciResults.iterator();
while (iter.hasNext()) {
MyBean mb = (MyBean) iter.next();
System.out.println(Index ID+mb.getIndex_ID());
System.out.println(Document Type+mb.getDocument_Type());
System.out.println(date_entered +mb.getDate_Entered());
}
}
}
output looks like this
Index ID 0
Document Type MYDOCTYPE
Date entered null
Why Index ID for all rows is 0 and Date entered for all rows is null
while I can get Document Type value correctly.
-
Do you Yahoo!?
Send a seasonal email greeting and help others. Do good.
__
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: AW: AW: [proposal] avoiding jar version nightmares
--- Daniel Florey [EMAIL PROTECTED] wrote: BTW: Another advantage of this approach would be that imports would indicate which version of the component is in use. I had a lot of trouble to find out, which version of jdom was in use by some libraries as this was not indicated by the name of the jar. The version may be listed in the manifest file. David Daniel __ Do you Yahoo!? Jazz up your holiday email with celebrity designs. Learn more. http://celebrity.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons Mapper: scope/roadmap?
--- Max Rudman [EMAIL PROTECTED] wrote:
On Dec 17, 2004, at 8:52 PM, David Graham wrote:
There aren't any reusable implementations that I can think of. What
do
you picture the Hibernate mapper implementation looking like?
Well, I am not too familiar with other O/R implementations but at least
in Hibernate you don't need a separate Data Access Object (DAO)
implementation for each value object. Everything needed to persist and
load Person is captured in Person.hbm.xml mapping file.
What I have in mind for Hibernate implementation is HibernateMapper
class which will hold on to Hibernate Session object and Class of the
entity being persisted. HibernateMapperFactory then would simply pass
through entity class to the Mapper so it can in turn use it in its
calls to Hibernate Session. It would look something like this:
public class HibernateMapper implements Mapper {
private net.sf.hibernate.Session session;
private Class type;
public HibernateMapper(Session session, Class type) {
this.session = session;
this.type = type;
}
public Object findByUniqueId(Object id) {
return session.get(type, id);
}
.
}
This is probably very oversimplified and there is a fair amount of
housekeeping code; hence, the value of providing an implementation as
part of the Mapper project instead of forcing users to re-invent the
wheel so to speak.
In addition, we could provide an implementation which works with Spring
Framework, for example, which is an IoC container I am very fond of.
That way, the whole MapperFactory configuration can be done out of XML
config files and provided to business logic classes in the Injection
of Dependency manner. As a bonus, Spring integrates with Hibernate to
provide automatic transaction management and such.
I imagine something similar can be done for other O/R frameworks; I am
just not familiar enough with them to give you more details.
Mapper really saved me on one project where we designed a new db
schema
and wrote a bunch of code to access it and then mgmt. decided to use
the
old schema at the last minute. All I had to do was implement the
mappers
differently and the rest of the app. never changed.
I agree, O/R tools are great but being able to switch to a different DB
schema is a virtue of the O/R mapping tool itself not the abstraction
API like Mapper. In other words, it seems to me I could have achieved
the same result by using Hibernate directly as opposed to hard-coding
DB schema in JDBC calls.
In my particular example certain tables did not exist in the old schema so
I had to simulate them with XML files. The mapper implementation read
from XML instead of the database. Hibernate is a wonderful tool but it
needs database tables :-).
If I understood the project's goal correctly,
it is to abstract various O/R implementations in a manner similar to
how Commons Logging abstracts various Logging implementations.
The idea behind Mapper is insulating the application from the details of
data retrieval including SQL, HQL, etc. The app. just calls
PersonMapper.findByFirstName() and the implementation uses SQL, HQL, or
queries XML as needed. The implementation may not be using a relational
database at all.
David
Max
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [proposal] avoiding jar version nightmares
What happens if you merge the jars for each product? For example, put commons 1.x files into productA.jar and commons 2.x files into productB.jar. David --- Daniel Florey [EMAIL PROTECTED] wrote: So how should we handle situations where two versions of the same component need to coexist? If I have to integrate two commercial projects where each one uses a different major version of the same component, how can I achieve this? There is no chance to force them to up- or downgrade to the version of the other product. In situations like these you are absolutely lost, aren't you? So my proposal was about to avoid this horrible situation. Any proposals how to solve this issue in another way? Or is this list not the right place for discussing stuff like this? Cheers, Daniel -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von David Graham Gesendet: Freitag, 17. Dezember 2004 02:26 An: Jakarta Commons Developers List Betreff: Re: [proposal] avoiding jar version nightmares Struts uses the deprecation cycle I described and so did the commons components spawned from Struts the last I knew (validator certainly still uses the described cycle). A 1.x series is backwards compatible but deprecated methods may be removed after they have been deprecated for at least one point release. A jump to 2.x means, among other things, there are backwards incompatible changes without a deprecation cycle. This approach obviously varies by project. David --- Stephen Colebourne [EMAIL PROTECTED] wrote: Commons has always followed a longer deprecation cycle than described below. A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0. 1.1 - 1.2 - 1.3 should all be easy compatible changes. 1.1/1.2 - 2.0 may cause issues. In collections we faced a peculiar compatability problem in that a constant was in both 2.1 and 3.0 but was declared as a different type (by error). This caused major hassle as it wasn't spotted quickly. (Use 2.1.1 or 3.1 to get around the problem). Personally, I believe that a different package name for each version is overly restricting. Most users will just recompile their code for the new version and it will just work. Plus, having the same class in two different packages will be very confusing when using an IDE. This would be especially true if someone obtains an object from one version and then tries to pass it to an object of another version. Also, since human error can be a factor, we would have to version every release, minor or major to actually make the system foolproof. Basically, I believe there is no simple solution to this. The best we can do is to encourage tools like clirr which check a library for binary compatability. This should become part of each components standard tests. Stephen - Original Message - From: David Graham [EMAIL PROTECTED] All the jakarta projects I've worked on have a deprecation cycle of one minor point release. For example, you deprecate a method for the 1.1 release and can remove it for the 1.2 release. This gives users time to see the deprecation warning and update their code appropriately. IMO, requiring a package name change is overly restrictive and confusing to users. The only time I've seen versioning problems is when commons components depend on each other and one of them breaks backwards compatibility like commons collections did recectly. This is why it's so important for commons components to have minimal dependencies. What commons components caused your project problems? David --- Daniel Florey [EMAIL PROTECTED] wrote: Hi all, As commons components gain more and more attention you'll find a lot components in larger java based projects. This can cause much trouble when subprojects use different incompatible versions of the same component. I was faced with this problem in the project I'm currently working on and thought about how to avoid situations like these. So this is my proposal: - All versions of a component using the same main version number must be upwards compatible: Methods in component-1.x must not change in semantic or syntax compared to component-1.y where x y. Methods can be marked as deprecated but must still work in the same way. - When incompatible api changes or semantic changes of existing methods will be introduced, a new major version number must indicate this. To ensure that different versions of the same component can be used by a single application, the package name must change as well. Example: org.apache.commons.component-1 contains the 1.x source code of the compoenent
Re: Jakarta Commons Structure rehashed
Option B doesn't make a whole lot of sense to me. Most people are interested in only a few commons projects so each having their own trunk, tags, and branches makes sense. Struts lays out its subprojects using Option A: http://svn.apache.org/viewcvs.cgi/struts/ David --- Tim O'Brien [EMAIL PROTECTED] wrote: I don't think we ever settled this question. Which SVN structure are we interested in? ** Option A: jakarta/ commons/ digester/ trunk/ tags/ branches/ beanutils/ trunk/ tags/ branches/ OR ** Option B: jakarta/ commons/ trunk/ digester/ beanutils/ tags/ digester/ beanutils/ branches/ digester/ beanutils/ __ Do you Yahoo!? Dress up your holiday email, Hollywood style. Learn more. http://celebrity.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Commons Mapper: scope/roadmap?
There aren't any reusable implementations that I can think of. What do you picture the Hibernate mapper implementation looking like? The idea is that your app talks to the Mapper API which is implemented as sql, hibernate, etc. However, each implementation will be very specific to your app. For example you might have a SqlPersonMapper that knows how to work with your Person db table using JDBC and then switch to using an HqlPersonMapper without the app. knowing because it uses the Mapper interface (or an extended PersonMapper sub-interface). Mapper really saved me on one project where we designed a new db schema and wrote a bunch of code to access it and then mgmt. decided to use the old schema at the last minute. All I had to do was implement the mappers differently and the rest of the app. never changed. David --- Max Rudman [EMAIL PROTECTED] wrote: I've just discovered Commons Mapper project and would like to contribute. I built my own abstraction layer for Hibernate but would love to move to Mapper instead. I looked through current documentation and have a couple of questions. 1) Are specific implementations within the scope of this project? You mention several data mapping technologies (such as Hibernate, iBATIS, etc.) in project overview but I saw no specific implementations in the JavaDocs API. As I said, I have experience with Hibernate and would like to contribute in providing Hibernate Mapper implementation (if this is something that needs to be done). 2) Is query API something you envision being part of this package? Specifically, a Query-By-Example API which I found to be very useful in enterprise application development where one often needs to have the ability to search for records with flexible (dynamic) WHERE clause. Hibernate package provides such an API but obviously it is specific to their implementation and it would be nice to have the abstraction layer against that functionality as well. This is my first time inquiring about contributing to Jakarta Commons so I apologize in advance if I am doing something inappropriate. I did search through both user and dev mailing list archives but couldn't find any information on the topics above. Thanks in advance, Max - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Send a seasonal email greeting and help others. Do good. http://celebrity.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] avoiding jar version nightmares
Struts uses the deprecation cycle I described and so did the commons components spawned from Struts the last I knew (validator certainly still uses the described cycle). A 1.x series is backwards compatible but deprecated methods may be removed after they have been deprecated for at least one point release. A jump to 2.x means, among other things, there are backwards incompatible changes without a deprecation cycle. This approach obviously varies by project. David --- Stephen Colebourne [EMAIL PROTECTED] wrote: Commons has always followed a longer deprecation cycle than described below. A method deprecated in 1.1, 1.2, 1.3 cannot be removed until 2.0. 1.1 - 1.2 - 1.3 should all be easy compatible changes. 1.1/1.2 - 2.0 may cause issues. In collections we faced a peculiar compatability problem in that a constant was in both 2.1 and 3.0 but was declared as a different type (by error). This caused major hassle as it wasn't spotted quickly. (Use 2.1.1 or 3.1 to get around the problem). Personally, I believe that a different package name for each version is overly restricting. Most users will just recompile their code for the new version and it will just work. Plus, having the same class in two different packages will be very confusing when using an IDE. This would be especially true if someone obtains an object from one version and then tries to pass it to an object of another version. Also, since human error can be a factor, we would have to version every release, minor or major to actually make the system foolproof. Basically, I believe there is no simple solution to this. The best we can do is to encourage tools like clirr which check a library for binary compatability. This should become part of each components standard tests. Stephen - Original Message - From: David Graham [EMAIL PROTECTED] All the jakarta projects I've worked on have a deprecation cycle of one minor point release. For example, you deprecate a method for the 1.1 release and can remove it for the 1.2 release. This gives users time to see the deprecation warning and update their code appropriately. IMO, requiring a package name change is overly restrictive and confusing to users. The only time I've seen versioning problems is when commons components depend on each other and one of them breaks backwards compatibility like commons collections did recectly. This is why it's so important for commons components to have minimal dependencies. What commons components caused your project problems? David --- Daniel Florey [EMAIL PROTECTED] wrote: Hi all, As commons components gain more and more attention you'll find a lot components in larger java based projects. This can cause much trouble when subprojects use different incompatible versions of the same component. I was faced with this problem in the project I'm currently working on and thought about how to avoid situations like these. So this is my proposal: - All versions of a component using the same main version number must be upwards compatible: Methods in component-1.x must not change in semantic or syntax compared to component-1.y where x y. Methods can be marked as deprecated but must still work in the same way. - When incompatible api changes or semantic changes of existing methods will be introduced, a new major version number must indicate this. To ensure that different versions of the same component can be used by a single application, the package name must change as well. Example: org.apache.commons.component-1 contains the 1.x source code of the compoenent org.apache.commons.component-2 contains the 2.x sources Both versions of the component can be used simultaneous and situations described at the beginning of this post can be handled. Disadvantage: When upgrading a project from component-1.x to component-2.x all includes must be updated. But the fact that many (even commercial products) ship without indicating by jar-extension which version of a component is used, this can avoid a lot of headaches. What do you think of this approach? Regards, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [proposal] avoiding jar version nightmares
All the jakarta projects I've worked on have a deprecation cycle of one minor point release. For example, you deprecate a method for the 1.1 release and can remove it for the 1.2 release. This gives users time to see the deprecation warning and update their code appropriately. IMO, requiring a package name change is overly restrictive and confusing to users. The only time I've seen versioning problems is when commons components depend on each other and one of them breaks backwards compatibility like commons collections did recectly. This is why it's so important for commons components to have minimal dependencies. What commons components caused your project problems? David --- Daniel Florey [EMAIL PROTECTED] wrote: Hi all, As commons components gain more and more attention you'll find a lot components in larger java based projects. This can cause much trouble when subprojects use different incompatible versions of the same component. I was faced with this problem in the project I'm currently working on and thought about how to avoid situations like these. So this is my proposal: - All versions of a component using the same main version number must be upwards compatible: Methods in component-1.x must not change in semantic or syntax compared to component-1.y where x y. Methods can be marked as deprecated but must still work in the same way. - When incompatible api changes or semantic changes of existing methods will be introduced, a new major version number must indicate this. To ensure that different versions of the same component can be used by a single application, the package name must change as well. Example: org.apache.commons.component-1 contains the 1.x source code of the compoenent org.apache.commons.component-2 contains the 2.x sources Both versions of the component can be used simultaneous and situations described at the beginning of this post can be handled. Disadvantage: When upgrading a project from component-1.x to component-2.x all includes must be updated. But the fact that many (even commercial products) ship without indicating by jar-extension which version of a component is used, this can avoid a lot of headaches. What do you think of this approach? Regards, Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] avoiding jar version nightmares
I'm still wondering what commons components caused you guys problems in your project? Why should all projects change to renaming packages and causing confusion if it's just a few projects that are causing problems? My guess is that it's commons collections that is giving you headaches but I would like to hear the real world example. Thanks, David --- Oliver Zeigermann [EMAIL PROTECTED] wrote: On Thu, 16 Dec 2004 09:09:11 -0800 (PST), David Graham [EMAIL PROTECTED] wrote: The only time I've seen versioning problems is when commons components depend on each other and one of them breaks backwards compatibility like commons collections did recectly. This is why it's so important for commons components to have minimal dependencies. Just think of a 1.x version and a 2.x version having the same package and class names, but different method sets or even different semantics. Now in a large project a piece of software from one vendor needs 1.x and another one needs 2.x. Now consider they really need to share the same class loader and you are lost. You would not if you could have both 1.x and 2.x usable at the same time. Daniel's proposal would make this possible. Oliver Disclaimer: Daniel talked this over with me in person yesterday, so our points of view are pretty much aligned. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
--- Richard Sitze [EMAIL PROTECTED] wrote: Simon Kitching [EMAIL PROTECTED] wrote on 12/15/2004 10:18:44 PM: On Thu, 2004-12-16 at 13:53, Matt Sgarlata wrote: Simon Kitching wrote: I think this demonstrates a major issue. When using logging in an enterprise situation, the logging can be considered a critical part of the application. If you have heavy-duty monitoring systems watching for alerts from the software, and have sysadmins on call 24x7 to deal with issues, then for an application to fail to locate the correct logging libs or config files is a *failure* of the app. You don't want an app to start up, but then not be able to generate alerts if problems occur. But when using logging in other situations, logging is *not* a critical part, and should not cause an application to fail to start. The latter is the focus of commons-logging at the moment. And unfortunately as commons-logging has no *mandatory* configuration, it is not possible to add a fail-on-no-config option! So perhaps we could build two separate jars from mostly-common source code? Deploying the traditional commons-logging jar would do the be quiet on no config, while the enterprise commons-logging jar would do something like write message to STDERR then throw a runtime exception on no config? Why not just introduce a boolean parameter that says whether or not an inability to log is a failure? e.g. Log log = LogFactory.getLog(MyClass.class, true); It's not inability to log as such. It's whether finding no specific config info or underlying log implementation and therefore falling back to using java.util.logging (java=1.4) or org.apache.commons.logging.SimpleLog (java1.4) is allowed or not. In many cases, what you *want* an app to do if it can't find any specific logging config is simply to output ERROR and FATAL messages to stderr. This is what commons-logging will currently do if its discovery process finds nothing. I guess commons-logging *could* use a parameter such as you suggest to indicate explicit configuration of logging is mandatory. This would presumably mean detecting whether commons-logging.properties or the corresponding system properties have defined an explicit log implementation and config file for that implementation. I'm not sure, however, if the decision on whether logging is mandatory or not should be a compile-time one. It seems to me to be more like something the application *deployer* should choose. That then leads us to a circular reference: how do we know whether configuration is mandatory or not, if we can't find any configuration? The current proposal is: - configuration is always manditory. Doesn't mandatory configuration relieve us from needing to split commons-logging.jar into several pieces? I like the fact that I don't have to manage multiple commons-logging jar files and will be rather dissapointed if that is required in the future. I wouldn't mind having a simple properties file or a system property like -Dorg.apache.commons.logging.impl=log4j that tells commons-logging to use log4j. David - ambiguous [multiple] configurations located by a particular ClassLoader in the hierarchy requires an error to be logged [where is a reasonable question to ask]. How we determine which configs belong to which ClassLoaders is described in the original proposal. - in a core JCL jar, a configuration *must not* be packaged with JCL. - in a helper JCL jar, a configuration *must* be packaged, along with *one* JCL logger wrapper class. - multiple helper JCL jar files, one per logging impl wrapper we support. Pick the logger impl you want, grab the corresponding helper JCL jar file, and drop it into your application. Regards, Simon __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
--- Richard Sitze [EMAIL PROTECTED] wrote: David Graham [EMAIL PROTECTED] wrote on 12/16/2004 11:47:46 AM: snip/ The current proposal is: - configuration is always manditory. Doesn't mandatory configuration relieve us from needing to split commons-logging.jar into several pieces? I like the fact that I don't have to manage multiple commons-logging jar files and will be rather dissapointed if that is required in the future. I wouldn't mind having a simple properties file or a system property like -Dorg.apache.commons.logging.impl=log4j that tells commons-logging to use log4j. ok, without going back to review exactly what I said in an earlier note, I had in mind something like: commons-logging-core.jar - core interface factory class, NO config commons-logging.jar- core + all helpers, NO config commons-logging-impl.jar - core + ONE helper, ONE config With this scheme, I believe we can scrub the code from LogFactory that looks for an attempts to load specific logger impls [Log4J, Avalon, ?], and instead depend entirely on the config. So the configuration file is inside each impl. jar? What are you picturing the configuration will look like? I figured it would just be a simple declaration that you're using Log4J, java.util.logging, etc. If it is indeed that simple then I don't understand why we would need separate jars. We could keep the single commons-logging.jar but just use the application supplied configuration instead of relying on the LogFactory lookup code. David __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [logging] Enterprise Common Logging... dare we say 2.0?
What you're seeing is the natural result of design conversations held outside of the mailing list. No one here had the benefit of participating in the localized logging design so naturally we're asking questions and making suggestions. Additionally, it might have helped all of us if the proposal didn't use marketing hype terms devoid of meaning (ie. enterprise) to describe what is actually a small and reasonable set of additions related to localized messages. There are no JSR-mandated logging requirements for commons logging so I'm not really sure what that means. David --- Noel J. Bergman [EMAIL PROTECTED] wrote: It disturbs me that what seems to me to be a reasonable and small set of requirements --- along with what appears to have been considerable forethought based upon real world issues, and experiences supporting many developers --- appears to be discounted a bit too out of hand. I hope my perception is wrong. Does anyone really dispute the requirement to support localization for log messages or the additional JSR-mandated logging requirements? If not, then let's work constructively towards satisfying the requirements. And not by relying upon some IDE's tooling. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Enterprise is marketing speak for expensive. It has no technical meaning so including that word in class names is rather confusing. It looks like the new functionality is related to i18n of messages so naming the classes something like I18NLog or GlobalizedLog would be more appropriate. David --- Richard Sitze [EMAIL PROTECTED] wrote: IBM would like to open a discussion within the Jakarta commons community on evolving the Jakarta Commons Logging (JCL) API's to support Enterprise level logging functionality. We recognize the value that a logging implementation independent API brings to open source component development, and would like to work with the community to accomplish this goal. We present a set of requirements as a baseline for the discussion, a proposal for meeting these requirements, a number of points of discussion, and attached are two Java source files that correspond to the discussion below. Requirements: We recognize that the community has an overriding requirement: A.1. Evolution: maintain compatibility with the current LogFactory/Log interfaces. We have ONE primary requirement: A.2. Globalization Having opened the door, we'd also like to propose a few other requirements: B.1. Functional alignment with JSR-47 concepts. B.2. Fix fragile configuration problems - Currently the user has NO idea which impl is in effect. All the default/fall back behavior means that in the end we have an apparent non-deterministic logging implementation. Errors in config file names, classpath errors, classpath ordering, etc., can all change the behavior... with no idea which is in effect. The fundamental problem with the current factory is that it is dependent on passively identifying a logging implementation. We propose one solution below, but would ask a more general question: any new bright ideas? Proposals: A.1. Evolution: Maintain compatibility with the current LogFactory/Log interfaces BY PROVIDING - Drop-in replacement of commons-logging.jar version 1.x with a version 2.x variant. - EnterpriseLogFactory class that extends the existing LogFactory. - EnterpriseLog interface that extends the existing Log interface. A.2. Globalization. For the enterprise logging we need globalized messages (translated) for message level logging API's: info, warn, error, fatal. The remaining logging API's are considered trace level logging API's, and do not require message translation. - For message level logging, support globalized variants on the new EnterpriseLog interface: info(Class callingClass, String methodName, String messageID); info(Class callingClass, String methodName, String messageID, Object messageParam); info(Class callingClass, String methodName, String messageID, Object[] messageParams); same for warn, error, fatal. - Utility function to support formatting for other purposes (exception strings): formatMessage(String messageID); formatMessage(String messageID, Object messageParam); formatMessage(String messageID, Object[] messageParams); Ensure that component has an assurance that the message will be translated/formatted as expected: - ALL message translation must be done using the standard java.util.ResourceBundle class, or functional equivalent. - ALL message formatting must be done using the standard java.text.MessageFormat class, or functional equivalent. - Bind a ResourceBundleName to an EnterpriseLog instance. - Expects that the named ResourceBundle is available to the logger. B.1. Functional alignment with JSR-47 concepts. JSR-47 has 3 trace levels: FINE, FINER, FINEST JCL has 2 trace levels defined today: debug, trace which corresponds to JSR-47 FINE and FINEST in the current implementation. The JSR-47 FINER level has no corresponding APIs in JCL. The expectation is that the FINER level be used for class/method level flow. We propose a set of API's that would correspond to the JSR-47 FINER LEVEL, but more generally support the class/method level flow logging. - enter(Class clazz, String methodName,
Re: [logging] Enterprise Common Logging... dare we say 2.0?
--- simon [EMAIL PROTECTED] wrote: snip Regarding the addition of entry/exit logging APIs, I'm also in favour. The code seems trivial, and it can be mapped to TRACE level for logging implementations that don't provide FINER equivalents. It also seems to me that: log.enter(MyClass, MyMethod, Entering method); is nice and readable. Until you refactor the class name or method name. Then your logging code is completely misleading. Considering the fact that IDEs allow you to rename things without even looking at their implementation code, the chance of the logging not keeping up with the names is high. I would personally never use the enter/exit methods for those reasons. If I wanted that kind of detail, I would use AspectJ. David Simon __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE][EMAIL] Release Commons-Email 1.0
+1 David --- Davanum Srinivas [EMAIL PROTECTED] wrote: [X] +0 I support this release but am unable to help On Fri, 3 Dec 2004 17:35:36 + (UTC), Henning P. Schmiedehausen [EMAIL PROTECTED] wrote: Eric Pugh [EMAIL PROTECTED] writes: --- [ ] +1 I support this release and am willing to help [X] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- 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 What is more important to you... [ ] Product Security or [ ] Quality of Sales and Marketing Support -- actual question from a Microsoft customer survey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Davanum Srinivas - http://webservices.apache.org/~dims/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] add expression evaluation?
I've never used JEXL but the Mozilla Rhino javascript engine is pretty
keen. Maybe this feature could start in contrib and move to the core if
people find it useful?
David
--- Joe Germuska [EMAIL PROTECTED] wrote:
In a discussion on the struts-user list, I got around to describing a
configuration format which made me wonder if folks would tolerate
some kind of expression evaluation engine in chain.
The musing repeated below:
At 1:57 PM -0600 12/2/04, Joe Germuska wrote:
I think you could find the view processor command by using the
standard Chain lookup action. Well, out of the box, its nameKey
property would depend on some String value being placed into the
context under a certain key, and as it is now, we're talking about
using a String property of an Object in the context under a certain
key. If we gave the LookupCommand an expression language (JEXL,
perhaps?), then we could do something like this, which seems cool:
command
className=org.apache.commons.chain.generic.LookupCommand
catalogName=struts-view-preprocess
nameKey=${context.forward.name}
optional=true/
or possibly work some magic to make the context prefix assumed.
Anyone have an opinion about adding a JEXL dependency to Chain, or
whether this would be best left to a Struts subclass of
LookupCommand?
Ideas? I'm not sure right now of the scope of this proposal -- is it
just for the LookupCommand? Is it somehow implemented more widely?
How can you do that when Chain is first-and-foremost an API?
I can certainly see some of these questions leading folks to throw up
their hands and say let's just keep it simple. There's no critical
reason to add this dependency to the core, but when you think about
the expressive power it would provide in the config files, it seems
pretty cool.
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
Narrow minds are weapons made for mass destruction -The Ex
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
http://info.mail.yahoo.com/mail_250
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Migrate to SVN?
It's true that the svn tools aren't as good as the cvs tools yet. However, Struts recently moved to svn and it's amazing how easy it's been to refactor and rearrange the code base after the switch. The change has really livened up that project. Also, I was able to use Subclipse to work with the Struts repository. David --- Shapira, Yoav [EMAIL PROTECTED] wrote: Hi, I feel the same as Senor Colebourne to a large extent. Not -1, but not a +1 either -- a true neutral 0 on this one. When we do move, we need to make sure the relevant documentation for potential contributors, e.g. http://www.apache.org/dev/contributors.html, and all related pages which currently only have CVS information, are updated to include SVN as well. It's a higher barrier of entry unfortunately. Yoav Shapira http://www.yoavshapira.com -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 6:13 PM To: Jakarta Commons Developers List Subject: Re: Migrate to SVN? I remain unenthused by SVN, probably because I don't have to manage a CVS server. Effectively I'm -1, but I'm probably not going to fight. My main reason is that SVN does not appear to be that widely adopted yet. A sign that the time has come to migrate would be when Eclipse/Idea ships with SVN support built in. At the moment, I fear we may just scare off some potential users/contributers. If we are moving though, I would want the pain all at once. Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] +1 from me as well -- seems to make sense to move as a group. Phil Alex Karasulu wrote: +1 Noel J. Bergman wrote: 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? A lot of projects, including the HTTP Server project, have been migrating, as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are definitely the laggards now. --- Noel - 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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Migrate to SVN?
I doubt Eclipse will ever have built-in svn support because there are several third party plugins available. Since adding a plugin update site is so trivial in Eclipse I wouldn't think this would be a big deal. The plugin I use with Struts svn is http://subclipse.tigris.org/. It works largely the same as Eclipse's cvs plugin. David --- Gary Gregory [EMAIL PROTECTED] wrote: I have the same feelings as Stephen. Without built-in Eclipse support, this is a pain for me to deal with. I deal with CVS everyday for work no matter what. Dealing with SVN means extra hoops and is a disincentive for me. Yes, playing with a new toy would be fun but at the end of the day, I need to get work done. Gary -Original Message- From: Stephen Colebourne [mailto:[EMAIL PROTECTED] Sent: Friday, November 26, 2004 3:13 PM To: Jakarta Commons Developers List Subject: Re: Migrate to SVN? I remain unenthused by SVN, probably because I don't have to manage a CVS server. Effectively I'm -1, but I'm probably not going to fight. My main reason is that SVN does not appear to be that widely adopted yet. A sign that the time has come to migrate would be when Eclipse/Idea ships with SVN support built in. At the moment, I fear we may just scare off some potential users/contributers. If we are moving though, I would want the pain all at once. Stephen - Original Message - From: Phil Steitz [EMAIL PROTECTED] +1 from me as well -- seems to make sense to move as a group. Phil Alex Karasulu wrote: +1 Noel J. Bergman wrote: 6) should I just delete the /jakarta-commons-sandbox/email directory, or leave the folder and a note pointing to the promotion? What about the website as well? I think for [configuration] we just deleted both. The ideal scenario would be to use cvs delete on all the sandbox files, so that the original history is maintained there, but nobody who checks out the sandbox (with -dP at least) will be bothered by the files. The IDEAL situation would be to convert Jakarta Commons to SVN. Can we PLEASE consider doing so? A lot of projects, including the HTTP Server project, have been migrating, as can be seen from http://svn.apache.org/viewcvs. Jakarta and XML are definitely the laggards now. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Validator 1.1.4
+1 Actually, HEAD contains 1.2 work so far. David --- Niall Pemberton [EMAIL PROTECTED] wrote: The release candidate has been available for a week now with no problems reported. This is a very minor maintenance release (adding four missing getters/setters missing from Version 1.1.3) . The new version will enable a number of Struts bugzilla tickets to be resolved. The plan is to cut the Validator 1.1.4 release from the VALIDATOR_1_1_2_BRANCH (VALIDATOR_1_1_2_BRANCH is for the 1.1.x series and HEAD contains the 2.x series) on completion of a successful vote. Here's my +1 Niall --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release Chain 1.0
+1 If the beanutils and digester dependencies are updated, it looks like commons-collections can be removed as a dependency from the project.xml file. David --- Martin Cooper [EMAIL PROTECTED] wrote: I believe Chain is now sufficiently complete and stable to warrant an official 1.0 release. There are no outstanding bug reports, and the component is already in use in a number of projects. The plan is to release HEAD as Commons Chain 1.0 on completion of a successful vote. I will be the release manager. --- [ ] +1 I support this release and am willing to help [ ] +0 I support this release but am unable to help [ ] -0 I do not support this release [ ] -1 I do not support this release, and here are my reasons --- Here is my own +1. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Resources to Commons Proper
+1 David --- Martin Cooper [EMAIL PROTECTED] wrote: The Resources project has been in the sandbox for quite some time, and is essentially complete and almost ready for a release. Several projects are using it already, and others are ready to pick it up once it is released. Therefore I propose that we promote Resources out of the sandbox and into Commons Proper, in preparation for a 1.0 release in the near future. --- [ ] +1 I support this proposal and am willing to help [ ] +0 I support this proposal but am unable to help [ ] -0 I do not support this proposal [ ] -1 I do not support this propsal, and here are my reasons --- Here is my own +1. -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Promote Transaction to Commons Proper
+1 This project looks well maintained. It would be good to state the minimum Java version required on the home page. David --- Oliver Zeigermann [EMAIL PROTECTED] wrote: Folks, as described in previous posts and inspired by the fine proposal for email promotion I would like to see the transaction component http://jakarta.apache.org/commons/sandbox/transaction/ promoted to commons proper. The initial committers would be Stefan Lützkendorf, James Mason, Daniel Florey and me. AFAIK none of us is a committer in commons proper so the promotion would include making as committers there. We all are Jakarta Slide committers and this is where the component came from. We factored out code for a transactional file system, transactional maps (implementing Map interface) with different ACID strategies, general purpose locks and a few more helper classes. Junit tests exist for all parts and succeed: http://jakarta.apache.org/commons/sandbox/transaction/junit-report.html Javadoc is pretty complete http://jakarta.apache.org/commons/sandbox/transaction/apidocs/index.html and general documentation and even a short tutorial for locks exist: http://jakarta.apache.org/commons/sandbox/transaction/locks/tutorial.html The transaction component is stable enough to be released as a 1.0 soon after promotion and would initially be maintained by the committers of the Slide community. Once promoted growth is anticipated as even in the sandbox it attracted some attention. As I am not a commons committer, I have no binding vote, but my non-binding vote of course is +1. Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Next Release
--- Niall Pemberton [EMAIL PROTECTED] wrote: David, thanks for the rsponse. I'm going to commit the automatic positioning work I've done today (to the HEAD, not the VALIDATOR_1_1_2_BRANCH). Thanks for the pointer to changes.xml - I'll update that today with the changes I've made. Can I cut a release using the ant release task or do I have to use maven - I know next to nothing about maven :-( I don't use or maintain the ant build file. Running 'maven clean dist' will give you the source and binary files needed for the release. Running 'maven clean site' will generate the website. David Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, November 11, 2004 8:10 PM Subject: Re: [Validator] Next Release --- Niall Pemberton [EMAIL PROTECTED] wrote: I decided to have a go a resolving a couple of Struts bugs to do with bundles/resources and validator: http://issues.apache.org/bugzilla/show_bug.cgi?id=18169 http://issues.apache.org/bugzilla/show_bug.cgi?id=21760 Currently theres an inconsitency in how Struts handles bundles since although the validator dtd allows users to specify alternative bundles - Struts completely ignores them. Seems to me this is a big weakness in how handles Strut's bundles if validator can't take acount of them. Specifically Struts ignores the following validator DTD attributes: *the msg elements 'bundle' attribute *the msg elements 'resource' attribute *the arg elements 'bundle' attribute Fixing Struts required a couple of small changes to Commons Validator, which I've just done - it was already subject to the following outstanding bugzilla request: http://issues.apache.org/bugzilla/show_bug.cgi?id=29452 In order to now fix Struts there needs to be a release of Commons Validator with this change in and I'm wondering about the following: 1) Version 1.1.4 or Version 1.2.0 I wan't sure what the difference between the whats in the HEAD (Version 1.2.0) and the VALIDATOR_1_1_2_BRANCH (Version 1.1.3) - but from a quick scan a summary of the differences is: *Form Inheritance functionality (new extends attribute) *Loads of deprecations removed (including arg0 to arg3) *A number of minor bug fixes Those are the only differences I can remember. I guess it would be good to have only one branch and release Version 1.2.0 but I'm wondering whether the Form Inheritance is fully tested and working and also, given all the deprecations removed, whether it might be better (upgrade wise for the users) to release Version 1.1.4 from the VALIDATOR_1_1_2_BRANCH. I doubt form inheritance has been tested completely since it hasn't been included in a release yet. The branch name should have been VALIDATOR_1_1_BRANCH so that it could logically support multiple 1.1.x releases. However, it's not named that so I guess we'll just have to release 1.1.4 from that branch and deal with the minor confusion. I'd like to limit the number of releases in the 1.1 series and move on to 1.2 so we can get rid of the gross arg0-4 stuff for good. 2) Arg's Position Parameter - Bug 31194 == While doing this stuff on validator I came across the following enhancement request: http://issues.apache.org/bugzilla/show_bug.cgi?id=31194 It looked like a good idea and I've attached a patch for review which implements this request. Personally, if the decision is to go with a Version 1.2.0 release - I wouldn't want to upgrade to 1.2.0 without this enhancement being applied - when replacing arg0 - arg3 I could get away with not having to add a position attribute if this enhacement was done. I agree that automatic positioning should be included in 1.2.0. The easiest route - Struts wise is to go the Version 1.1.4 route. It would mean zero impact on the users, except having to drop the new jar in. Validator wise, we should probably get the Version 1.2.0 out of the door and just support one version. I'd rather go the 1.1.4 route but I'd appreciate hearing what others think. I think releasing a 1.1.4 is a good idea. This will give users yet another opportunity to notice the arg0-4 deprecation and change their xml accordingly. That will make for a smooth upgrade to 1.2.0 when it's finally released. If you cut a release, please update the changes.xml file because we're using that as our release notes. I usually update this file at the same time as making a code change or fixing a bug. Thanks so much for volunteering on validator Niall! David Niall
Re: [Validator] Next Release
--- Niall Pemberton [EMAIL PROTECTED] wrote: Would it be better to call the version 1.3.1.1? I'm just thinking that its going to confuse people using the 1.3.1 version DTD with a 1.4.1 version? I think you've got your versions mixed up :-). IMO, the release should be called 1.1.4 because that comes after 1.1.3. This is a bugfix release so it shouldn't be surprising that the dtd is the same as the last version. David Niall - Original Message - From: David Graham [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, November 11, 2004 8:10 PM Subject: Re: [Validator] Next Release I think releasing a 1.1.4 is a good idea. This will give users yet another opportunity to notice the arg0-4 deprecation and change their xml accordingly. That will make for a smooth upgrade to 1.2.0 when it's finally released. If you cut a release, please update the changes.xml file because we're using that as our release notes. I usually update this file at the same time as making a code change or fixing a bug. Thanks so much for volunteering on validator Niall! David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [transaction] Promotion possible?
Sandbox components can not have any official releases. The way to get out of the sandbox is to start a VOTE thread and have it pass. Several commons projects started with just the committers from the source project (ie. Struts) but have grown a bigger community once out of the sandbox. If transaction is broadly useful I don't see any reason it wouldn't grow a community as well. David --- Oliver Zeigermann [EMAIL PROTECTED] wrote: Folks, I'd like to discuss the possibility of a promotion of the transaction component from the sandbox. The transaction component is stable and has proved its maturity in the Slide project and also is maintained by the committers of the Slide project. From other posts I have learned that the most important criteria for a promotion are community and readiness for a 1.0. While I'd say it is more than ready for a 1.0 release - docs and junit tests are in place now - a healthy community apart from the Slide project is yet to be created. However, many people have been interested in the package, but had questions/reversavtions concerning readiness of the code and the lack of an official release. Because of this I would very much like to see an official release of the transaction component soon. This would be great as well as Slide relies on the component and its 2.1 release - which is in beta now - would benefit from a 1.0 release as well. Having said that, is it possible to promote the transaction component soon and if not is it possible to get a release out inspite of it? Thanks for your attention and cheers, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator Field.java Msg.java
Can we change getMessageObject() to getMessage() ? Most everything in
Java is an object so it's redundant. Also, getMsgs() doesn't read very
well; what about getMessages() ? It would be good to add @since javadoc
tags so people don't assume this functionality was there from the
beginning.
David
--- [EMAIL PROTECTED] wrote:
niallp 2004/11/11 04:18:25
Modified:validator/src/share/org/apache/commons/validator
Field.java
Msg.java
Log:
Bug 29452 Enable Field/Msg to support all DTD attributes, based on
patch submitted by Rich Wertz
Changed Field to add getMsgObject(key) and getMsgs() methods
Changed Msg to add resource property and getter/setter
Revision ChangesPath
1.34 +24 -10
jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java
Index: Field.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- Field.java 8 Jun 2004 17:17:44 - 1.33
+++ Field.java 11 Nov 2004 12:18:25 - 1.34
@@ -207,14 +207,30 @@
* Add a codeMsg/code to the codeField/code.
*/
public void addMsg(Msg msg) {
-hMsgs.put(msg.getName(), msg.getKey());
+hMsgs.put(msg.getName(), msg);
}
/**
* Retrieve a message value.
*/
public String getMsg(String key) {
-return (String) hMsgs.get(key);
+Msg msg = getMsgObject(key);
+return (msg == null) ? null : msg.getKey();
+}
+
+/**
+ * Retrieve a message object.
+ */
+public Msg getMsgObject(String key) {
+return (Msg)hMsgs.get(key);
+}
+
+/**
+ * The codeField/code's messages are returned as an
+ * unmodifiable codeMap/code.
+ */
+public Map getMsgs() {
+return Collections.unmodifiableMap(hMsgs);
}
/**
@@ -469,11 +485,9 @@
String varKey = TOKEN_START + TOKEN_VAR;
// Process Messages
if (key != null !key.startsWith(varKey)) {
-for (Iterator i = hMsgs.keySet().iterator();
i.hasNext();) {
-String msgKey = (String) i.next();
-String value = this.getMsg(msgKey);
-
-hMsgs.put(msgKey, ValidatorUtils.replace(value, key,
replaceValue));
+for (Iterator i = hMsgs.values().iterator();
i.hasNext();) {
+Msg msg = (Msg) i.next();
+msg.setKey(ValidatorUtils.replace(msg.getKey(), key,
replaceValue));
}
}
1.13 +30 -3
jakarta-commons/validator/src/share/org/apache/commons/validator/Msg.java
Index: Msg.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/Msg.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- Msg.java21 Feb 2004 17:10:29 - 1.12
+++ Msg.java11 Nov 2004 12:18:25 - 1.13
@@ -49,6 +49,13 @@
protected String name = null;
/**
+ * Whether or not the key is a message resource (optional).
Defaults to
+ * true. If it is 'true', the value will try to be resolved as a
message
+ * resource.
+ */
+protected boolean resource = true;
+
+/**
* Returns the resource bundle name.
* @since Validator 1.1
*/
@@ -94,6 +101,22 @@
}
/**
+ * Tests whether or not the key is a resource key or literal
value.
+ * @return codetrue/code if key is a resource key.
+ */
+public boolean isResource() {
+return this.resource;
+}
+
+/**
+ * Sets whether or not the key is a resource.
+ * @param resource If true indicates the key is a resource.
+ */
+public void setResource(boolean resource) {
+this.resource = resource;
+}
+
+/**
* Creates and returns a copy of this object.
*/
public Object clone() {
@@ -115,6 +138,10 @@
results.append(name);
results.append( key=);
results.append(key);
+results.append( resource=);
+results.append(resource);
+results.append( bundle=);
+results.append(bundle);
results.append(\n);
return results.toString();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator Field.java Msg.java
Thanks Niall!
David
--- Niall Pemberton [EMAIL PROTECTED] wrote:
OK I'll do that.
Niall
- Original Message -
From: David Graham [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, November 11, 2004 2:37 PM
Subject: Re: cvs commit:
jakarta-commons/validator/src/share/org/apache/commons/validator
Field.java
Msg.java
Can we change getMessageObject() to getMessage() ? Most everything in
Java is an object so it's redundant. Also, getMsgs() doesn't read
very
well; what about getMessages() ? It would be good to add @since
javadoc
tags so people don't assume this functionality was there from the
beginning.
David
--- [EMAIL PROTECTED] wrote:
niallp 2004/11/11 04:18:25
Modified:validator/src/share/org/apache/commons/validator
Field.java
Msg.java
Log:
Bug 29452 Enable Field/Msg to support all DTD attributes, based on
patch submitted by Rich Wertz
Changed Field to add getMsgObject(key) and getMsgs() methods
Changed Msg to add resource property and getter/setter
Revision ChangesPath
1.34 +24 -10
jakarta-commons/validator/src/share/org/apache/commons/validator/Field.java
Index: Field.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/F
ield.java,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- Field.java 8 Jun 2004 17:17:44 - 1.33
+++ Field.java 11 Nov 2004 12:18:25 - 1.34
@@ -207,14 +207,30 @@
* Add a codeMsg/code to the codeField/code.
*/
public void addMsg(Msg msg) {
-hMsgs.put(msg.getName(), msg.getKey());
+hMsgs.put(msg.getName(), msg);
}
/**
* Retrieve a message value.
*/
public String getMsg(String key) {
-return (String) hMsgs.get(key);
+Msg msg = getMsgObject(key);
+return (msg == null) ? null : msg.getKey();
+}
+
+/**
+ * Retrieve a message object.
+ */
+public Msg getMsgObject(String key) {
+return (Msg)hMsgs.get(key);
+}
+
+/**
+ * The codeField/code's messages are returned as an
+ * unmodifiable codeMap/code.
+ */
+public Map getMsgs() {
+return Collections.unmodifiableMap(hMsgs);
}
/**
@@ -469,11 +485,9 @@
String varKey = TOKEN_START + TOKEN_VAR;
// Process Messages
if (key != null !key.startsWith(varKey)) {
-for (Iterator i = hMsgs.keySet().iterator();
i.hasNext();) {
-String msgKey = (String) i.next();
-String value = this.getMsg(msgKey);
-
-hMsgs.put(msgKey, ValidatorUtils.replace(value,
key,
replaceValue));
+for (Iterator i = hMsgs.values().iterator();
i.hasNext();) {
+Msg msg = (Msg) i.next();
+msg.setKey(ValidatorUtils.replace(msg.getKey(),
key,
replaceValue));
}
}
1.13 +30 -3
jakarta-commons/validator/src/share/org/apache/commons/validator/Msg.java
Index: Msg.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/M
sg.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- Msg.java 21 Feb 2004 17:10:29 - 1.12
+++ Msg.java 11 Nov 2004 12:18:25 - 1.13
@@ -49,6 +49,13 @@
protected String name = null;
/**
+ * Whether or not the key is a message resource (optional).
Defaults to
+ * true. If it is 'true', the value will try to be resolved
as a
message
+ * resource.
+ */
+protected boolean resource = true;
+
+/**
* Returns the resource bundle name.
* @since Validator 1.1
*/
@@ -94,6 +101,22 @@
}
/**
+ * Tests whether or not the key is a resource key or literal
value.
+ * @return codetrue/code if key is a resource key.
+ */
+public boolean isResource() {
+return this.resource;
+}
+
+/**
+ * Sets whether or not the key is a resource.
+ * @param resource If true indicates the key is a resource.
+ */
+public void setResource(boolean resource) {
+this.resource = resource;
+}
+
+/**
* Creates and returns a copy of this object.
*/
public Object clone
Re: [Validator] Next Release
--- Niall Pemberton [EMAIL PROTECTED] wrote: I decided to have a go a resolving a couple of Struts bugs to do with bundles/resources and validator: http://issues.apache.org/bugzilla/show_bug.cgi?id=18169 http://issues.apache.org/bugzilla/show_bug.cgi?id=21760 Currently theres an inconsitency in how Struts handles bundles since although the validator dtd allows users to specify alternative bundles - Struts completely ignores them. Seems to me this is a big weakness in how handles Strut's bundles if validator can't take acount of them. Specifically Struts ignores the following validator DTD attributes: *the msg elements 'bundle' attribute *the msg elements 'resource' attribute *the arg elements 'bundle' attribute Fixing Struts required a couple of small changes to Commons Validator, which I've just done - it was already subject to the following outstanding bugzilla request: http://issues.apache.org/bugzilla/show_bug.cgi?id=29452 In order to now fix Struts there needs to be a release of Commons Validator with this change in and I'm wondering about the following: 1) Version 1.1.4 or Version 1.2.0 I wan't sure what the difference between the whats in the HEAD (Version 1.2.0) and the VALIDATOR_1_1_2_BRANCH (Version 1.1.3) - but from a quick scan a summary of the differences is: *Form Inheritance functionality (new extends attribute) *Loads of deprecations removed (including arg0 to arg3) *A number of minor bug fixes Those are the only differences I can remember. I guess it would be good to have only one branch and release Version 1.2.0 but I'm wondering whether the Form Inheritance is fully tested and working and also, given all the deprecations removed, whether it might be better (upgrade wise for the users) to release Version 1.1.4 from the VALIDATOR_1_1_2_BRANCH. I doubt form inheritance has been tested completely since it hasn't been included in a release yet. The branch name should have been VALIDATOR_1_1_BRANCH so that it could logically support multiple 1.1.x releases. However, it's not named that so I guess we'll just have to release 1.1.4 from that branch and deal with the minor confusion. I'd like to limit the number of releases in the 1.1 series and move on to 1.2 so we can get rid of the gross arg0-4 stuff for good. 2) Arg's Position Parameter - Bug 31194 == While doing this stuff on validator I came across the following enhancement request: http://issues.apache.org/bugzilla/show_bug.cgi?id=31194 It looked like a good idea and I've attached a patch for review which implements this request. Personally, if the decision is to go with a Version 1.2.0 release - I wouldn't want to upgrade to 1.2.0 without this enhancement being applied - when replacing arg0 - arg3 I could get away with not having to add a position attribute if this enhacement was done. I agree that automatic positioning should be included in 1.2.0. The easiest route - Struts wise is to go the Version 1.1.4 route. It would mean zero impact on the users, except having to drop the new jar in. Validator wise, we should probably get the Version 1.2.0 out of the door and just support one version. I'd rather go the 1.1.4 route but I'd appreciate hearing what others think. I think releasing a 1.1.4 is a good idea. This will give users yet another opportunity to notice the arg0-4 deprecation and change their xml accordingly. That will make for a smooth upgrade to 1.2.0 when it's finally released. If you cut a release, please update the changes.xml file because we're using that as our release notes. I usually update this file at the same time as making a code change or fixing a bug. Thanks so much for volunteering on validator Niall! David Niall __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] Java5.0 - Runtime exceptions or assertion errors. What's your preference?
The main reason not to use assertions is that they can be disabled at
runtime, rendering them fairly useless IMO. Personally, I would remove
the null parameter checking entirely and let the code throw a NPE. The
caller will see their offending method in the stack trace.
David
--- Chris Lambrou [EMAIL PROTECTED] wrote:
Hi,
Although I've marked the subject with [collections], I guess this is
targeted at anyone who has an interest in a Java 5.0 port of any jakarta
project. I'm slowly chipping away at a Java 5.0 port of
commons-collections. As I've been generifying the original collections
classes, I've found apart from a little bit of tidying here and there,
I've mostly been leaving the argument checking code at the start of most
constructors and/or factory methods alone. It's just occured to me that
all of these checks are explicit checks that throw some subclass of
RuntimeException. For example:
protected ClosureTransformer(Closure? super E closure)
{
if (closure == null) {
throw new IllegalArgumentException(Closure must not be
null);
}
this.closure = closure;
}
Since JDK1.4, the assert keyword has been available to replace this type
of error checking, but obviously it's not been used in collections in
order to maintain backwards compatibility with earlier versions of the
JDK. With the move to Java 5.0, backwards compatibility is no longer a
concern, and I'm considering replacing all such runtime argument checks
with assertions. For example:
protected ClosureTransformer(Closure? super E closure)
{
assert closure != null : Closure must not be null;
this.closure = closure;
}
I've heard both sides of the explict-check-and-RuntimeException versus
Assertions argument before in what feels like the dim and distant past,
but the discussion has always included the backwards compatibility
slant. I was wondering if anyone has any thoughts on the matter in
light of Java 5.0
Chris
P.S. If anyone's interested, the JDK 1.5 port of collections is
currently hosted on SourceForge at http://collections15.sourceforge.net
- I'd be interested in any feedback, particularly on the new generic
interfaces in the main package.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Check out the new Yahoo! Front Page.
www.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validator inside of Email.java (RE: [email] Dumbster failing)
As a validator committer I'd thought I'd share my 2 cents. I agree that validating the email address should be done by the user of [email]. If the address passed to [email] is invalid, the user will receive a MessageException just as they would expect from using JavaMail. Unfortunately, validator's dependency list is quite bloated at the moment so it would be painful for you to have a dependency on it because it will drag along a boatload of other components you don't need. We are working to correct that but it probably won't be as soon as you'd like :-). IMO, copy and pasting the validator code into email is a bad idea. This code is not stable and you will constantly be in catch up mode. Not to mention that coding technique is probably the worst thing a programmer can do. I just spent a *long* time deleting approximately 50% of a code base that now does what it used to do in half the code and half the time. We're better than this at Apache :-). Commons projects and Struts chose to get rid of the @author tags for some of these reasons: 1. They imply ownership over the code and create a territorial environment. This is community owned code and @author tags violate that spirit. 2. Apache code lives for many years and well past the original author's contributions. Does an @author tag from 10 years ago after major refactoring of the file still apply? 3. The source control system (CVS, Subversion, etc) is a more accurate tracking device for contributions. Username, date, comments, and release tags all say much more about a contribution than a simple @author tag. 4. The project contributors webpage is a good place for publicly recognizing people's contributions without affecting the code. David --- Matthias Wessendorf [EMAIL PROTECTED] wrote: 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] __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [email] Anyone interested?
--- Eric Pugh [EMAIL PROTECTED] wrote: 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? Sandbox projects are not allowed to have releases so you would need to get voted into commons proper before releasing 1.0. David -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] __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] Anyone working on this project?
What does MapMapHandler do? David --- Norris Shelton [EMAIL PROTECTED] wrote: I made a MapMapHandler and wanted someone to look at it to see if it is worth submitting. = Norris Shelton Software Engineer Sun Certified Java 1.1 Programmer Appriss, Inc. ICQ# 26487421 AIM NorrisEShelton YIM norrisshelton ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [feedparser] Getting Brad Neuberg CVS commit
It might be helpful to look at the Warning Signs portion of this page: http://jakarta.apache.org/site/newproject.html Several of them seem to apply to feedparser. David --- Craig McClanahan [EMAIL PROTECTED] wrote: On Thu, 21 Oct 2004 13:00:56 -0700, Kevin A. Burton [EMAIL PROTECTED] wrote: [snip] When a new projects is created are you telling me that you don't give CVS commit to the lead developers? How would IBM feel if when they contributed Xerces that you wouldn't give their lead engineers access to CVS? If you had gone through the incubation process (http://incubator.apache.org) the way that IBM is doing for Derby, or BEA is doing for Beehive, that is indeed what would have happened. However, I suspect there would have been pushback on a project with only two active developers, both working for the same company. Craig __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] bug id 30686
There isn't a javascript url validation yet. I'm not concerned at all about the performance of the regex. We just need it to work in all cases and tune it if there's a performance problem later. David --- Tim Reilly [EMAIL PROTECTED] wrote: Have you used the proposed patch for your projects? No. I was evaluating validator or really just a handful of classes from validator when I stumbled upon my basic test case failing. Instead of just filing a bug I decided to track it down, and sent patches too! I can take some time this week to look at it. Great. I know I sounded unconfident about the patch, actually its that I'm not confident that with the addition of * its most efficient regular expression. I know little to nothing about how regex engines reduce the expressions and evaluate them. But I'm confident regarding the addition of 'zero or more' clause from Martin's comments and also looking at the spec Martin referenced. Also the thoroughness of the test cases. I'll integrate this class into my project (why not.) I'm still not finding where the js counter-part for this lives? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Each Mutable Number class declares Serializable
Just like any other interface child classes inherit it from their parent. You can remove the implements Serializable from all Number subclasses. They're already Serializable since their parent class is. David --- Gary Gregory [EMAIL PROTECTED] wrote: Hello, I see that java.lang.Number declares java.io.Serializable. Number subclasses in java.lang do not but each of our Mutable number classes does. This does not seem necessary. Am I missing something? Can we remove these extra declarations? Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Code clean up of return (value);?
This shows up in Struts quite a bit and I think Craig uses this convention. I don't personally care for it because Java needs less syntax rather than more :-). David --- Gary Gregory [EMAIL PROTECTED] wrote: Hello, I've noticed in [lang] the use of extraneous parentheses in return statements: return (expr); I would like to change these to: return expr; I have some previous-life flashbacks of return (expr); being a C construct. I find that the extra parentheses makes the code harder to parse. Does anyone care to keep the extra parentheses? Thanks, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Im-/Ex-porter into Commons Sandbox
This will create bloat problems for clients that use Digester. For example: Struts uses Digester for xml parsing. In the future Struts may want to use the new i18n component. However, if i18n uses XML Im-Exporter then Struts must drag that along too despite already having a perfectly fine xml parser in its dependency list. Struts is just one example. It will be even worse for inter-commons project dependencies. Bad dependency management has plagued commons components and it's just recently started to get better. If all commons components use Digester then we can avoid having to duplicate functionality and bloat dependencies. I don't understand what's wrong with Digester that necessitates a new parsing library. I've been able to write complex parsing rules in a matter of minutes. David --- Oliver Zeigermann [EMAIL PROTECTED] wrote: Folks, on the request of Daniel Florey I'd like to create at least one new sandbox component for a tool that allows easy import / export of XML into / from Java. It is used by Jakarta Slide and in the components Daniel introduced. I know this is a bit delicate as there already is Digester around in commons. However, the audience for my tool is different from Digester's. XML Im-/Exporter is geared towards high performance use for people who are very familiar with XML. It is just a little bit more than pure SAX. It also has a different philosohie than Digester. Having said that I hope not to cause any inconvenience with this... Preparing this now and cheers, Oliver - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbutils] QueryRunner.query with no replacement params
--- jon gold [EMAIL PROTECTED] wrote:
i notice that QueryRunner.query always prepares a statement -- even if
there are no replacement parameters. why is this?
You don't need replacement parameters to benefit from caching and reusing
PreparedStatement instances.
the reason i ask is that it leads to undue bloat on a statement pool
when used in conjunction with a connection from a connection pool. in
our case, we eventually get OutOfMemoryErrors.
What pool implementation are you using? It seems like you could configure
the pool to not use up all your memory.
i've subclassed
QueryRunner in my application anyway, so it's not a big deal for me to
handle this locally, but it seems like it would be nice to replace the
block:
PreparedStatement stmt = null;
ResultSet rs = null;
Object result = null;
try {
stmt = this.prepareStatement(conn, sql);
this.fillStatement(stmt, params);
rs = this.wrap(stmt.executeQuery());
...
with
Statement stmt = null;
ResultSet rs = null;
Object result = null;
try {
if ( params != null ) {
stmt = this.prepareStatement(conn, sql);
this.fillStatement((PreparedStatement)stmt, params);
rs = this.wrap(stmt.executeQuery());
}
else {
stmt = conn.createStatement();
rs = this.wrap(stmt.executeQuery(sql);
}
...
that way if i want to prepare and keep a no-param statement, i pass in a
non-null but empty Object[] for params. if i want to say just run this
statement but throw it away, then i pass in null (ie, just call
QueryRunner.query( sql, rsh ) as is.
While that is certainly doable it's not at all clear to the user of the
API. They have to remember that null indicates a special behavior which
is almost always confusing and error prone.
I really don't see this as a DbUtils problem. QueryRunner is doing its
best to provide good performance by using PreparedStatements. A
connection/statement pool should allow you to configure its maximum size
so it doesn't use all your memory. If it doesn't, subclassing QueryRunner
for these special cases is the best solution.
David
jon
___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [validator] ISBNValidator
Validator uses the standard Java coding conventions. Considering I don't
know anything about ISBN numbers I would need a JUnit test case proving it
works and some javadoc describing the ISBN rules before I would commit
anything. Add the Apache 2.0 license to the top of your .java files
before attaching them to a new bugzilla enhancement ticket. See other
validator source files for an example you can cut and paste.
Thanks!
David
--- Mark Lowe [EMAIL PROTECTED] wrote:
Hello
I've just written an ISBN validator I don't think i can diff a file
that doesn't exist. But i'd like to see if its of use to anyone other
than myself.
I've attached it and i'll just check the commons stuff out of cvs and
see if there's a jalopy template that could iron out anything that
would be displeasing to anyone in terms of coding.
What do i have to do to get this committed?
I still need to add an option to switch checking the regular expression
off in case folk want to use it to check numbers with no hyphens or
spaces. At the moment the input can be either.
Mark
package com.boxstuff.bookshop.util;
import org.apache.oro.text.perl.Perl5Util;
/**
*pA class for validating ISBN numbers.
* Based on document a
href=http://www.isbn.org/standards/home/isbn/international/html/usm4.htm;
*
http://www.isbn.org/standards/home/isbn/international/html/usm4.htm/a/p
* @author a href=mailto:[EMAIL PROTECTED]Mark Lowe/a
*/
public class ISBNValidator {
/**
* @return isbn regular expression
*/
private final static String ISBN_NUMBER_PATTERN = ([0-9 ]|-){11}(-|
)[0-9X];
/**
* @return isbn regular expression including ISBN prefix
*/
private final static String ISBN_PATTERN = (ISBN[= ])? +
ISBN_NUMBER_PATTERN;
/**
* pEmpty contructor./p
*/
public ISBNValidator() {
}
/**
* pFirst checked against reqular expression to see if hyphens or
spaces are correct.
* Second validates actual number. ISBN is weighted from length to
penultimate number which is used as a control number.
* The sum of each digit and respective weight is calcuated into a
total along with the conrtol number.
* If the total returns 0 for modulus 11 it returns valid./p
*
* @param isbn Candidate ISBN number to be validated.
* @return whether the number is valid or not.
*/
public boolean isValid(String isbn) {
boolean result = false;
if (!isValidPattern(isbn)) {
return false;
}
isbn = clean(isbn);
int j = isbn.length();
int total = 0;
int sum = 0;
int num = 0;
int control =
Character.getNumericValue(isbn.charAt(isbn.length() - 1));
for (int i = 0; (i isbn.length()) (j = 2); i++) {
num = Character.getNumericValue(isbn.charAt(i));
sum = j * num;
total = total + sum;
j--;
}
total = total + control;
result = (total % 11) == 0;
return result;
}
/**
* @param isbn The string to be cleaned before full validation.
* @return clean isbn string without any non digits.
*/
private String clean(String isbn) {
String result = ;
int j = 0;
for (int i = 0; i isbn.length(); i++) {
char ch = isbn.charAt(i);
if (Character.isDigit(ch)) {
result += ch;
}
}
return new String(result);
}
/**
* @param isbn Full isbn code
* @return whether the isbn code fits matches regular expression
* @see org.apache.oro.text.perl.Perl5Util#match
*/
private boolean isValidPattern(String isbn) {
Perl5Util regexpValidator = new Perl5Util();
return regexpValidator.match(/ + ISBN_NUMBER_PATTERN + /,
isbn);
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DbUtils] QueryLoader
Please open a bugzilla ticket and attach a cvs diff -u formatted patch if you have one. Thanks! David --- [EMAIL PROTECTED] wrote: I have a problem using QueryLoader when deployed in a .war file to weblogic. The properties file cannot be located on the classpath. QueryLoader uses QueryLoader.class.getResourceAsStream(path) which looks for a resource relative to the current class (QueryLoader), you can use / to indicate classpath root but this does not work with weblogic possibly due to the way in which weblogic manages the classpath for .war files. If I use getClass().getClassLoader().getResourceAsStream(path) instead and dont use leading / for the path then this works locally and for weblogic. Any comments Jason IMPORTANT NOTICE Email from OOCL is confidential and may be legally privileged. If it is not intended for you, please delete it immediately unread. The internet cannot guarantee that this communication is free of viruses, interception or interference and anyone who communicates with us by email is taken to accept the risks in so doing. Without limitation, OOCL and its affiliates accept no liability whatsoever and howsoever arising in connection with the use of this email. Under no circumstances shall this email constitute a binding agreement to carry or for provision of carriage services by OOCL, which is subject to the availability of carrier's equipment and vessels and the terms and conditions of OOCL's standard bill of lading which is also available at http://www.oocl.com. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBUtils] additional DBUtils class helper methods request
Done. This will be in the next nightly build. David --- Kyle Miller [EMAIL PROTECTED] wrote: Could you please add the following two methods to the DBUtils helper class: rollbackAndClose(...); rollbackAndCloseQuietly(...); to mimic the commit and close methods. Thanks, Kyle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving from Bugzilla to JIRA
-1 on moving to JIRA. Martin Cooper has indicated there are people in infrastructure are willing to do a bugzilla upgrade. Just because bugzilla's UI is ugly and JIRA's is pretty is not a valid reason to switch to proprietary software in an OSS community. Regardless, many other bugzilla installations including Red Hat's demonstrate bugzilla is skinnable. I can read the Slashdot headlines now: Apache abandons Bugzilla in favor of proprietary software. IMO, this switch is bad for our community. David --- Paul Libbrecht [EMAIL PROTECTED] wrote: I'd also be +1 but I am a bit bothered by the political impact of depending on a commercial product as strong open-source veteran. Currently +0. If Bugzilla skins would exist (they are possible) and be used and usable, I think such discussion would be way more futile. Unfortunately, I haven't seen any. As of Scarab, I still haven't managed to get a demo-account to be opened for me on any demo-server... which is not a really good sign, I feel. paul PS: the bugzilla/jira opposition is a real feel for open-source can't do GUIs wich is really something a bit too widespread. PPS: I haven't done it but you can export all Bugzilla bugs of one product and only keep the ones for a given component, leaving quiet the bugzilla ones... so the need for a complete migration isn't really there except it takes more time to migrate a single component. Le 3 sept. 04, à 14:24, Henri Yandell a écrit : I'd like to be using JIRA rather than Bugzilla. Release planning feels possible in JIRA, whereas in Bugzilla it always feels like something so painful it is not worth the effort you'd have to put in. In fact, I'm currently using the Wiki to try to simulate the release process in JIRA :) +1 Hen On Fri, 3 Sep 2004, [iso-8859-1] Eduardo Sebastián Marco wrote: I think it should be necessary to have a vote, but I don't think like Gary does. I think the matter here is not whether we support opensource or not... Of course we do! I think the matter here is excelence. And in my opinion, if there's something actually better and it's avalaible, why not? Is that or getting involved on the lesser tool to make it better. Eduardo. -Mensaje original- De: Gary Gregory [mailto:[EMAIL PROTECTED] Enviado el: viernes, 03 de septiembre de 2004 1:59 Para: Jakarta Commons Developers List; Dion Gillard Asunto: RE: Moving from Bugzilla to JIRA On principle, I am not in favor of moving /away/ from Bugzilla, an open-source project, to Jira, a non-open-source project. It feels to me that this would send a negative message, as in: we are not supporting the open-source community. OTOH, this is software evolution at work. I have heard good things about JIRA, but not used it much beyond filing a couple of tickets vs. Maven. Gary -Original Message- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Thursday, September 02, 2004 15:40 To: Jakarta Commons Developers List Subject: Moving from Bugzilla to JIRA I've found out that the JIRA import process from Bugzilla can only import a whole project, and not components, and hence all of jakarta-commons has to go together. Does anyone still want to stay on Bugzilla? Do we need a vote for this? -- http://www.multitask.com.au/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBUtils] BeanProcessor enhancement request
BeanProcessor.newInstance() is now protected. The change should show up in the next nightly build. David --- Kyle Miller [EMAIL PROTECTED] wrote: I have a JavaBean that needs to be populated from 3 different select statements, unfortunately DBUtils BeanProcessor doesn't support the reuse of beans, it instantiates a new instance each time. I would like to see more of the methods in BeanProcessor be protected instead of private. I like the JavaBean processing in BeanProcessor, and I don't want to reimplement it. However I would like to override the newInstance method to return an existing object instead of new instance. I can also think of instances where someone may want to override the isCompatableType method. I have implemented a BeanReuseProcessor that works with a single bean or a list of beans, and it is fully junit tested. It required changing the visibilty of BeanProcessor.newInstance(...) to protected, so I would like to get the changes added to CVS so I don't have to keep hacking the source every for every release. I think this is a useful enhancement, and I would like to contribute it to the project. Please let me know what you think. -- Kyle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Interpolation
--- matthew.hawthorne [EMAIL PROTECTED] wrote:
I agree that it's bad news.
But, I think the worst offense is this:
try {
// ...
} catch (Exception e) {
return null;
}
(shudder)
I've seen plenty of this to; it's truly horrifying :-).
try {
// ...
} catch (Throwable e) {}
David
__
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Worst offence in Java :) Re: [lang] Interpolation
--- Henri Yandell [EMAIL PROTECTED] wrote:
On Sat, 28 Aug 2004, matthew.hawthorne wrote:
IMO, copy-paste reuse is the worst offense that a programmer can
commit.
I agree that it's bad news.
But, I think the worst offense is this:
try {
// ...
} catch (Exception e) {
return null;
}
(shudder)
How lucky you've been. Have you never seen:
try {
...
} catch(Throwable t) {
// ignore
}
At least there was a comment in there :-). I've seen a shocking number of
these: catch(Throwable t) {} from programmers that knew it wouldn't
matter.
David
??? :)
Hen
___
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Interpolation
--- Stephen Colebourne [EMAIL PROTECTED] wrote: snip Potentially, we could use the digester version to start from. (In new commons style, there would be copy-paste with reference to original, not dependency) That is not the new commons style. That was a temporary solution to removing commons-collections dependencies from other commons projects that didn't actually need collections. IMO, copy-paste reuse is the worst offense that a programmer can commit. If we start doing this in commons it will be more ridiculed, and rightfully so, than it already is. David ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/validator project.xml
Welcome aboard James! I noticed you misspelled your email address so I saved you some time and added [EMAIL PROTECTED] to some lists I thought you might enjoy :-). David --- [EMAIL PROTECTED] wrote: jmitchell2004/08/27 09:17:28 Modified:validator project.xml Log: Volunteer myself - no applause, just send money :P Revision ChangesPath 1.51 +7 -1 jakarta-commons/validator/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/validator/project.xml,v retrieving revision 1.50 retrieving revision 1.51 diff -u -r1.50 -r1.51 --- project.xml 11 Jun 2004 20:51:57 - 1.50 +++ project.xml 27 Aug 2004 16:17:28 - 1.51 @@ -1,4 +1,4 @@ -?xml version=1.0 encoding=UTF-8? +?xml version=1.0 encoding=UTF-8? !-- Copyright 2003-2004 The Apache Software Foundation @@ -121,6 +121,12 @@ idmrdon/id email[EMAIL PROTECTED]/email organization/organization +/developer +developer + nameJames Mitchell/name + idjmitchell/id + emailjmitchell NOSPAM apache.org/email + organizationEdgeTech, Inc/organization /developer /developers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] logging
DbUtils intentionally does not use logging but it is rather small and doesn't really need it. Validator has very little logging usage and that dependency could probably be removed. Most of what it used to log was better handled by throwing an exception out to the framework to the users. I like the fact that DbUtils is distributed as just a single dbutils.jar but that's not a requirement I would place on other commons components. David --- Henri Yandell [EMAIL PROTECTED] wrote: (probably flamebait) Why do so many of our components require logging of some form or another? (usually commons-logging). I can see why a micro-framework like Digester might be nice to have debugging statements, and might want an error system better than Exceptions as the rules can be tricky to write sometimes, but for a simple component-library like beanutils it seems like overkill. Even if we were using java.util.logging, it would still seem like overkill for a library to require logging. The following all depend on logging. Seems like a lot: beanutils betwixt chain configuration digester el httpclient jexl jxpath latka launcher math modeler validator (sandbox) cli messenger periodicity resources scaffold sql threadpool vfs xo Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Interpolation
Interpolation is well understood by Perl programmers. It's probably a good idea to use a term that many other people already know. Of course, if it doesn't really do interpolation in the Perl sense of the word an alternate name would be a good idea to prevent confusion. David --- Gary Gregory [EMAIL PROTECTED] wrote: Hello, I'm just taking a quick look at Interpolation. (1) Does it belong? I was at first a little surprised to see something so script-like in [lang]. I guess it does not feel like something that is missing in java.lang. OTOH, we are just talking about another form of String search and replace, so it does make sense under that umbrella. (2) The name Interpolation and interpolate. I must say that I am a bit turned off by these somewhat mathematical names. This class is more of String matcher or replacer thingy. What does Ant call these things? Interpolation.interpolate( templateString, valuesMap ); (3) Usage. I'd like that class to be more flexible in order to do the following for example: Interpolation interpolation = new Interpolation(); interpolation.setStartMarker(); interpolation.setEndMarker(); interpolation.setMap(aMap); String news = interpolation.interpolate(templateString); Cheers, Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Completing the 1.1.3 GA release
It looks like all commons sites built with Maven 1.0 lost the plus sign. I'm not sure what the deal is with the RSS image. Oddly, the stylesheets didn't get copied into the style directory for the validator build but were copied for the dbutils build. I just copied the stylesheets manually before uploading the validator site. David --- Martin Cooper [EMAIL PROTECTED] wrote: On Tue, 24 Aug 2004, David Graham wrote: I checked in release notes for 1.1.3 and 1.2.0-dev in changes.xml for all the bugzilla tickets I could find. I set the 1.1.3 release date as the 25th; please change as necessary. The website is now updated. Great! Thanks, David. I'll send out the announcement. One thing I noticed in the site refresh is that we lost the 'plus sign in a box' indicators of openable items on the nav bar, and we're missing an icon for RSS. Probably one of those Maven things... -- Martin Cooper David --- Martin Cooper [EMAIL PROTECTED] wrote: OK, there's just one more thing that needs to happen before I send out the announcement. The download page now links to the changes report, mentioned by David below. However, the changes report on the site doesn't include the changes for 1.1.3, since the site is very out of date. Unfortunately, my Maven config is all messed up at the moment, so I'm not in a position to fix this. If someone else could please regenerate the site and upload it, then we'll be all set. -- Martin Cooper PS - Sorry this is taking so long! On Fri, 20 Aug 2004, David Graham wrote: --- Martin Cooper [EMAIL PROTECTED] wrote: I noticed that we don't seem to have a Release Notes file for 1.1.3 as we did for 1.0.2, so the release notes on the site are still the old ones. If someone would like to come up with a Release Notes file for 1.1.3, please let me know. Otherwise, I'll need to remove the old one. We don't use a release notes file in validator; we use changes.xml which generates this nice report: http://jakarta.apache.org/commons/validator/changes-report.html David __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Completing the 1.1.3 GA release
I will update the site this evening unless someone beats me to it. David --- Martin Cooper [EMAIL PROTECTED] wrote: OK, there's just one more thing that needs to happen before I send out the announcement. The download page now links to the changes report, mentioned by David below. However, the changes report on the site doesn't include the changes for 1.1.3, since the site is very out of date. Unfortunately, my Maven config is all messed up at the moment, so I'm not in a position to fix this. If someone else could please regenerate the site and upload it, then we'll be all set. -- Martin Cooper PS - Sorry this is taking so long! On Fri, 20 Aug 2004, David Graham wrote: --- Martin Cooper [EMAIL PROTECTED] wrote: I noticed that we don't seem to have a Release Notes file for 1.1.3 as we did for 1.0.2, so the release notes on the site are still the old ones. If someone would like to come up with a Release Notes file for 1.1.3, please let me know. Otherwise, I'll need to remove the old one. We don't use a release notes file in validator; we use changes.xml which generates this nice report: http://jakarta.apache.org/commons/validator/changes-report.html David __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Completing the 1.1.3 GA release
I checked in release notes for 1.1.3 and 1.2.0-dev in changes.xml for all the bugzilla tickets I could find. I set the 1.1.3 release date as the 25th; please change as necessary. The website is now updated. David --- Martin Cooper [EMAIL PROTECTED] wrote: OK, there's just one more thing that needs to happen before I send out the announcement. The download page now links to the changes report, mentioned by David below. However, the changes report on the site doesn't include the changes for 1.1.3, since the site is very out of date. Unfortunately, my Maven config is all messed up at the moment, so I'm not in a position to fix this. If someone else could please regenerate the site and upload it, then we'll be all set. -- Martin Cooper PS - Sorry this is taking so long! On Fri, 20 Aug 2004, David Graham wrote: --- Martin Cooper [EMAIL PROTECTED] wrote: I noticed that we don't seem to have a Release Notes file for 1.1.3 as we did for 1.0.2, so the release notes on the site are still the old ones. If someone would like to come up with a Release Notes file for 1.1.3, please let me know. Otherwise, I'll need to remove the old one. We don't use a release notes file in validator; we use changes.xml which generates this nice report: http://jakarta.apache.org/commons/validator/changes-report.html David __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Completing the 1.1.3 GA release
--- Martin Cooper [EMAIL PROTECTED] wrote: I noticed that we don't seem to have a Release Notes file for 1.1.3 as we did for 1.0.2, so the release notes on the site are still the old ones. If someone would like to come up with a Release Notes file for 1.1.3, please let me know. Otherwise, I'll need to remove the old one. We don't use a release notes file in validator; we use changes.xml which generates this nice report: http://jakarta.apache.org/commons/validator/changes-report.html David __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBUtils] Oracle 9.2.0 JDBC Timestamp Problem
Thanks for finding this! It would be best to open a bugzilla ticket so
the issue isn't lost or forgotten.
Thanks,
David
--- Rolf Moser [EMAIL PROTECTED] wrote:
Hello
I just run into a Timestamp problem with the Oracle 9i (9.2.0) JDBC
Driver
When calling rs.getObject(index) on a DB field, defined as Timestamp(6),
the resulting object is a oracle.sql.TIMESTAMP and not a
java.sql.Timestamp as with other JDBC Drivers. This leads to a null
value propagation if your Bean Property is defined as
java.sql.Timestamp.
If calling rs.getTimestamp(index), Oracle correctly converts the
resulting value to a java.sql.Timestamp object.
I looked at the current source and added the following statement to the
BeanProcessor processColumn Method as a workaround:
} else if(propType.equals(Timestamp.class)) {
return rs.getTimestamp(index);
This ensures that for a Bean property of type java.sql.Timestamp the
getTimestamp() method is called.
Otherwise the default getObject() mehod is called, so there souldn't be
a problem if someone wants the Oracle enhanced oracle.sql.TIMESTAMP
object.
Regards
Rolf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBUtils] Oracle 9.2.0 JDBC Timestamp Problem
This change makes sense in DbUtils because we're already explicitly
calling ResultSet.get* methods for other types. It doesn't hurt to add
getTimestamp() to that list.
All concrete implementations of JDBC interfaces were removed from DbUtils
because of incompatibilities between JDK versions. We replaced them with
the ProxyFactory class which allows you to build dynamic wrappers.
David
--- Henri Yandell [EMAIL PROTECTED] wrote:
setObject is also quite screwed, and setTimestamp used to do some weird
stuff in Oracle 9, unsure about their new driver.
My planned solution to this was to create a specific wrapper driver for
Oracle that fixes Oracle's bugs, rather than put the fixes into things
like dbutils.
Need to find that code again. DbUtils used to have an 'extended' driver
concept that you could extend and put fixes like this in, but JDBC 2 vs
3
made it get taken out of DbUtils I think.
Not a negative to the patch by the way, just an info dump having seen
this
problem before.
Hen
On Wed, 18 Aug 2004, David Graham wrote:
Thanks for finding this! It would be best to open a bugzilla ticket
so
the issue isn't lost or forgotten.
Thanks,
David
--- Rolf Moser [EMAIL PROTECTED] wrote:
Hello
I just run into a Timestamp problem with the Oracle 9i (9.2.0) JDBC
Driver
When calling rs.getObject(index) on a DB field, defined as
Timestamp(6),
the resulting object is a oracle.sql.TIMESTAMP and not a
java.sql.Timestamp as with other JDBC Drivers. This leads to a null
value propagation if your Bean Property is defined as
java.sql.Timestamp.
If calling rs.getTimestamp(index), Oracle correctly converts the
resulting value to a java.sql.Timestamp object.
I looked at the current source and added the following statement to
the
BeanProcessor processColumn Method as a workaround:
} else if(propType.equals(Timestamp.class)) {
return rs.getTimestamp(index);
This ensures that for a Bean property of type java.sql.Timestamp the
getTimestamp() method is called.
Otherwise the default getObject() mehod is called, so there souldn't
be
a problem if someone wants the Oracle enhanced oracle.sql.TIMESTAMP
object.
Regards
Rolf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.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]
__
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Completing the 1.1.3 GA release
That sounds like a good plan to me Martin. Thanks, David --- Martin Cooper [EMAIL PROTECTED] wrote: We voted on this a while back, and the outcome was positive. As far as I'm aware, all that needs to happen to complete the process is: * Notify the PMC of the successful vote. * Move the release to the mirror location. * Announce the new release. Anything else that we need to do, or should I just start doing this? -- Martin Cooper - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release beanutils 1.7.0
+1 David --- robert burrell donkin [EMAIL PROTECTED] wrote: the release candidate has been available for a week now with no problems reported. there have been a number of small improvements to the documentation since then but no major changes to the code base. i would therefore like to propose that we cut beanutils 1.7.0 from the head of the release branch. this vote will be conducted on the commons-dev list and i will tally no earlier than 2200 GMT on this coming friday, the 30th. here's my +1 - robert -8 [ ] +1 I fully support this release [ ] +0 I give qualified support to this release [ ] -0 I have reservations about this release [ ] -1 This release should not be cut --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] DBUtils : workaround for Oracle NUMBER datatype
Download a recent nightly build. This problem has already been fixed. David --- John Pederzolli [EMAIL PROTECTED] wrote: This patch allows the object get/set datatypes to be float, double, or int (if possible). The current codebase requires get/set datatypes to be BigDecimal. Index: BasicRowProcessor.java === RCS file: /home/cvspublic/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java,v retrieving revision 1.10 diff -r1.10 BasicRowProcessor.java 2c2,58 * Copyright 2002-2004 The Apache Software Foundation --- * $Header: /home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java,v 1.5 2003/11/11 00:53:19 dgraham Exp $ * $Revision: 1.5 $ * $Date: 2003/11/11 00:53:19 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 2002-2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowledgement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgement may appear in the software itself, *if and wherever such third-party acknowledgements normally appear. * * 4. The names The Jakarta Project, Commons, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. 4,14d59 * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an AS IS BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. 15a61 17a64,69 import java.beans.BeanInfo; import java.beans.IntrospectionException; import java.beans.Introspector; import java.beans.PropertyDescriptor; import java.lang.reflect.InvocationTargetException; import java.lang.reflect.Method; 20a73 import java.util.ArrayList; 24a78 import java.math.BigDecimal; 28,32c82,83 * * p * This class is thread-safe. * /p * --- * This class is a thread-safe Singleton. * 33a85,89 * * @author Henri Yandell * @author Juozas Baliuka * @author David Graham * @author Yoav Shapira 38,39c94,113 * The default BeanProcessor instance to use if not supplied in the * constructor. --- * Set a bean's primitive properties to these defaults when SQL NULL * is returned. These are the same
Re: [PATCH] DBUtils : workaround for Oracle NUMBER datatype
If you're using the latest code in cvs and this isn't working then it's probably a bug. The BeanProcessor.isCompatibleType() and BeanProcessor.processColumn() methods are the likely sources of the problem. Please open a bugzilla ticket and attach a cvs diff -u formatted patch file. Thanks, David --- John Pederzolli [EMAIL PROTECTED] wrote: Actually I was working off a new cvs checkout. The problem I was referring to was the following: say you have an object with methods int getAccount() and setAccount(int), and the account is stored as a number datatype in oracle. If you are using the BeanListHandler to run a query, the account will always be set to zero regardless of the data stored. The patch I wrote fixed this ; I realize that the number datatype is not ideal for account, this is just an example... On Wed, 14 Jul 2004 11:24:54 -0700 (PDT), David Graham [EMAIL PROTECTED] wrote: Download a recent nightly build. This problem has already been fixed. David --- John Pederzolli [EMAIL PROTECTED] wrote: This patch allows the object get/set datatypes to be float, double, or int (if possible). The current codebase requires get/set datatypes to be BigDecimal. Index: BasicRowProcessor.java === RCS file: /home/cvspublic/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java,v retrieving revision 1.10 diff -r1.10 BasicRowProcessor.java 2c2,58 * Copyright 2002-2004 The Apache Software Foundation --- * $Header: /home/cvs/jakarta-commons/dbutils/src/java/org/apache/commons/dbutils/BasicRowProcessor.java,v 1.5 2003/11/11 00:53:19 dgraham Exp $ * $Revision: 1.5 $ * $Date: 2003/11/11 00:53:19 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 2002-2003 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowledgement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowledgement may appear in the software itself, *if and wherever such third-party acknowledgements normally appear. * * 4. The names The Jakarta Project, Commons, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. 4,14d59 * Licensed under the Apache License, Version 2.0 (the License); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless
RE: [VOTE] [codec] Release 1.3-RC1
--- Gary Gregory [EMAIL PROTECTED] wrote: snip/ Unsure if we've standardised on the Maven Feather logo or not. I thought I'd use the same one as the Maven site. The feathery one doesn't look too hot to me, it also jumps out too much IMHO since it has a white background and the bg for the area is grey. FWIW, I disable the Maven icon on all projects I work on. Do our users really care what we build our website with? David __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] [codec] Release 1.3-RC1
+1 David --- Scott Sanders [EMAIL PROTECTED] wrote: On Jun 29, 2004, at 4:21 PM, Gary Gregory wrote: This vote is to approve the public release of commons codec 1.3-RC1. [X] +1 Go ahead and release 1.3-RC1 [ ] +0 [ ] -0 [ ] -1 Don't release 1.3-RC1, because... - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [chain] Deploying new website
--- Don Brown [EMAIL PROTECTED] wrote: I moved the chain cvs from sandbox to commons proper (long story) and have updated the build and doc files such that the website builds and is ready for deployment. I have not modified the site source for the jakarta website pending deployment of the new chain site. Should I manually deploy the website and if so, what does this involve? I don't know of any other way than manual. I just log into cvs.apache.org and navigate to /www/jakarta.apache.org/commons/chain (not sure if that's exactly the right path), tar up the existing site, untar the new site into that directory and you're done. If anything goes wrong I just untar the old version. The site is built with 'maven clean site'. Hope that helps, David Thanks. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] 1.1.3 ALPHA release available
I downloaded the binary distro and everything looked in order. David --- Ted Husted [EMAIL PROTECTED] wrote: I've tagged the 1.1.2 branch, and rolled the Validator 1.1.3 alpha release. It is posted in my Apache home directory for review: - http://www.apache.org/~husted/validator/v1.1.3/ Please review the release and advise whether you believe we should promote the release to Beta or General Release quality. I'm still reviewing the signing procedures, and should this release past the Alpha stage, I will sign and mirror it as appropriate. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DbUtils] ClassCastException
What does your DbUtil line 143 look like? When you set a breakpoint at
that line and inspect it in your debugger what is the class being
returned?
David
--- Anderson, James H [IT] [EMAIL PROTECTED] wrote:
I'm getting a ClassCastException that I don't understand. I hope someone
can help with this, because I'd very much like to be able to use DbUtil
on my project!
The stack trace:
org.apache.commons.dbutils.BasicRowProcessor$CaseInsensitiveHashMap
java.lang.ClassCastException:
org.apache.commons.dbutils.BasicRowProcessor$CaseInsensitiveHashMap
at com.ssmb.recom.aft.access.DbUtil.select(DbUtil.java:143)
at com.ssmb.recom.aft.access.DbUtil.selectOneMapTrimmed(DbUtil.java:66)
at
com.ssmb.recom.aft.datamanager.AftRequests.nextBusinessDate(AftRequests.java:3454)
at
com.ssmb.recom.aft.datamanager.AftRequests.nextBusinessDateAfter(AftRequests.java:3489)
at
com.ssmb.recom.aft.datamanager.AftRequests.main(AftRequests.java:2920)
The invoking code:
java.sql.Date sqlDate = new java.sql.Date( date.getTime() );
String selectTradingDate = select trading_date from trade_days
where trading_date = ? and banking_day = 'B';
Object[] params = { sqlDate };
boolean commit = true;
Map h = null;
try {
h = (Map) DbUtil.selectOneMapTrimmed(selectTradingDate,
params, commit);
} catch (Exception e) {
logger.error(No trade date = + date, e);
throw new RuntimeException(e.getMessage());
}
java.util.Date tradeDate = (java.util.Date)
h.get(trading_date);
My wrapper code as invoked in the code, above:
package com.ssmb.recom.aft.access;
import java.sql.*;
import java.util.*;
import org.apache.commons.dbutils.*;
import org.apache.commons.dbutils.handlers.*;
import org.apache.commons.dbutils.wrappers.*;
import org.apache.commons.beanutils.BeanUtils;
import com.ssmb.recom.datamgr.RecomDataSource;
public class DbUtil {
[...]
/**
select one row, set param=null to avoid parameter substitution
*/
public static Object selectOneMapTrimmed(String query, Object[] param,
boolean commit)
throws Exception {
MapHandler h = new MapHandler() {
public Object handle (ResultSet rs) throws
SQLException {
StringTrimmedResultSet wrapped = new
StringTrimmedResultSet(rs);
rs =
ProxyFactory.instance().createResultSet(wrapped);
Object returnVal = null;
try {
returnVal = super.handle(rs);
} catch (SQLException e) {
System.out.println(e.getMessage());
throw e;
}
return returnVal;
}
};
if (param == null) {
return select(query, h, commit);
} else {
return select(query, param, h, commit);
}
}
[...]
}
The table being queried:
table database creatorcreated
-- -- -- --
trade_days db2tst08 vimdbat06/20/2000
column type length scale nulls
-- -- - -
trading_date date 4 0 y
trading_daychar 1 0 y
trading_dowsmallint 2 0 y
banking_daychar 1 0 y
Note:
When I execute this query using vanilla JDBC, everything works fine.
Any help appreciated,
jim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DbUtils] What's about protected QueryRunner.prepareConnection()?
Replacing calls to ds.getConnection() with prepareConnection() sounds reasonable. Please open an enhancement ticket. Thanks, David --- Mikhail Krivoshein [EMAIL PROTECTED] wrote: Hello all, Currently QueryRunner has prepareStatement() method that is used to create a new statements. I think there is sense to go further and create prepareConnection() method that will be used to create a new connections (and tune them). Idea behind this is to provide protected method that can't be used in derived QueryRunners to tune connection establishing code. I presonally want to override such prepareConnection() method in MyQueryRunner and make conn.setAutoCommit(false); call there. Looking forward to hear comments. If you decide that this is a good idea, I'm ready to prepare a patch. Best regards, Mikhail Krivoshein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Commons Chain to Commons Proper
+1 David --- Joe Germuska [EMAIL PROTECTED] wrote: At 6:40 PM -0400 6/9/04, Don Brown wrote: I propose Commons Chain should graduate to Commons Proper. I'm not sure what justification I should give other than Struts is planning on including it in future releases, and I personally am, as I've already mentioned, using commons-chain in a production application to help decompose complex data importing/transformation processes in addition to using it with struts-chain in a different application. I don't see any bugs against it in bugzilla, and have personally experienced no problems. This is a non-binding +1, as I'm not a commons committer -- but I've got at least one production app running off of struts-chain (and thus commons-chain) so it seems ready for leaving the sandbox, if nothing else! Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place. - Carlos Santana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Collections dependencies
--- Stephen Colebourne [EMAIL PROTECTED] wrote: Actually, the removal of collections classes from validator will take a bit longer. We still have protected FastHashMap variables that need to be replaced with Maps. the collections packaged FashHashMap and it's dependencies are binary compatible (in 2.x and 3.x collections - actually, they are identical) and will be included as part of the next beanutils release. beanutils, validator and digester are in similar positions (and i suspect from craig's comments earlier that struts is also) they need the FastHashMap class (at least so that it can be deprecated) but they don't need the other classes which have changed. so, those classes they need will be included as part of the beanutils distribution. therefore, it will be possible to remove the collections dependency by upgrading to the upcoming beanutils. this will allow FastHashMap to be repackaged or removed (as appropriate) in due course after deprecation. I am +1 to the removal of the [collections] dependency here. However I must express caution at the implications of what seems to be described here. The idea appears to be that [validator] will obtain its copy of FastHashMap from [beanutils]. But this class will only be present in one release (1.7?) of [beanutils] and after that my understanding is that it will be removed. This would appear to be a very risky way of handling this, as you create a new dependency hell between [validator] and one specific release of [beanutils]. If I have understood correctly, I will -1 a valiator release :-( If the aim is to remove the [collections] depencency now, then FastHashMap should be copied (no package rename) to [validator] too. However, FastHashMap has not changed between [collections] 2.1 and 3.x, so perhaps removing the dependency is not urgent? We can deprecate the uses of FastHashMap in Validator for its upcoming release and replace them with Map and HashMap references for the following release. I'm against copying FastHashMap into Validator because that's a stopgap measure for BeanUtils and Digester only. David Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/validator/src/test/org/apache/commons/validator validator-bsf.xml
I thought we agreed to add BSF and JXPath validators to a contrib directory so we wouldn't bloat the dependencies needed to distribute the core validator? I'm -1 on adding dependencies in the core distro. David --- [EMAIL PROTECTED] wrote: husted 2004/06/08 07:53:12 Added: validator/src/test/org/apache/commons/validator validator-bsf.xml Log: Apply #29205 Add BSFValidator, submitted by Don Brown. Revision ChangesPath 1.1 jakarta-commons/validator/src/test/org/apache/commons/validator/validator-bsf.xml Index: validator-bsf.xml === !DOCTYPE form-validation PUBLIC -//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1//EN http://jakarta.apache.org/commons/dtds/validator_1_1.dtd; form-validation global validator name=bsf classname=org.apache.commons.validator.BSFValidator method=isValid methodParams=java.lang.Object,org.apache.commons.validator.Field msg=/ /global formset form name=bsfForm field property=value depends=bsf var var-nameeval/var-name var-valuevalue.equals(foo)/var-value /var /field /form form name=bsfForm-numeric field property=value depends=bsf var var-nameeval/var-name var-valueInteger.parseInt(value)0 amp;amp; Integer.parseInt(value)lt;100/var-value /var /field /form form name=bsfForm-nested field property=object depends=bsf var var-nameeval/var-name var-valuevalue.value.equals(foo)/var-value /var /field /form /formset /form-validation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/validator/src/share/org/apache/commons/validator GenericValidator.java
The new methods need @since javadoc tags.
David
--- [EMAIL PROTECTED] wrote:
husted 2004/06/08 08:22:29
Modified:validator/src/share/org/apache/commons/validator
GenericValidator.java
Log:
Apply #29015 Add support for min or max numeric values submitted by
Jon Wilmoth
Revision ChangesPath
1.32 +85 -3
jakarta-commons/validator/src/share/org/apache/commons/validator/GenericValidator.java
Index: GenericValidator.java
===
RCS file:
/home/cvs/jakarta-commons/validator/src/share/org/apache/commons/validator/GenericValidator.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- GenericValidator.java 11 Apr 2004 06:47:22 - 1.31
+++ GenericValidator.java 8 Jun 2004 15:22:29 - 1.32
@@ -268,5 +268,87 @@
public static boolean minLength(String value, int min) {
return (value.length() = min);
}
+
+// See http://issues.apache.org/bugzilla/show_bug.cgi?id=29015
WRT the value methods
+
+/**
+ * pChecks if the value is greater than or equal to the
min./p
+ *
+ * @param value The value validation is being performed on.
+ * @param min The minimum numeric value.
+ */
+public static boolean minValue(int value, int min) {
+return (value = min);
+}
+
+/**
+ * pChecks if the value is greater than or equal to the
min./p
+ *
+ * @param value The value validation is being performed on.
+ * @param min The minimum numeric value.
+ */
+public static boolean minValue(long value, long min) {
+return (value = min);
+}
+
+/**
+ * pChecks if the value is greater than or equal to the
min./p
+ *
+ * @param value The value validation is being performed on.
+ * @param min The minimum numeric value.
+ */
+public static boolean minValue(double value, double min) {
+return (value = min);
+}
+
+/**
+ * pChecks if the value is greater than or equal to the
min./p
+ *
+ * @param value The value validation is being performed on.
+ * @param min The minimum numeric value.
+ */
+public static boolean minValue(float value, float min) {
+return (value = min);
+}
+
+/**
+ * pChecks if the value is less than or equal to the max./p
+ *
+ * @param value The value validation is being performed on.
+ * @param max The maximum numeric value.
+ */
+public static boolean maxValue(int value, int max) {
+return (value = max);
+}
+
+/**
+ * pChecks if the value is less than or equal to the max./p
+ *
+ * @param value The value validation is being performed on.
+ * @param max The maximum numeric value.
+ */
+public static boolean maxValue(long value, long max) {
+return (value = max);
+}
+
+/**
+ * pChecks if the value is less than or equal to the max./p
+ *
+ * @param value The value validation is being performed on.
+ * @param max The maximum numeric value.
+ */
+public static boolean maxValue(double value, double max) {
+return (value = max);
+}
+
+/**
+ * pChecks if the value is less than or equal to the max./p
+ *
+ * @param value The value validation is being performed on.
+ * @param max The maximum numeric value.
+ */
+public static boolean maxValue(float value, float max) {
+return (value = max);
+}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/validator project.xml
:-) Thanks for getting validator moving again! I've been absolutely swamped lately. David --- [EMAIL PROTECTED] wrote: husted 2004/06/08 08:12:12 Modified:validator project.xml Log: Add Ted Husted to list of developers [before David yells at me again :)] Revision ChangesPath 1.47 +8 -2 jakarta-commons/validator/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/validator/project.xml,v retrieving revision 1.46 retrieving revision 1.47 diff -u -r1.46 -r1.47 --- project.xml 8 Jun 2004 15:05:38 - 1.46 +++ project.xml 8 Jun 2004 15:12:12 - 1.47 @@ -1,4 +1,4 @@ -?xml version=1.0 encoding=UTF-8? +?xml version=1.0 encoding=UTF-8? !-- Copyright 2003-2004 The Apache Software Foundation @@ -87,6 +87,12 @@ organization/organization /developer developer + nameTed Husted/name + idhusted/id + email[EMAIL PROTECTED]/email + organization/organization +/developer +developer nameRob Leland/name idrleland/id emailrleland at apache.org/email @@ -110,7 +116,7 @@ email[EMAIL PROTECTED]/email organization/organization /developer - /developers + /developers contributors contributor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/validator/src/test/org/apache/commons/validator validator-bsf.xml
--- Ted Husted [EMAIL PROTECTED] wrote: Well, it could also be argued that one of the benefits of using Maven is that it's easier to setup additional distributions. :) There is something to be said for the idea of having a core distribution with a minimum number of dependencies, and an optional distribution with additional dependencies for things like a BSF and JXPath validator. I really thought this is what we discussed and agreed upon a couple of weeks ago so I'm still +1 on the idea :-). I think the new validators are useful but shouldn't impact the core framework's dependencies. Let me see if I can get a 1.1.3 core release out, and then we could see about a companion 1.13 opt release. -Ted. On Tue, 08 Jun 2004 12:13:22 -0400, Don Brown wrote: Just curious, why are we against adding code that has additional dependencies only if you actually use it? In general, it seems these things have a way of creeping into other areas of the code so you end up with the dependency growing. Just look at how Validator uses one class out of the entire Commons Collections dependency. That particular dependency is inherited from BeanUtils but Validator ended up using it just because it was there. Now we're having a difficult time separating from collections. David For example, while someone building validator needs BSF to build the code, the validator release doesn't need to include the BSF jar as it isn't required for normal operation. The only time it would be required is if the user tried to use the BSF validator. I would have thought one of the benefits of Maven is you can be more liberal with your build-time dependencies. Don Ted Husted wrote: Something like a contrib folder is fine as a whiteboard. But it not a practical way to distribute useful code. Unless the contrib folder is released, the vast majority of teams cannot use it. We'd really need a second Commons Validator distribution, dependant on the first. I'll reverse the patches, but that's going to consume the time I had set aside to complete the release. I'm away most of next week, so it looks like we may be stalled for another fortnight :( -Ted. On Tue, 08 Jun 2004 08:45:27 -0700 (PDT), David Graham wrote: I thought we agreed to add BSF and JXPath validators to a contrib directory so we wouldn't bloat the dependencies needed to distribute the core validator? I'm -1 on adding dependencies in the core distro. David --- [EMAIL PROTECTED] wrote: husted 2004/06/08 07:53:12 Added: validator/src/test/org/apache/commons/validator validator-bsf.xml Log: Apply #29205 Add BSFValidator, submitted by Don Brown. Revision ChangesPath 1.1 jakarta- commons/validator/src/test/org/apache/commons/validator/validator- bsf .xml Index: validator-bsf.xml === ! DOCTYPE form-validation PUBLIC -//Apache Software Foundation//DTD Commons Validator Rules Configuration 1.1//EN http://jakarta.apache.org/commons/dtds/validator_1_1.dtd; form-validation global validator name=bsf classname=org.apache.commons.validator.BSFValidator method=isValid methodParams=java.lang.Object,org.apache.commons.validator.Field msg =/ /global formset form name=bsfForm field property=value depends=bsf var var-nameeval/var- name var-valuevalue.equals(foo)/var-value /var /field /form form name=bsfForm-numeric field property=value depends=bsf var var-nameeval/var- name var-valueInteger.parseInt(value)0 amp;amp; Integer.parseInt(value)lt;100/var-value /var /field /form form name=bsfForm-nested field property=object depends=bsf var var-nameeval/var-name var-valuevalue.value.equals(foo)/var-value /var /field /form /formset /form-validation -- --- To unsubscribe, e-mail: commons-dev- [EMAIL PROTECTED] For additional commands, e- mail: [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- --- To unsubscribe, e-mail: commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: commons-dev- [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: [Validator] 1.1.3 release plan
If I recall correctly, there's a 1_1_2 branch that 1.1.3 should be released from. HEAD was for 1.2.0 development and has had some deprecated items removed. Sorry if you already knew this, I just didn't want the release cut from the wrong branch. David --- Ted Husted [EMAIL PROTECTED] wrote: We seem fine as far as the tickets and docs go. I need to test signing a distribution before tagging CVS for Commons Validator 1.1.3. I can give this a try on Thursday. -Ted. __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Ted Husted as Committer
--- Robert Leland [EMAIL PROTECTED] wrote: +1 To Ted. David Graham wrote: --- robert burrell donkin [EMAIL PROTECTED] wrote: +1 but please don't roll a release before the upcoming beanutils dependency hell fix is released. this will allow the problematic validator dependency on commons collections to be removed by upgrading to the next beanutils release. Actually, the removal of collections classes from validator will take a bit longer. Why is it that we want to remove FastHashMap ? is there a performance penalty ? Its javadoc states that it's not cross platform. I have absolutely no interest in using Java code that doesn't run on all platforms. Also, that's our only usage of Commons Collections code so we can drop that bulky dependency. David Rob We still have protected FastHashMap variables that need to be replaced with Maps. David __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Ted Husted as Committer
I thought you were already a Commons committer so I invited you to add yourself to the project.xml file a while back. Regardless, here's my +1 :-). David --- Ted Husted [EMAIL PROTECTED] wrote: The few remaining issues against Validator seem to have fixes and patches that I could apply. I'd like to resolve these issues and then roll the 1.3.1 release. Accordingly, I'd like to nominate myself as a Validator Committer. Here's my +1 for me :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Ted Husted as Committer
--- robert burrell donkin [EMAIL PROTECTED] wrote: +1 but please don't roll a release before the upcoming beanutils dependency hell fix is released. this will allow the problematic validator dependency on commons collections to be removed by upgrading to the next beanutils release. Actually, the removal of collections classes from validator will take a bit longer. We still have protected FastHashMap variables that need to be replaced with Maps. David - robert On 6 Jun 2004, at 13:39, Ted Husted wrote: The few remaining issues against Validator seem to have fixes and patches that I could apply. I'd like to resolve these issues and then roll the 1.3.1 release. Accordingly, I'd like to nominate myself as a Validator Committer. Here's my +1 for me :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Validator] Field class
I think this has been brought up before but nothing came of it. Feel free to open a bugzilla enhancement ticket with patches and we'll apply them. Thanks, David --- Rich Wertz [EMAIL PROTECTED] wrote: Recent validator DTDs indicate that each field element may have any number of child msg elements with optional attributes bundle and resource and required attributes key and name. Why then does the Field class not provide any accessor methods for retrieving Msg objects that have been associated with a particular field? The current getMsg() implementation returns only a String, even though an addMsg(Msg) method is provided. Shouldn't messages be handled by the Field class in a manner more consistent with its handling of Args? The primary use case needs driving these questions are 1) to be able to extract key, name, bundle, and resource y/n information for a particular message belonging to a field and, 2) to retrieve multiple messages from a particular field. I believe that this functionality would be particularly useful in situations where the validator is used as a standalone validation framework by applications, since it allows for more flexibility when analyzing ValidatorResult instances. Thanks! Rich -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Sunday, June 06, 2004 7:39 AM To: Jakarta Commons Developers List Subject: [Validator] Ted Husted as Committer The few remaining issues against Validator seem to have fixes and patches that I could apply. I'd like to resolve these issues and then roll the 1.3.1 release. Accordingly, I'd like to nominate myself as a Validator Committer. Here's my +1 for me :) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
