Parent Directory
| 
Revision Log
| Links to HEAD: | (view) (annotate) |
| Sticky Revision: |
Roll version number to 1.8.3-SNAPSHOT after 1.8.2 release
Update version number from 1.8.2-SNAPSHOT to 1.8.2
Roll version number to 1.8.2-SNAPSHOT after 1.8.1 release
Prepare for the BeanUtils 1.8.1 release
Roll version number to 1.9.0-SNAPSHOT following the 1.8.0 release
Update copyright year
Fix svn properties only (eol-style, keywords etc)
TLP related blanket changes: s:jakarta.apache.org/commons:commons.apache.org: s/commons-user@jakarta.apache.org/user@commons.apache.org/ s/commons-dev@jakarta.apache.org/dev@commons.apache.org/ s/Jakarta Commons/Apache Commons/ s:svn.apache.org/viewcvs/jakarta/commons:svn.apache.org/viewvc/commons: s:svn.apache.org/viewcvs.cgi/jakarta/commons:svn.apache.org/viewvc/commons: s:svn.apache.org/viewvc/jakarta/commons:svn.apache.org/viewvc/commons: s:svn.apache.org/repos/asf/jakarta/commons:svn.apache.org/repos/asf/commons: I'd appreciate another pair of eyes on this. There are some categories we probably don't want to change ATM (hopefully, none of these snuck in): * Historicals (proposals etc.) * URLs that shouldn't change (DOCTYPE fragments etc.) * Test cases where namespace URLs matter etc. (I'll track any related nightly failures)
Moving to TLP
Moving back :)
Moving to TLP
Fix ant build (conf directory has been zapped)
BEANUTILS-290 - add ant script to re-create the "core" and "bean-collections" jars
Minor changes to ant build
BEANUTILS-290 - Merge Bean-Collections back into core BeanUtils and remove Bean-Collections sub-project
Fixing the build to include all the tests as per BEANUTILS-287. Also fixing the build.properties.sample so it's easier to use for the default maven user (ie: it looks by default in the .maven repository)
BEANUTILS-233 Implement equals() and hashCode() methods for DynaProperty - thanks to Russell for the patch and test case!
BEANUTILS-185 Provide a Map decorator for a DynaBean (enables DynaBean to be used with other teechnologies such as JSTL)
junit.home, commons-logging.home and commons-collections.home are only used to define the directories of the jar files; which are then defined as separate variables. Seems pointless, so removing them. Also removing the junit.jar declaration from build.xml, seems pointless given that it's in build.properties.sample.
bump version number to 1.8.0-SNAPSHOT
Moved copyright out of source files and into NOTICE.txt
add LazyDynaList - based on suggestion from Vic Cekvenich
Bug 36445 Replace copied code and add mapped property tests - reported by Sam Ruby
svn:keywords correction
Add Indexed Property Test Case
Updated site to reflect new release
Merged in changes from the release
Add new LazyDynaMap Test Case to the ant build script
Add the Test Cases for LazyDynaClass and LazyDynaBean to the ant build file
Moved classes depending on commons-collections into separate directory with separate build.
Change to Apache License 2.0
Bean property functor implementation tests. Also documentation improvements. Submitted by Norm Deane
An initial suite of microbenchmarks for: * BeanUtils.copyProperties() * BeanUtils.populate() * PropertyUtils.copyProperties()
Changed from singletons backing Utility classes to pseudo-singletons (per thread context classloader). This should isolated the use of BeanUtils between web apps. Also added a test case. Note that for some 1.3 JVMs, WeakHashMap has a bug which results in a memory leak. Since commons-logging has the same vunerability and this results in the beanutils classes remaining in memory after they should have been released, I decided to go with the standard class rather than use the collections replacement which does not have this bug.
Rolled back last commit. Accidentally committed everything in commons when I just wanted to commit docs and xdocs. Doh!
Changed charter as per successful VOTE. We now allow any Apache committers to use the sandbox (upon request).
Added conversion of int[] to StringArrayConverter. This helps with a common html forms use case. Enhancement filed as bug #18297. Patch submitted by Dan Allen.
This patch contain numerous improvements to locale convert utils. These include more graceful handling of nulls and more precise numeric classes returned from numeric convertions. Submitted by Michael Szlapa.
Release 1.6.1 finished
Preparations for 1.6.1 release
Preparations for 1.6.1 release
Preparations for beanutils 1.6.1 release
Updated the version number in the build files to 1.7-dev.
Corrected year
Preparation for beanutils 1.6 release
Fix for bug#15888. A lenient property was added to DateLocaleConverter that allows the lenient property to be set on the DateFormat used to parse the convertion. Also added a test case.
Copy the local "LICENSE.txt" file instead of the parent "../LICENSE" file. Submitted by: David Morris <David.Morris at plumcreek.com>
RowSetDynaClass is a way to represent the results of an SQL "SELECT" statement as a "disconnected row set" (in JDBC terminology). Its function is to copy the results of a query (represented as a JDBC ResultSet or RowSet object that is passed to its constructor) into an in-memory List of the matching rows. Once the RowSetDynaClass instance has been created, the ResultSet/RowSet instance (and its corresponding Statement and Connection) can be closed and/or returned to the connection pool (if any). In this way, RowSetDynaClass differs from ResultSetDynaClass, where the DynaBean "instances" returned by the Iterator are really just a proxy for the values represented in the current row of the ResultSet. The typical usage pattern for RowSetDynaClass is in the class comments of the Javadoc. RowSetDynaClass instances will be Serializable, as long as all of the column values are, which makes it a very convenient mechanism for transmitting result sets to a remote Java-based client (such as an applet or a web services client).
rev the version
1.5 release
Added test case for BeanComparator. Submitted by Eric Pugh.
1.4.1 release prep
updated build number to new release
Preparations for the 1.4 release.
Initial checkin of a way to wrap DynaBean APIs around the rows in a java.sql.ResultSet, along with associated test cases and docco updates. FIXME - does not support indexed or mapped propeties.
Set version number back to development.
Update version number for release.
Include an overview file in the Javadocs since there is now more than one Java package.
Inspired by previous discussions on generalizing ConvertUtils, this patch makes the standard Converters used (for all the primitive types) completely pluggable, so there is no longer any concept of "custom converters". Now, you can replace how String->int conversions (for example) are done in your application. Besides the types previously supported by ConvertUtils (all of the Java primitive types and their wrappers), ConvertUtils also includes standard Converter implementations for the following Java classes: - java.math.BigDecimal - java.math.BigInteger - java.sql.Date - java.sql.Time - java.sql Timestamp that, in their default versions, simply use the default print format described in the JDK JavaDocs. One customization you might want to make is to have the standard Converters throw ConversionException instead of returning a default value (which is the standard behavior for backwards compatibility). To accomplish this, the standard converter implementations for primitives support two constructors -- one that takes a default value, and one that doesn't (and therefore will return an exception on conversion errors). So, if you wanted to switch to exceptions for integer conversion errors, you would say: ConvertUtils.register(new IntegerConverter(), Integer.TYPE); ConvertUtils.register(new IntegerConverter(), Integer.class); to cover both the wrapper class and the primitive type.
BeanUtils now uses logging. Added to build.xml, removed any System.out.println(), made some exception messages more informative.
Update copyright dates.
Add "jar" and "install-jar" targets that support copying the JAR file
to ${lib.repo}.
Submitted by: Jon Stevens <jon@latchkey.com>
Add an implementation of DynaBean that wraps existing standard JavaBeans
with the DynaBean APIs. Add test cases to make sure that all the tests
passed by BasicDynaBean also pass, except for the contains() and remove()
method tests -- these methods are not currently supported by the
WrapDynaBean implementation.
Canonical usage pattern:
MyAddressClass myBean = ...;
WrapDynaBean dynaBean = new WrapDynaBean(myBean);
String name = (String) dynaBean.get("name");
dynaBean.put("country", "US");
Add unit tests for accessing DynaBeans through BeanUtils as well as through PropertyUtils.
Initial integration of transparent DynaBean support into PropertyUtils (with an appropriate JUnit test case). At the moment, there has been no attempt to integrate PropertyDescriptor support. Therefore, the following PropertyUtils methods will misbehave on DynaBeans: describe(), getMappedProeprtyDescriptors(), getPropertyDescriptor(), getPropertyDescriptors(), getPropertyEditorClass(), getReadMethod(), getWriteMethod(). However, all the basic property getting and setting stuff works correctly, and this is by far the majority use case.
Add unit tests for BasicDynaBean (and BasicDynaClass), as well as fixing a few small implementation bugs.
Conform to the recently agreed (on GENERAL@JAKARTA.APACHE.ORG) convention of including the Apache License inside the JAR file, at META-INF/LICENSE.txt as well as externally in the distribution directory. This will ensure that the license is included, even when we eventually have a CJAN/JJAR type mechanism to download just the JAR files you need, instead of binary distributions.
Update version number to 1.3-dev for next round of development.
Prepare for 1.2 release to provide a stable base for enhancements (especially dynamic beans and enhanced converters). Add release notes to document the (very few) changes since 1.1.
added commons-collection jar in classpath of javadoc task to prevent warnings and better javadoc generation
Extract the private methods used to find accessible method in PropertyUtils into a new MethodUtils class, making them public for general purpose use. Also add a corresponding JUnit test case. Submitted by: Robert Burrell Donkin <robertdonkin@mac.com>
Update version number for next round of development.
Tweak version number for 1.1 release, and clean up Javadocs a bit.
Back to version 1.1-dev.
Re-build 1.0 to fix a snafu in the MANIFEST.MF file.
Update version numbers for development subsequent to 1.0 releases.
Update documentation and build scripts in preparation for verison 1.0 release.
Update the MANIFEST.MF file we generate (for beanutils) to declare the dependency on the collections classes in a manner that can be verified by applications that support the JDK's Optional Package Versioning specification (such as Tomcat 4.0 and other servlet containers implementing the 2.3 specification). For more info, see: http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html In order to support these conventions, the recommended "name" of the extension is the fully qualified package name of the base package implemented by this extension. Therefore, the generated name is now "org.apache.commons.beanutils" instead of "beanutils". I will adjust the other build scripts as necessary to reflect this convention.
Update to new distribution conventions: * "build" --> "dist". * Include LICENSE file (no README yet for this package) * Include Javadocs under "dist/docs/api". * Do not include source in the binary distribution.
Conform to majority convention on the name of the Ant properties file in the user's home directory.
Go with the flow some more (conf --> src/conf).
Moved location of properties file to reflect lack of build directory Added BeanUtils test case. PR: Obtained from: Submitted by: Reviewed by:
Since nobody is paying attention to the existing practice OR to my proposal,
give up and go with the flow.
Can we at least agree to do ONE thing the same -- format the output of the
"ant dist" target (i.e. the "build" subdirectory) as follows?
jakarta-commons/
component/
build/
commons-${component}.jar Binary JAR file
doc/ HTML docs (if any)
javadoc/ Javadocs
src/ Copy of source code
Consistency will become much more important as CJAN emerges.
Conform to majority practice on the location of build.xml and build.properties.sample. I don't care all that much, as long as it's not different for every Commons component.
This form allows you to request diffs between any two revisions of this file. For each of the two "sides" of the diff, enter a numeric revision.
| apache@apache.org | ViewVC Help |
| Powered by ViewVC 1.1.2 |