[jira] Reopened: (FILEUPLOAD-141) Remove FileItems if FileUploadBase.parseRequest() fails
[ https://issues.apache.org/jira/browse/FILEUPLOAD-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened FILEUPLOAD-141: -- (Reopening as closed issues with ongoing conversations are too easy to lose track of) Remove FileItems if FileUploadBase.parseRequest() fails --- Key: FILEUPLOAD-141 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-141 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Environment: commons-fileupload is used for parsing multipart/form-data POST requests in servlets. OS: Linux Reporter: Marcus Klein If the method FileUploadBase.parseRequest() throws a FileUploadException, the already parsed FileItem objects are not accessible and removed by the garbage collector. Now expect a fileupload that fills the servers hard disc with FileItems until no space is left on the device. The method parseRequest() throws a FileUploadException and there are several FileItem objects that still exist in the device because the garbage collector does not run and removes them. This causes failing fileuploads until the garbage collector runs and removes the lost FileItem objects. I suggest calling FileItem.delete() on all FileItem objects created in the method FileUploadBase.parseRequest() if the method is left with a FileUploadException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (FILEUPLOAD-140) Means to preserve text parameters when upload limit exceeded
[ https://issues.apache.org/jira/browse/FILEUPLOAD-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened FILEUPLOAD-140: -- Reopening as there's a post-close comment on there. Means to preserve text parameters when upload limit exceeded Key: FILEUPLOAD-140 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-140 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Reporter: Paul Benedict Assignee: Jochen Wiedmann I am trying to resolve https://issues.apache.org/struts/browse/STR-2585 but am lacking the means to do it. The current use is with the deprecated DiskFileUpload and I prefer to have this class fixed first. When SizeLimitExceededException is thrown, it does not return the items it has collected thus far. I see two possible solutions which involve adding a property on the exception to return them: (1) Return the parameters thus gathered or (2) finish out the input stream but throw away all file items and return only the text parameters. Otherwise, whenever a the upload exceeds its limit, all other input parameters disappear. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-53) 'not supported' error given against Firebird DB
[ https://issues.apache.org/jira/browse/DBCP-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated DBCP-53: -- Summary: 'not supported' error given against Firebird DB (was: [dbcp] commons dbcp does not supports Firebird DB.) 'not supported' error given against Firebird DB --- Key: DBCP-53 URL: https://issues.apache.org/jira/browse/DBCP-53 Project: Commons Dbcp Issue Type: Bug Environment: Operating System: Windows XP Platform: PC Reporter: DMoL Fix For: 1.3 I'm trying to use Torque-3.2 with open-source Firebird DBMS, but simple example not works. Here is the log output: 15.03.2006 21:47:38 org.apache.torque.dsfactory.AbstractDataSourceFactory setProperty SEVERE: Property: driver value: org.firebirdsql.jdbc.FBDriver is not supported by DataSource: org.apache.commons.dbcp.cpdsadapter.DriverAdapterCPDS -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-115) Digester depends on BeanUtils copies of Collections classes
[ https://issues.apache.org/jira/browse/DIGESTER-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513723 ] Henri Yandell commented on DIGESTER-115: Note, it only directly depends on ArrayStack. Buffer and BufferUnderflowException are depended on via ArrayStack. A tighter ArrayStack could definitely be made (remove the unnecessary bits) and used within Digester. Digester depends on BeanUtils copies of Collections classes --- Key: DIGESTER-115 URL: https://issues.apache.org/jira/browse/DIGESTER-115 Project: Commons Digester Issue Type: Bug Affects Versions: 1.8 Reporter: Niall Pemberton Fix For: 1.8.1 This is related to issue# BEANUTILS-278 Digester uses 3 classes (ArrayStack, Buffer and BufferUnderflowException) from commons BeanUtils which were copied from Commons Collections and BEANUTILS-278 proposes removing them. ArrayStack.java Buffer.java BufferUnderflowException.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DIGESTER-115) Digester depends on BeanUtils copies of Collections classes
[ https://issues.apache.org/jira/browse/DIGESTER-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated DIGESTER-115: --- Fix Version/s: 1.8.1 Digester depends on BeanUtils copies of Collections classes --- Key: DIGESTER-115 URL: https://issues.apache.org/jira/browse/DIGESTER-115 Project: Commons Digester Issue Type: Bug Affects Versions: 1.8 Reporter: Niall Pemberton Fix For: 1.8.1 This is related to issue# BEANUTILS-278 Digester uses 3 classes (ArrayStack, Buffer and BufferUnderflowException) from commons BeanUtils which were copied from Commons Collections and BEANUTILS-278 proposes removing them. ArrayStack.java Buffer.java BufferUnderflowException.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DIGESTER-114) SetPropertyRule throws /java.lang.IllegalArgumentException: No name specified/ when matched element has no attributes
[
https://issues.apache.org/jira/browse/DIGESTER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated DIGESTER-114:
---
Fix Version/s: 1.8.1
SetPropertyRule throws /java.lang.IllegalArgumentException: No name
specified/ when matched element has no attributes
-
Key: DIGESTER-114
URL: https://issues.apache.org/jira/browse/DIGESTER-114
Project: Commons Digester
Issue Type: Bug
Affects Versions: 1.8
Reporter: Britt Levy
Fix For: 1.8.1
A /java.lang.IllegalArgumentException: No name specified/ is thrown from the
SetPropertyRule.begin(Attributes attributes) method if the attributes list is
empty (attributes.getLength() = 0). The method should check the length of the
attributes list and simply return if there are no attributes.
Add the follwowing to org.apache.commons.digester.SetPropertyRuleTestCase to
reproduce:
/**
* Simple test xml document used in the tests.
*/
protected final static String TEST_XML_3 =
?xml version='1.0'?root +
set/ +
/root;
/**
* Test SetPropertyRule when matched XML element has no attributes.
*/
public void testElementWithNoAttributes() throws Exception {
// Set up the rules we need
digester.addObjectCreate(root,
org.apache.commons.digester.SimpleTestBean);
digester.addSetProperty(root/set, name, value);
// Parse the input - should not throw an exception
SimpleTestBean bean =
(SimpleTestBean) digester.parse(xmlTestReader(TEST_XML_3));
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DIGESTER-109) FromXmlRuleSet and SetNextRule classloader issue
[ https://issues.apache.org/jira/browse/DIGESTER-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed DIGESTER-109. -- Resolution: Won't Fix Closing as WONTFIX, as with the validator issue this links to. The workaround is to call Digester.setUseContextClassLoader(true). FromXmlRuleSet and SetNextRule classloader issue --- Key: DIGESTER-109 URL: https://issues.apache.org/jira/browse/DIGESTER-109 Project: Commons Digester Issue Type: Bug Reporter: Anna Komaristaia When I start the application in Unix, there are 2 classes cause the problem: 1) The NullPointerException in FromXmlRuleSet class in the method addRuleInstances(Digester, String); 2) The NullPointerException in SetNextRule class in the method end(); Temporary solution --- I recompiled the commons-digester jar with the next changes and it's working fine in PC and Unix: Changes in the FromXmlRuleSet class 1) public static final String DIGESTER_DTD_PATH = digester-rules.dtd; 2) in the method addRuleInstances the line URL dtdURL = getClass().getClassLoader().getResource(DIGESTER_DTD_PATH); changed by URL dtdURL = this.getClass().getResource(DIGESTER_DTD_PATH); Changes In the SetNextRule class the line paramTypes[0] = digester.getClassLoader().loadClass( paramType); changed by if( digester.getClassLoader() == null ) paramTypes[0] = Class.forName(paramType); else paramTypes[0] = digester.getClassLoader().loadClass( paramType); Thanks, //Anna -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DIGESTER-89) [digester] [PATCH] add jar target to build.xml
[ https://issues.apache.org/jira/browse/DIGESTER-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed DIGESTER-89. - Resolution: Fixed Fix Version/s: 1.8.1 svn ci -m Applying Petteri Räty's build.xml improvement from DIGESTER-89 so you can build the jar without the javadoc. I did modify it so you are forced to run the tests when building the jar build.xml Sendingbuild.xml Transmitting file data . Committed revision 557404. Thanks Petteri. [digester] [PATCH] add jar target to build.xml -- Key: DIGESTER-89 URL: https://issues.apache.org/jira/browse/DIGESTER-89 Project: Commons Digester Issue Type: Improvement Environment: Operating System: All Platform: Other Reporter: Petteri Räty Priority: Minor Fix For: 1.8.1 Attachments: 1.7-build.xml-jar-target.patch Now to create the commons-digester.jar file one must also create javadocs. Here is a patch that add a jar target so I don't need to run javadoc to create the jar file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DIGESTER-117) Missing unit tests using ant and maven
[ https://issues.apache.org/jira/browse/DIGESTER-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed DIGESTER-117. -- Resolution: Fixed Fix Version/s: 1.8.1 Emulating the changes in DBCP/Beanutils (I think it was those two); I've opted to update the build.xml and not to use 'maven ant'. I've also rewritten the build.properties.sample, using dbcp's as an example, so that running 'maven jar' puts the various required jar files into the location expected by the sample. Missing unit tests using ant and maven -- Key: DIGESTER-117 URL: https://issues.apache.org/jira/browse/DIGESTER-117 Project: Commons Digester Issue Type: Bug Affects Versions: 1.8 Reporter: Gail Badner Fix For: 1.8.1 Currently, 136 unit tests are run using maven and 149 unit tests are run using ant. The maven build uses the file patterns: **/*Test.java **/*TestCase.java which misses the following tests: **/plugins/TestAll.java **/TestFactoryCreate.java After the missing tests are added to the maven build, 157 tests are executed. The ant build does not execute the following tests: LocationTrackerTestCase NamespaceSnapshotTestCase OverlappingCallMethodRuleTestCase After the missing tests to the ant build, 157 tests are executed. I'm not sure how this should be fixed; should test cases that don't end in Test or TestCase be renamed? When this is fixed, it would be nice if the junit ant task were used to run the tests so that the JUnit report can be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DIGESTER-111) Null InputStream leads to MalformedURLExceptions under JDK 1.5
[ https://issues.apache.org/jira/browse/DIGESTER-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated DIGESTER-111: --- Fix Version/s: 1.8.1 Null InputStream leads to MalformedURLExceptions under JDK 1.5 -- Key: DIGESTER-111 URL: https://issues.apache.org/jira/browse/DIGESTER-111 Project: Commons Digester Issue Type: Improvement Affects Versions: 1.8 Reporter: Niall Pemberton Priority: Minor Fix For: 1.8.1 Passing a null InputStream to Digester.parse(InputStream) causes a confusing java.net.MalformedURLException under JDK 1.5 Would be more user friendly to trap this condition and throw an appropriate exception and message. This came up as an issue in Commons Validator - see VALIDATOR-226 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-349) Deadlock using ReflectionToStringBuilder
[ https://issues.apache.org/jira/browse/LANG-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-349: --- Fix Version/s: 2.3.1 First step - attempt a reproduction. If that fails, then dig into the code and see if it's obvious. Deadlock using ReflectionToStringBuilder Key: LANG-349 URL: https://issues.apache.org/jira/browse/LANG-349 Project: Commons Lang Issue Type: Bug Affects Versions: 2.0 Environment: java version 1.5.0_10 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode) uname -a Linux fwjsfimat04 2.4.21-32.EL #1 SMP Fri Apr 15 21:02:58 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux Reporter: David I. Priority: Critical Fix For: 2.3.1 I used the ReflectionToStringBuilder on an object to output debugging messages to Log4j. If this object was picked up by two different threads and the toString() method was called at the same time in two different threads, a deadlock occurrs. Here is a stack trace from using jstack: Thread 1172: (state = BLOCKED) - java.util.Vector.hashCode() @bci=0, line=938 (Interpreted frame) - java.util.HashMap.containsKey(java.lang.Object) @bci=6, line=377 (Compiled frame) - org.apache.commons.lang.builder.ReflectionToStringBuilder.toString() @bci=50, line=522 (Compiled frame) - org.apache.commons.lang.builder.ReflectionToStringBuilder.toString(java.lang.Object, org.apache.commons.lang.builder.ToStringStyle, boolean, java.lang.Class) @bci=12, line=265 (Interpreted frame) - org.apache.commons.lang.builder.ReflectionToStringBuilder.toString(java.lang.Object, org.apache.commons.lang.builder.ToStringStyle) @bci=4, line=197 (Interpreted frame) - org.apache.commons.lang.builder.ToStringBuilder.reflectionToString(java.lang.Object, org.apache.commons.lang.builder.ToStringStyle) @bci=2, line=170 (Interpreted frame) [...] Thread 1191: (state = BLOCKED) - java.util.Vector.hashCode() @bci=0, line=938 (Interpreted frame) - java.util.HashMap.containsKey(java.lang.Object) @bci=6, line=377 (Compiled frame) - org.apache.commons.lang.builder.ReflectionToStringBuilder.toString() @bci=50, line=522 (Compiled frame) [...] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DAEMON-101) Javadoc typo, says avfter should probably be after
[ https://issues.apache.org/jira/browse/DAEMON-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed DAEMON-101. Resolution: Fixed Thanks Tim, both have been fixed in SVN. Javadoc typo, says avfter should probably be after -- Key: DAEMON-101 URL: https://issues.apache.org/jira/browse/DAEMON-101 Project: Commons Daemon Issue Type: Improvement Environment: N/A, javadoc Reporter: Tim Mooney Priority: Trivial Javadoc for the Daemon interface method start uses the word avfter, should probably be after. The comment may also fail to close a code tag (which doesn't seem to be valid, anyway). Full comment: Start the operation of this Daemon instance. This method is to be invoked by the environment after the init() method has been successfully invoked and possibly the security level of the JVM has been dropped. Implementors of this method are free to start any number of threads, but need to return control avfter having done that to enable invocation of the stop()-method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-92) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException
[ https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513305 ] Henri Yandell commented on BEANUTILS-92: Unit test comments: * You don't need to catch the Throwable, just let the exception hit the JUnit framework. * Do we really need the main methods? * Do we really need the suite methods? * Do we need the overridden setup/teardown methods? * Do we need the constructor? [JUnit stopped needing this a long time back from memory] *grumbles as always about p / instead of br/* Fix comments: * It would be nice if the debug was more expressive - ie) Error writing to 'name' on class 'dest'. Otherwise, +1. PropertyUtilsBean.copyProperties does not catch NoSuchMethodException - Key: BEANUTILS-92 URL: https://issues.apache.org/jira/browse/BEANUTILS-92 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: other Platform: Other Reporter: Will Pugh Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: Beanutils-92-updated.patch, fixCopyPropertyException, Jira92TestCase.java I ran into a problem where I had a bean that had an IndexedSetter but no simple setter. This caused a NoSuchMethodException to get thrown in PropertyUtilsBean.copyProperties. This is inconsistant with BeanUtilsBean which catches this case and continues copying the other properties. When I asked about this in on the mailing list, the answer seemed to come back that this is probabaly incorrect behaviour, but it is possible people depend on this behaviour so this might be too big a change for a point release. I'm attaching the patch so it can be added to the next major release (if it is determined to be incorrect behaviour). The scenario I ran into this was one where I had a bean that I then used CGLib for enhancing. After that, the bean failed to be clonable by BeanUtils.clone. This could potentially become a big deal since Hibernate used CGLib for adding proxies to beans for lazy loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-92) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException
[ https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513317 ] Henri Yandell commented on BEANUTILS-92: I've committed a modified version of your patches as r557008, it felt easier than adding another attachment etc: http://svn.apache.org/viewvc?view=revrevision=557008 How does that look? PropertyUtilsBean.copyProperties does not catch NoSuchMethodException - Key: BEANUTILS-92 URL: https://issues.apache.org/jira/browse/BEANUTILS-92 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: other Platform: Other Reporter: Will Pugh Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: Beanutils-92-updated.patch, fixCopyPropertyException, Jira92TestCase.java I ran into a problem where I had a bean that had an IndexedSetter but no simple setter. This caused a NoSuchMethodException to get thrown in PropertyUtilsBean.copyProperties. This is inconsistant with BeanUtilsBean which catches this case and continues copying the other properties. When I asked about this in on the mailing list, the answer seemed to come back that this is probabaly incorrect behaviour, but it is possible people depend on this behaviour so this might be too big a change for a point release. I'm attaching the patch so it can be added to the next major release (if it is determined to be incorrect behaviour). The scenario I ran into this was one where I had a bean that I then used CGLib for enhancing. After that, the bean failed to be clonable by BeanUtils.clone. This could potentially become a big deal since Hibernate used CGLib for adding proxies to beans for lazy loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate
[ https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513318 ] Henri Yandell commented on BEANUTILS-35: You mentioned pushing this one out to 1.8.x on IM - I'm in favour of that. Indexed properties with Array type cause IllegalArgumentException in setProperty/populate - Key: BEANUTILS-35 URL: https://issues.apache.org/jira/browse/BEANUTILS-35 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Affects Versions: 1.7.0 Environment: Operating System: All Platform: All Reporter: David Wood Assignee: Niall Pemberton Fix For: 1.8.0 Attachments: ArrayIndexedProperty.patch, BEANUTILS-35-PropertyUtilsBean-getPropertyType.patch, beanutils-indexed-arrays.patch If you attempt: public String[] getIndexedArrayProperty(int index) public void setIndexedArrayProperty(int index,String newvalue[]) ...this will fail with an IllegalArgumentException in PropertyUtilsBean, because setProperty will decide to store the first element of the newvalue array rather than the whole array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-346) Dates.round() behaves incorrectly for minutes and seconds
[
https://issues.apache.org/jira/browse/LANG-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512691
]
Henri Yandell commented on LANG-346:
Digging into this - I can definitely reproduce the error with the test case you
include - many thanks for that.
Looking at the source code history, the error presumably came in during changes
to the modify(Calendar, int, boolean) method for LANG-59.
Dates.round() behaves incorrectly for minutes and seconds
-
Key: LANG-346
URL: https://issues.apache.org/jira/browse/LANG-346
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.2, 2.3
Reporter: Ken Dombeck
Fix For: 2.3.1
Get unexpected output for rounding by minutes or seconds.
public void testRound()
{
Calendar testCalendar = Calendar.getInstance(TimeZone.getTimeZone(GMT));
testCalendar.set(2007, 6, 2, 8, 9, 50);
Date date = testCalendar.getTime();
System.out.println(Before round() + date);
System.out.println(After round() + DateUtils.round(date,
Calendar.MINUTE));
}
--2.1 produces
Before round() Mon Jul 02 03:09:50 CDT 2007
After round() Mon Jul 02 03:10:00 CDT 2007 -- this is what I would expect
--2.2 and 2.3 produces
Before round() Mon Jul 02 03:09:50 CDT 2007
After round() Mon Jul 02 03:01:00 CDT 2007 -- this appears to be wrong
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-347) DateUtils' new addWeekdays feature
[
https://issues.apache.org/jira/browse/LANG-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-347:
---
Fix Version/s: (was: 2.3.1)
DateUtils' new addWeekdays feature
--
Key: LANG-347
URL: https://issues.apache.org/jira/browse/LANG-347
Project: Commons Lang
Issue Type: New Feature
Affects Versions: 2.3
Reporter: Vasily Ivanov
Fix For: 3.0
New method to add signed number of weekdays (skipping weekends):
/**
* Adds a number of weekdays (skipping weekends) to a date returning a new
Date object.
* The original date object is unchanged.
* p
* If the original Date itself is on a weekend, calculation will be started
from the
* next Monday morning (0:00:00.000) if an amount is positive or from the
last Friday night
* (23:59:59.999) otherwise.
*
* @param date the date, not null
* @param amount the amount to add, may be negative
* @return the new Date object with the amount added
*/
public static Date addWeekdays(Date date,
int amount)
{
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
Calendar c = Calendar.getInstance();
c.setTime(date);
if (amount != 0) {
if (isWeekend(c)) {
// see comments above
final boolean isSat = getDayOfWeek(c) == Calendar.SATURDAY;
int numToJump = 0;
if (amount 0) {
// this will jump date to the closest Monday
numToJump = isSat ? 2 : 1;
} else {
// this will jump date to the closest Saturday
numToJump = isSat ? 0 : -1;
}
c.add(Calendar.DAY_OF_MONTH, numToJump);
// this will jump to the start of the day (Monday or Saturday)
modify(c, Calendar.DAY_OF_MONTH, false);
if (amount 0) {
// this will go back to the end of prev Friday
c.add(Calendar.MILLISECOND, -1);
}
}
int count = 0;
final int absAmount = Math.abs(amount);
final int offset = amount 0 ? 1 : -1;
while (count absAmount) {
c.add(Calendar.DAY_OF_MONTH, offset);
if (!isWeekend(c)) {
count++;
}
}
}
return c.getTime();
}
public static int getDayOfWeek(Calendar c)
{
return c.get(Calendar.DAY_OF_WEEK);
}
public static boolean isWeekend(Calendar c)
{
final int dayOfWeek = getDayOfWeek(c);
return dayOfWeek == Calendar.SATURDAY || dayOfWeek == Calendar.SUNDAY;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LANG-343) Validate: Throw NullArgumentException
[ https://issues.apache.org/jira/browse/LANG-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-343. -- Resolution: Won't Fix Fix Version/s: (was: 2.3.1) Validate: Throw NullArgumentException - Key: LANG-343 URL: https://issues.apache.org/jira/browse/LANG-343 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.3 Reporter: Paul Benedict Validate methods should throw NullArgumentException on detecting null, not just IllegalArgumentException (its superclass) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (LANG-52) [lang] Validate.notNull should throw NullArgumentException
[ https://issues.apache.org/jira/browse/LANG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened LANG-52: --- Reopening this issue for 3.0 - backwards compatible changes might be acceptable then. [lang] Validate.notNull should throw NullArgumentException -- Key: LANG-52 URL: https://issues.apache.org/jira/browse/LANG-52 Project: Commons Lang Issue Type: Bug Environment: Operating System: All Platform: All Reporter: Jörg Gottschling Priority: Trivial Fix For: 3.0 Attachments: LANG-52.patch Validate.notNull throws a IllegalArgumentException but should throw a NullArgumentException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-52) [lang] Validate.notNull should throw NullArgumentException
[ https://issues.apache.org/jira/browse/LANG-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-52: -- Fix Version/s: 3.0 [lang] Validate.notNull should throw NullArgumentException -- Key: LANG-52 URL: https://issues.apache.org/jira/browse/LANG-52 Project: Commons Lang Issue Type: Bug Environment: Operating System: All Platform: All Reporter: Jörg Gottschling Priority: Trivial Fix For: 3.0 Attachments: LANG-52.patch Validate.notNull throws a IllegalArgumentException but should throw a NullArgumentException -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-348) Add StringUtils.repeat with separator
[
https://issues.apache.org/jira/browse/LANG-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512515
]
Henri Yandell commented on LANG-348:
Logically it would be:
public static String repeat(String str, char separatorChar, int repeat) {
String[] array = new String[repeat];
Collections.fill(array, str);
return join(array, separatorChar);
}
And maybe an overload for String separatorChar.
The hack I would probably just use instead is:
StringUtils.repeat(str + separatorStr, repeat).removeEnd(separatorStr);
Add StringUtils.repeat with separator
-
Key: LANG-348
URL: https://issues.apache.org/jira/browse/LANG-348
Project: Commons Lang
Issue Type: New Feature
Reporter: Kees van Dieren
Priority: Minor
I would like to have a repeat method with the ability to set a separator:
public static String repeat(String str, char separatorChar, int repeat)
Usage scenario: generate insert statements for JDBC preparedstatements:
assertEquals(?,?,?,?, StringUtils.repeat(?, ',', 4));
Can this be added to commons-lang?
Thanks!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-142) [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver
[
https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512666
]
Henri Yandell commented on BEANUTILS-142:
-
Definitely two issues.
On your fix; it turns out that I was running the new code, but it was not
executing it. I didn't have commons-logging in the classpath, and the
catch(Throwable t) { } was hiding that. Is there any reason for that try/catch?
Can we remove it?
On 1)
This is a tricky one. Oracle's DATE type can contain both date and time parts.
Its TIMESTAMP type lets you get down to milliseconds (and to smaller units than
JDBC types usually handle). So DATE - java.sql.Timestamp is completely correct
from a mapping point of view. I think there's nothing more to do here - people
have to know about the database they're dealing with to use DynaBeans.
2) Obvious solutions to this are:
i) Fix JDBC driver. Could start another project to make a 'fix the stinking
oracle jdbc driver via a wrapper'. Have always had an urge to do that :)
ii) Convert the oracle.sql.TIMESTAMP to a java.sql.Timestamp. The problem here
is that this means a) changing JDBCDynaClass so that createDynaProperty
silently converts oracle.sql.TIMESTAMP to java.sql.Timestamp; and secondly,
that we then have a converter in place to do oracle.sql.TIMESTAMP to
java.sql.Timestamp. The problem with that last step is that our converter is
Class based and not String based. Still *playing with that idea*
[beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle
10g JDBC driver
--
Key: BEANUTILS-142
URL: https://issues.apache.org/jira/browse/BEANUTILS-142
Project: Commons BeanUtils
Issue Type: Bug
Components: DynaBean
Environment: Operating System: Windows XP
Platform: All
Reporter: Li Zhang
Assignee: Henri Yandell
Fix For: 1.8.0
Attachments: beanutils-142-oracle-bug.patch, Beanutils-142.patch,
Play.java
Beginning in Oracle 9.2, DATE is mapped to Date and TIMESTAMP is mapped to
Timestamp. However if you were relying on DATE values to contain time
information, there is a problem. When using Oracle 10g JDBC driver, the
ResultSetMetaData.getColumnClassName returns java.sql.Timestamp but
ResultSet.getObject(name).getClass() returns java.sql.Date. Obviously these
two
do not match each other. When the RowSetDynaClass.copy function tries to set
the
value to BasicDynaBean, it throws exception. Need a workaround.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-142) [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver
[ https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512669 ] Henri Yandell commented on BEANUTILS-142: - As we dig into it at the same time :) So... 3) Use Niall's patch. This is a bit odd in that it means that the DATE column type will goto a java.sql.Date and lose the time part [which may be all that is there given that Oracle lacks a TIME type]. Their metadata getColumnClassName says java.sql.Timestamp, the getColumnType says java.sql.Types.DATE, and the getObject returns java.sql.Date. So I think that's 2 to 1 in favour of saying that in Oracle you lose such things. So I'm +1 to your patch Niall. It removes the try throwable bit, so that can be ignored from my previous comment. [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver -- Key: BEANUTILS-142 URL: https://issues.apache.org/jira/browse/BEANUTILS-142 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Environment: Operating System: Windows XP Platform: All Reporter: Li Zhang Assignee: Henri Yandell Fix For: 1.8.0 Attachments: beanutils-142-oracle-bug.patch, Beanutils-142.patch, Play.java Beginning in Oracle 9.2, DATE is mapped to Date and TIMESTAMP is mapped to Timestamp. However if you were relying on DATE values to contain time information, there is a problem. When using Oracle 10g JDBC driver, the ResultSetMetaData.getColumnClassName returns java.sql.Timestamp but ResultSet.getObject(name).getClass() returns java.sql.Date. Obviously these two do not match each other. When the RowSetDynaClass.copy function tries to set the value to BasicDynaBean, it throws exception. Need a workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DBCP-227) Some unit tests are run using maven, but not ant
[ https://issues.apache.org/jira/browse/DBCP-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed DBCP-227. -- Resolution: Fixed Fix Version/s: 1.3 svn ci -m Applying my patch from DBCP-227 - it's easy enough to run 'maven ant' if someone decides to do that someday, so no reason not to improve the existing build.xml in the meantime Sendingbuild.properties.sample Sendingbuild.xml Sendingsrc/test/org/apache/commons/dbcp/TestAll.java Sendingsrc/test/org/apache/commons/dbcp/TestJndi.java Transmitting file data Committed revision 555705. Some unit tests are run using maven, but not ant Key: DBCP-227 URL: https://issues.apache.org/jira/browse/DBCP-227 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Reporter: Gail Badner Fix For: 1.3 Attachments: DBCP-227.patch The following unit tests run using maven, but not ant: TestJOCLContentHandler TestPoolingDataSource TestJndi When this is fixed, it would be nice if the junit ant task were used to run the tests so that the JUnit report can be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-281) BeanUtils.cloneBean and Covariant (Overriding) return types
[
https://issues.apache.org/jira/browse/BEANUTILS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512268
]
Henri Yandell commented on BEANUTILS-281:
-
Just to follow up more on this issue, the type of which I've seen crop up in
Spring and Hibernate too:
http://opensource.atlassian.com/projects/spring/browse/SPR-2727
http://opensource.atlassian.com/projects/hibernate/browse/HHH-442
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2268
http://opensource.atlassian.com/projects/spring/browse/SPR-2968
The real bug is down in PropertyUtils.getPropertyDescriptors(Class). If you
evoke that on Car.class, it considers that the
AbstractVehicle.getField();Serializable class it the read method [wrong], and
that there is no write method [wrong]. Basically it gives the result you would
expect from evoking it on AbtractVehicle.class.
This is due to errors in the data returned from
Introspector.getBeanInfo(Car.class).getPropertyDescriptors().
The solution is most likely to write our own version of the Introspector's
getBeanInfo method:
http://java.sun.com/j2se/1.5.0/docs/api/java/beans/Introspector.html#getBeanInfo(java.lang.Class)
BeanUtils.cloneBean and Covariant (Overriding) return types
---
Key: BEANUTILS-281
URL: https://issues.apache.org/jira/browse/BEANUTILS-281
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Environment: JDK1.5
Reporter: Onur Kutlu GAGO
Fix For: LATER THAN 1.8.0
BeanUtils.cloneBean(Object) method does not copy the fields that are
overriden by the subclasses. For example, consider an abstract
class(AbstractVehicle) where you define an abstract getter for a field.
**
public abstract class AbstractVehicle {
public abstract Serializable getField();
}
***
In a class (Car) that extends this abstract class (AbstractVehicle) you
define the field itself and override the return type of the getter method
(from Serializable to Integer):
***
public class Car extends AbstractVehicle {
private Integer field = null;
@Override
public Integer getField() {
return field;
}
public void setField(Integer field) {
this.field = field;
}
}
***
When you clone such objects (Car) this field is not copied! The following
code prints 'null' instead of 5!
***
public class CopyTestMain {
public static void main(String[] args) throws IllegalAccessException,
InstantiationException, InvocationTargetException, NoSuchMethodException {
final Car aCar = new Car();
aCar.setField(5);
final Car copyCar = (Car) BeanUtils.cloneBean(aCar);
System.out.println(Field = + copyCar.getField());
}
}
***
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-281) BeanUtils.cloneBean and Covariant (Overriding) return types
[
https://issues.apache.org/jira/browse/BEANUTILS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512281
]
Henri Yandell commented on BEANUTILS-281:
-
Interestingly, the Harmony version of Introspector/BeanInfo [which means:
BeanInfoData.java, BeanInfoImpl.java, BeanInfoWrapper.java, Introspector.java]
work correctly.
So we could either view this as a WONTFIX because it's a bug that presumably
will be fixed in 1.7.0; or we could embed the classes above in BeanUtils.
I suspect this bug is too easy to workaround for us to pull in 4 classes from
Harmony. ie:
Change AbstractVehicle to:
public abstract class AbstractVehicle {
public abstract Serializable getField();
public abstract void setField(Serializable s);
}
and add the following method to Car so things compile:
public void setField(java.io.Serializable field) {
setField((Integer) field);
}
Thus I'll close this as WONTFIX.
BeanUtils.cloneBean and Covariant (Overriding) return types
---
Key: BEANUTILS-281
URL: https://issues.apache.org/jira/browse/BEANUTILS-281
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Environment: JDK1.5
Reporter: Onur Kutlu GAGO
Fix For: LATER THAN 1.8.0
BeanUtils.cloneBean(Object) method does not copy the fields that are
overriden by the subclasses. For example, consider an abstract
class(AbstractVehicle) where you define an abstract getter for a field.
**
public abstract class AbstractVehicle {
public abstract Serializable getField();
}
***
In a class (Car) that extends this abstract class (AbstractVehicle) you
define the field itself and override the return type of the getter method
(from Serializable to Integer):
***
public class Car extends AbstractVehicle {
private Integer field = null;
@Override
public Integer getField() {
return field;
}
public void setField(Integer field) {
this.field = field;
}
}
***
When you clone such objects (Car) this field is not copied! The following
code prints 'null' instead of 5!
***
public class CopyTestMain {
public static void main(String[] args) throws IllegalAccessException,
InstantiationException, InvocationTargetException, NoSuchMethodException {
final Car aCar = new Car();
aCar.setField(5);
final Car copyCar = (Car) BeanUtils.cloneBean(aCar);
System.out.println(Field = + copyCar.getField());
}
}
***
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (BEANUTILS-281) BeanUtils.cloneBean and Covariant (Overriding) return types
[
https://issues.apache.org/jira/browse/BEANUTILS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed BEANUTILS-281.
---
Resolution: Won't Fix
Marking as WONTFIX for the reasons above - please feel free to reopen if you
have further thoughts.
BeanUtils.cloneBean and Covariant (Overriding) return types
---
Key: BEANUTILS-281
URL: https://issues.apache.org/jira/browse/BEANUTILS-281
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Environment: JDK1.5
Reporter: Onur Kutlu GAGO
Fix For: LATER THAN 1.8.0
BeanUtils.cloneBean(Object) method does not copy the fields that are
overriden by the subclasses. For example, consider an abstract
class(AbstractVehicle) where you define an abstract getter for a field.
**
public abstract class AbstractVehicle {
public abstract Serializable getField();
}
***
In a class (Car) that extends this abstract class (AbstractVehicle) you
define the field itself and override the return type of the getter method
(from Serializable to Integer):
***
public class Car extends AbstractVehicle {
private Integer field = null;
@Override
public Integer getField() {
return field;
}
public void setField(Integer field) {
this.field = field;
}
}
***
When you clone such objects (Car) this field is not copied! The following
code prints 'null' instead of 5!
***
public class CopyTestMain {
public static void main(String[] args) throws IllegalAccessException,
InstantiationException, InvocationTargetException, NoSuchMethodException {
final Car aCar = new Car();
aCar.setField(5);
final Car copyCar = (Car) BeanUtils.cloneBean(aCar);
System.out.println(Field = + copyCar.getField());
}
}
***
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-142) [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver
[ https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated BEANUTILS-142: Attachment: Play.java Test case for this bug. It shows that there is a problem with DATE columns being loaded as originally said. I don't think an Exception is thrown for TIMESTAMP-oracle.sql.TIMESTAMP. Instead the user gets an oracle.sql.TIMESTAMP object instead of the expected java.sql.Timestamp. We should a) Fix the exception and b) Probably tidy up a bit so users don't get the oracle class. Here is the output: metadata - java.sql.Date? java.sql.Timestamp metadata - java.sql.Timestamp? oracle.sql.TIMESTAMP getDate - java.sql.Date? class java.sql.Date getObject - java.sql.Date? class java.sql.Date getTimestamp - java.sql.Timestamp? class java.sql.Timestamp getObject - java.sql.Timestamp? class oracle.sql.TIMESTAMP Exception in thread main org.apache.commons.beanutils.ConversionException: Cannot assign value of type 'java.sql.Date' to property 'test_date' of type 'java.sql.Timestamp' at org.apache.commons.beanutils.BasicDynaBean.set(BasicDynaBean.java:304) at org.apache.commons.beanutils.RowSetDynaClass.copy(RowSetDynaClass.java:240) at org.apache.commons.beanutils.RowSetDynaClass.init(RowSetDynaClass.java:187) at org.apache.commons.beanutils.RowSetDynaClass.init(RowSetDynaClass.java:105) at jdbc.Play.main(Play.java:38) [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver -- Key: BEANUTILS-142 URL: https://issues.apache.org/jira/browse/BEANUTILS-142 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Environment: Operating System: Windows XP Platform: All Reporter: Li Zhang Assignee: Henri Yandell Fix For: 1.8.0 Attachments: Beanutils-142.patch, Play.java Beginning in Oracle 9.2, DATE is mapped to Date and TIMESTAMP is mapped to Timestamp. However if you were relying on DATE values to contain time information, there is a problem. When using Oracle 10g JDBC driver, the ResultSetMetaData.getColumnClassName returns java.sql.Timestamp but ResultSet.getObject(name).getClass() returns java.sql.Date. Obviously these two do not match each other. When the RowSetDynaClass.copy function tries to set the value to BasicDynaBean, it throws exception. Need a workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-18) [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent
[ https://issues.apache.org/jira/browse/BEANUTILS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511973 ] Henri Yandell commented on BEANUTILS-18: I'm +1 to the view that this is a bug and not a backwards compatibility issue. isReadable should return false if the method is not readable. [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent - Key: BEANUTILS-18 URL: https://issues.apache.org/jira/browse/BEANUTILS-18 Project: Commons BeanUtils Issue Type: Bug Components: Bean / Property Utils Environment: Operating System: Windows 2000 Platform: PC Reporter: Maarten Coene Fix For: 1.8.0 Attachments: BEANUTILS-18-PropertyUtilsBean.patch, patch-PropertyUtilsBean.txt, patch-PropertyUtilsTestCase.txt, PropertyUtilsTest.java Hi, When the object passed to PropertyUtils is a non-public class, the PropertyUtils.isReadable() method returns true for an existing property while the PropertyUtils.getProperty() method for the same property throws a NoSuchMethodException. I'll attach a junit test that illustrates the problem. regards, Maarten -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DBCP-229) Track callers of active connections for debugging
[ https://issues.apache.org/jira/browse/DBCP-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511461 ] Henri Yandell commented on DBCP-229: This would be a cool debug mode to have, though I wonder if it would get used more than the alternatives of logging or a profiling/debugging tool. Have we considered a JMX wrapper for DBCP? That would be one way to access such debug data. Track callers of active connections for debugging - Key: DBCP-229 URL: https://issues.apache.org/jira/browse/DBCP-229 Project: Commons Dbcp Issue Type: New Feature Reporter: Armin Häberling Lately we got the following exception org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool exhausted at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:103) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540) The reason for that was that some piece of code opened a connection, but never closed it. Tracking the active connections (and the callers of the getConnection method) would it make it easier to find such erroneous code. One possible approach would be to add the connection returned by BasicDataSource.getConnection together with the stacktrace in a Map holding all active connections. And removing the connection from the map during PoolableDataSource.close(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (CLI-136) junit should only be a test dependency in pom.xml
[ https://issues.apache.org/jira/browse/CLI-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed CLI-136. - Resolution: Won't Fix The (about to be released) 1.1 project.xml has a scopetest/scope set. Both the project.xml and pom.xml in trunk also have it set. junit should only be a test dependency in pom.xml - Key: CLI-136 URL: https://issues.apache.org/jira/browse/CLI-136 Project: Commons CLI Issue Type: Improvement Components: CLI-1.x Affects Versions: 1.0 Environment: Maven 2.0.7 Reporter: Max Berger Priority: Trivial According to http://www.mvnrepository.com/artifact/commons-cli/commons-cli/1.0 commons-cli requires junit to run. instead, this should be a test-only dependency, e.g. please add scopetest/scope to the pom.xml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-341) [NumberUtils] Please add number byte[] methods
[
https://issues.apache.org/jira/browse/LANG-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-341:
---
Fix Version/s: 3.0
Setting fix version to 3.0 for consideration there.
A unit test would be much appreciated by the way :)
[NumberUtils] Please add number byte[] methods
-
Key: LANG-341
URL: https://issues.apache.org/jira/browse/LANG-341
Project: Commons Lang
Issue Type: New Feature
Reporter: Lilianne E. Blaze
Fix For: 3.0
Hello,
I need a set of methods to convert Long to or from a byte[] array, as if
writing / reading from Data(Input/Output)Stream(
ByteArray(Input/Output)Stream ).
First, doing it with Streams seems a bit wasteful, second, it seems a
pretty general use. Would it be possible to add something like that to,
for example,
org.apache.commons.lang.math.NumberUtils?
Example code:
static public long toLong(byte[] b)
{
return toLong(b, 0);
}
static public long toLong(byte[] b, int offset)
{
return (((long)b[offset] 56) +
((long)(b[offset + 1] 255) 48) +
((long)(b[offset + 2] 255) 40) +
((long)(b[offset + 3] 255) 32) +
((long)(b[offset + 4] 255) 24) +
((b[offset + 5] 255) 16) +
((b[offset + 6] 255) 8) +
((b[offset + 7] 255) 0));
}
static public byte[] longToByteArray(long l)
{
byte b[] = new byte[8];
longToByteArray(l, b, 0);
return b;
}
static public void longToByteArray(long l, byte b[], int offset)
{
b[offset] = (byte)(l 56);
b[offset + 1] = (byte)(l 48);
b[offset + 2] = (byte)(l 40);
b[offset + 3] = (byte)(l 32);
b[offset + 4] = (byte)(l 24);
b[offset + 5] = (byte)(l 16);
b[offset + 6] = (byte)(l 8);
b[offset + 7] = (byte)(l 0);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-346) Dates.round() behaves incorrectly for minutes and seconds
[
https://issues.apache.org/jira/browse/LANG-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-346:
---
Fix Version/s: 2.3.1
Dates.round() behaves incorrectly for minutes and seconds
-
Key: LANG-346
URL: https://issues.apache.org/jira/browse/LANG-346
Project: Commons Lang
Issue Type: Bug
Affects Versions: 2.2, 2.3
Reporter: Ken Dombeck
Fix For: 2.3.1
Get unexpected output for rounding by minutes or seconds.
public void testRound()
{
Calendar testCalendar = Calendar.getInstance(TimeZone.getTimeZone(GMT));
testCalendar.set(2007, 6, 2, 8, 9, 50);
Date date = testCalendar.getTime();
System.out.println(Before round() + date);
System.out.println(After round() + DateUtils.round(date,
Calendar.MINUTE));
}
--2.1 produces
Before round() Mon Jul 02 03:09:50 CDT 2007
After round() Mon Jul 02 03:10:00 CDT 2007 -- this is what I would expect
--2.2 and 2.3 produces
Before round() Mon Jul 02 03:09:50 CDT 2007
After round() Mon Jul 02 03:01:00 CDT 2007 -- this appears to be wrong
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-342) HashCodeBuilder.append(long) is incorrect
[
https://issues.apache.org/jira/browse/LANG-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-342:
---
Fix Version/s: 2.3.1
Setting fix version to 2.3.1 so the javadoc can be added. Then it should be
reversioned to 3.0 for consideration there.
HashCodeBuilder.append(long) is incorrect
-
Key: LANG-342
URL: https://issues.apache.org/jira/browse/LANG-342
Project: Commons Lang
Issue Type: Bug
Reporter: Benjamin Manes
Priority: Minor
Fix For: 2.3.1
I was looking at using HashCodeBuilder rather than always writing out the
strategy by hand, and I noticed one potential mistake:
/**
* Append a hashCode for a long.
*
* @param value the long to add to the hashCode
* @return this
*/
public HashCodeBuilder append(long value)
{
iTotal = iTotal * iConstant + ((int) (value ^ (value 32)));
return this;
}
whereas Effective Java and Long.hashCode() use:
/**
* Returns a hash code for this codeLong/code. The result is
* the exclusive OR of the two halves of the primitive
* codelong/code value held by this codeLong/code
* object. That is, the hashcode is the value of the expression:
* blockquotepre
* (int)(this.longValue()^(this.longValue()gt;gt;gt;32))
* /pre/blockquote
*
* @return a hash code value for this object.
*/
public int hashCode() {
return (int)(value ^ (value 32));
}
So the author accidentally used a signed right-shift rather than an unsigned.
Stephen Colebourne noted that while this is a bug, it is minor and could have
backward compatability issues. I would simply recommend that a non-JavaDoc
comment be added noting this method doesn't follow Effective Java correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-340) performance problem with EqualsBuilder.append()
[
https://issues.apache.org/jira/browse/LANG-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-340:
---
Fix Version/s: 3.0
Setting for investigation in 3.0 (though if anyone wants to dig into it, please
feel free).
My suspicion is that a generic library has costs and if this is as centric to
your application as it sounds then we're not going to be able to eke much out.
However - who knows until someone looks :)
performance problem with EqualsBuilder.append()
---
Key: LANG-340
URL: https://issues.apache.org/jira/browse/LANG-340
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.3
Reporter: Ramil Israfilov
Fix For: 3.0
We are using EqualsBuilder for construction of equals() method in our
javabeans.
For example we have a class:
public class SimpleRecord{
String name;
String label;
...
public boolean equals(Object object) {
return new EqualsBuilder().append(this.label, rhs.label).append(
this.getName(), rhs.getName()).isEquals();
}
So far so good.
But one of our applications uses extensively Stack to push/pop SimpleRecord
bean. And it was working very slow.
After profiling of application we saw that most of the time JVM spent in
equals() method of SimpleRecord. (it is called during peek() which is calling
remove() from Stack)
If we replace EqualsBuilder by following code our application worked 3 times
faster ! Could you make some optimizations ?
if (!(object instanceof SimpleRecord)) {
return false;
}
SimpleRecord rhs = (SimpleRecord) object;
if (this.getName() == null rhs.getName() != null) {
return false;
} else
if (rhs.getName() == null this.getName() != null) {
return false;
} else
if (this.label == null rhs.label != null) {
return false;
} else
if (rhs.label == null this.label != null) {
return false;
} else
if (this.label == null rhs.label == null) {
return this.getName().equals(rhs.getName());
} else
return this.getName().equals(rhs.getName())
this.label.equals(rhs.label);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-344) CollatorUtils - equivalent of StringUtils, but using Collators
[ https://issues.apache.org/jira/browse/LANG-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-344: --- Fix Version/s: 3.0 Setting for 3.0 consideration. CollatorUtils - equivalent of StringUtils, but using Collators -- Key: LANG-344 URL: https://issues.apache.org/jira/browse/LANG-344 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.3 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Stephen Kestle has pointed out that equalsIgnoreCase is an English/ASCII hack and that using the Collator class provides a more robust String comparison mechanism. - Most recently this came up when adding new ignore case methods to StringUtils for LANG-326 (also http://tinyurl.com/3d2jjk ) - Raised in regarding case insensitivity for EqualsBuilder and HashCodeBuilder in LANG-316 Creating this issue ticket so this doesn't get forgotten -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (BEANUTILS-287) Missing unit tests using ant and unit test errors using maven
[ https://issues.apache.org/jira/browse/BEANUTILS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed BEANUTILS-287. --- Resolution: Fixed Fix Version/s: 1.8.0 New test target added; ie) I killed the massive duplication as the feature of being able to run just one test from the Ant script doesn't seem worth the risk of missing tests. The MemoryTestCase (which fails) is being excluded as with the project.xml. I also updated the build.properties.sample to not include collections, and to by default look in the local .maven repository. Missing unit tests using ant and unit test errors using maven -- Key: BEANUTILS-287 URL: https://issues.apache.org/jira/browse/BEANUTILS-287 Project: Commons BeanUtils Issue Type: Bug Affects Versions: 1.7.0 Reporter: Gail Badner Fix For: 1.8.0 When running unit tests with ant, 402 tests are executed and all are successful. The following test cases are are not executed with ant: ConstructorUtilsTestCase FileConverterTestCase URLConverterTestCase When running unit tests with maven, 413 tests are executed, but 2 fail: BeanificationTestCase.testMemoryTestMethodology LocaleBeanificationTestCase.testMemoryTestMethodology Both errors are due to java.lang.ClassNotFoundException: org.apache.commons.beanutils.BetaBean When this is fixed, it would be nice if the junit ant task were used to run the tests so that the JUnit report can be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (DBCP-227) Some unit tests are run using maven, but not ant
[ https://issues.apache.org/jira/browse/DBCP-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated DBCP-227: --- Attachment: DBCP-227.patch Attachment: Tests added in, uses junit, fixes commons logging property. Alternatively, could use 'maven ant', I'm not sure at first glance if dbcp is maintaining the custom ant on purpose (ie for the jdbc2/3 support). Some unit tests are run using maven, but not ant Key: DBCP-227 URL: https://issues.apache.org/jira/browse/DBCP-227 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Reporter: Gail Badner Attachments: DBCP-227.patch The following unit tests run using maven, but not ant: TestJOCLContentHandler TestPoolingDataSource TestJndi When this is fixed, it would be nice if the junit ant task were used to run the tests so that the JUnit report can be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-287) Missing unit tests using ant and unit test errors using maven
[
https://issues.apache.org/jira/browse/BEANUTILS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509962
]
Henri Yandell commented on BEANUTILS-287:
-
Either we should 'maven ant' it, or replace all the test bits with:
target name=test depends=compile.tests
description=Run all unit test cases
junit printsummary=true showoutput=true fork=yes
haltonfailure=${test.failonerror}
classpath refid=test.classpath/
batchtest
fileset dir=${test.home}
include name=**/*TestCase.java/
/fileset
/batchtest
/junit
/target
Missing unit tests using ant and unit test errors using maven
--
Key: BEANUTILS-287
URL: https://issues.apache.org/jira/browse/BEANUTILS-287
Project: Commons BeanUtils
Issue Type: Bug
Affects Versions: 1.7.0
Reporter: Gail Badner
When running unit tests with ant, 402 tests are executed and all are
successful.
The following test cases are are not executed with ant:
ConstructorUtilsTestCase
FileConverterTestCase
URLConverterTestCase
When running unit tests with maven, 413 tests are executed, but 2 fail:
BeanificationTestCase.testMemoryTestMethodology
LocaleBeanificationTestCase.testMemoryTestMethodology
Both errors are due to java.lang.ClassNotFoundException:
org.apache.commons.beanutils.BetaBean
When this is fixed, it would be nice if the junit ant task were used to run
the tests so that the JUnit report can be generated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-117) Missing unit tests using ant and maven
[
https://issues.apache.org/jira/browse/DIGESTER-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510005
]
Henri Yandell commented on DIGESTER-117:
Either run 'maven ant', or replace the existing test stuff with:
junit printsummary=true showoutput=true fork=yes
haltonfailure=${test.failonerror}
classpath refid=test.classpath/
batchtest
fileset dir=${test.home}
include name=**/*TestCase.java/
include name=**/*Test.java/
include name=**/plugins/TestAll.java/
include name=**/TestFactoryCreate.java/
/fileset
/batchtest
/junit
Which should we do?
Missing unit tests using ant and maven
--
Key: DIGESTER-117
URL: https://issues.apache.org/jira/browse/DIGESTER-117
Project: Commons Digester
Issue Type: Bug
Affects Versions: 1.8
Reporter: Gail Badner
Currently, 136 unit tests are run using maven and 149 unit tests are run
using ant.
The maven build uses the file patterns:
**/*Test.java
**/*TestCase.java
which misses the following tests:
**/plugins/TestAll.java
**/TestFactoryCreate.java
After the missing tests are added to the maven build, 157 tests are executed.
The ant build does not execute the following tests:
LocationTrackerTestCase
NamespaceSnapshotTestCase
OverlappingCallMethodRuleTestCase
After the missing tests to the ant build, 157 tests are executed.
I'm not sure how this should be fixed; should test cases that don't end in
Test or TestCase be renamed?
When this is fixed, it would be nice if the junit ant task were used to run
the tests so that the JUnit report can be generated.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (CLI-21) [cli] clone method in Option should use super.clone()
[ https://issues.apache.org/jira/browse/CLI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed CLI-21. Resolution: Fixed [cli] clone method in Option should use super.clone() - Key: CLI-21 URL: https://issues.apache.org/jira/browse/CLI-21 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Environment: Operating System: other Platform: Other Reporter: Nathan McDonald Fix For: 1.1 Attachments: bug21.patch, CLI-21.patch In org.apache.commons.cli.Option public method clone is implemented by creating a new instance through one of the class Constructors, and then assigning values as required through the setter methods. This means that any subclasses of the Option class will not return a true clone, but a new Option instance instead. A proper implementation of clone should use super.clone() to create a new instance, rather than calling the class constructor. This allows shallows clones to propogate correctly down to subclasses. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (COLLECTIONS-3) NPE: map.LRUMap.reuseMapping(LRUMap.java:272)
[
https://issues.apache.org/jira/browse/COLLECTIONS-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509351
]
Henri Yandell commented on COLLECTIONS-3:
-
That should be:
synchronized(map) {
Playing with SoakLRUMap, not doing that gives a
ConcurrentModificationException, which hasn't been reported so far.
Mostly I get IllegalStateExceptions when playing with SoakLRUMap and not
synchronizing the Map, however I did get one NPE still:
java.lang.NullPointerException
at org.apache.commons.collections.map.LRUMap.moveToMRU(LRUMap.java:194)
at
org.apache.commons.collections.map.LRUMap.updateEntry(LRUMap.java:217)
Line is:
entry.before.after = entry.after;
Which, looking at the code, implies that entry.before is null. Maybe another
place to put a state check?
Maybe a state check would be worth it there too?
NPE: map.LRUMap.reuseMapping(LRUMap.java:272)
-
Key: COLLECTIONS-3
URL: https://issues.apache.org/jira/browse/COLLECTIONS-3
Project: Commons Collections
Issue Type: Bug
Components: Map
Affects Versions: 3.1
Environment: Operating System: Linux
Platform: PC
Reporter: Otis Gospodnetic
Attachments: commons-collections-3.2-LRUMap-debug.jar, LRUMap.java,
SoakLRUMap.java
I'm using Collections 3.1 and just found this NPE in my logs:
java.lang.NullPointerException
at
org.apache.commons.collections.map.LRUMap.reuseMapping(LRUMap.java:272)
at
org.apache.commons.collections.map.LRUMap.addMapping(LRUMap.java:243)
at
org.apache.commons.collections.map.AbstractHashedMap.put(AbstractHashedMap.java:282)
I instantiated LRUMap like this:
LRUMap map = new LRUMap(31);
And from there on, I use it like I'd use any Map, putting things into
it, and so on. Maybe I'm not using LRUMap correctly? My _guess_ is
that this occurs when the Map is full, but I am not certain.
I am wrapping the LRUMap in my own Maps as follows, but I think they're
not the culprit:
LRUMap map = new LRUMap(31);
_userSessions = new ExpiringMap(map,
new TimerTTLReferenceHolder(180), // ttl=30min
30); // purge frequency=5min
The only similar thing I found is COM-1288, but it looks like that was fixed
before 3.1 release.
I understand the value of a self-contained unit test that demonstrates this
bug,
but it happens only occassionally on my production system, never during
development, so I can't really come up with it :(
My guess is that this is a boundary case, as line 272 is:
loop = loop.next;
So 'loop' is most likely null, and it's null because ... not sure, maybe that
hashIndex is wrong.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CLI-21) [cli] clone method in Option should use super.clone()
[ https://issues.apache.org/jira/browse/CLI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509022 ] Henri Yandell commented on CLI-21: -- Another thought - as I kick myself to keep momentum on the CLI release. Need to find out if a change from: public Object clone() to protected Object clone() throws CloneNotSupportedException will be voted down. I presume it will. [cli] clone method in Option should use super.clone() - Key: CLI-21 URL: https://issues.apache.org/jira/browse/CLI-21 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Environment: Operating System: other Platform: Other Reporter: Nathan McDonald Fix For: 1.1 Attachments: bug21.patch In org.apache.commons.cli.Option public method clone is implemented by creating a new instance through one of the class Constructors, and then assigning values as required through the setter methods. This means that any subclasses of the Option class will not return a true clone, but a new Option instance instead. A proper implementation of clone should use super.clone() to create a new instance, rather than calling the class constructor. This allows shallows clones to propogate correctly down to subclasses. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CLI-134) 1.1 is not backwards compatible because it adds methods to the CommandLineParser interface
1.1 is not backwards compatible because it adds methods to the CommandLineParser interface -- Key: CLI-134 URL: https://issues.apache.org/jira/browse/CLI-134 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Reporter: Henri Yandell Fix For: 1.1 Attachments: CLI-134.patch General problem - the interface adds methods. Solution - remove the interfaces from the methods and people who want to use them will have to use the Parser abstract class instead of the CommandLineParser interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CLI-134) 1.1 is not backwards compatible because it adds methods to the CommandLineParser interface
[ https://issues.apache.org/jira/browse/CLI-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated CLI-134: -- Attachment: CLI-134.patch Patch removing the methods. 1.1 is not backwards compatible because it adds methods to the CommandLineParser interface -- Key: CLI-134 URL: https://issues.apache.org/jira/browse/CLI-134 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Reporter: Henri Yandell Fix For: 1.1 Attachments: CLI-134.patch General problem - the interface adds methods. Solution - remove the interfaces from the methods and people who want to use them will have to use the Parser abstract class instead of the CommandLineParser interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (CLI-134) 1.1 is not backwards compatible because it adds methods to the CommandLineParser interface
[ https://issues.apache.org/jira/browse/CLI-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed CLI-134. - Resolution: Fixed Applied to SVN - r551811. 1.1 is not backwards compatible because it adds methods to the CommandLineParser interface -- Key: CLI-134 URL: https://issues.apache.org/jira/browse/CLI-134 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Reporter: Henri Yandell Fix For: 1.1 Attachments: CLI-134.patch General problem - the interface adds methods. Solution - remove the interfaces from the methods and people who want to use them will have to use the Parser abstract class instead of the CommandLineParser interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (CLI-134) 1.1 is not backwards compatible because it adds methods to the CommandLineParser interface
[ https://issues.apache.org/jira/browse/CLI-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened CLI-134: --- Damn. Missed and removed a method I shouldn't have :) Leaving one in that should have stayed. 1.1 is not backwards compatible because it adds methods to the CommandLineParser interface -- Key: CLI-134 URL: https://issues.apache.org/jira/browse/CLI-134 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Reporter: Henri Yandell Fix For: 1.1 Attachments: CLI-134.patch General problem - the interface adds methods. Solution - remove the interfaces from the methods and people who want to use them will have to use the Parser abstract class instead of the CommandLineParser interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CLI-21) [cli] clone method in Option should use super.clone()
[ https://issues.apache.org/jira/browse/CLI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated CLI-21: - Attachment: CLI-21.patch Patch making the clone method public again, and dropping the exception. [cli] clone method in Option should use super.clone() - Key: CLI-21 URL: https://issues.apache.org/jira/browse/CLI-21 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Environment: Operating System: other Platform: Other Reporter: Nathan McDonald Fix For: 1.1 Attachments: bug21.patch, CLI-21.patch In org.apache.commons.cli.Option public method clone is implemented by creating a new instance through one of the class Constructors, and then assigning values as required through the setter methods. This means that any subclasses of the Option class will not return a true clone, but a new Option instance instead. A proper implementation of clone should use super.clone() to create a new instance, rather than calling the class constructor. This allows shallows clones to propogate correctly down to subclasses. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CLI-21) [cli] clone method in Option should use super.clone()
[ https://issues.apache.org/jira/browse/CLI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509037 ] Henri Yandell commented on CLI-21: -- Here's the clirr error: ERROR: 7009: org.apache.commons.cli.Option: Accessibility of method 'public java.lang.Object clone()' has been decreased from public to protected Solutionwise, I guess we make it public again, drop the exception and throw a RuntimeException if it's thrown. Will attach a patch to that end. I am confused that Clirr doesn't seem to care about the exception being added. [cli] clone method in Option should use super.clone() - Key: CLI-21 URL: https://issues.apache.org/jira/browse/CLI-21 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Environment: Operating System: other Platform: Other Reporter: Nathan McDonald Fix For: 1.1 Attachments: bug21.patch, CLI-21.patch In org.apache.commons.cli.Option public method clone is implemented by creating a new instance through one of the class Constructors, and then assigning values as required through the setter methods. This means that any subclasses of the Option class will not return a true clone, but a new Option instance instead. A proper implementation of clone should use super.clone() to create a new instance, rather than calling the class constructor. This allows shallows clones to propogate correctly down to subclasses. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CLI-135) Backwards compatibility between 1.1 and 1.0 broken due to Option.addValue removal
Backwards compatibility between 1.1 and 1.0 broken due to Option.addValue removal - Key: CLI-135 URL: https://issues.apache.org/jira/browse/CLI-135 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Reporter: Henri Yandell Fix For: 1.1 ERROR: 7006: org.apache.commons.cli.Option: Return type of method 'public boolean addValue(java.lang.String)' has been changed to void ERROR: 7009: org.apache.commons.cli.Option: Accessibility of method 'public boolean addValue(java.lang.String)' has been decreased from public to package -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CLI-135) Backwards compatibility between 1.1 and 1.0 broken due to Option.addValue removal
[ https://issues.apache.org/jira/browse/CLI-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509029 ] Henri Yandell commented on CLI-135: --- First step is to change the package private addValue variant so it no longer clashes. Second step is to put back the old addValue method in some non-useful way. Backwards compatibility between 1.1 and 1.0 broken due to Option.addValue removal - Key: CLI-135 URL: https://issues.apache.org/jira/browse/CLI-135 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Reporter: Henri Yandell Fix For: 1.1 ERROR: 7006: org.apache.commons.cli.Option: Return type of method 'public boolean addValue(java.lang.String)' has been changed to void ERROR: 7009: org.apache.commons.cli.Option: Accessibility of method 'public boolean addValue(java.lang.String)' has been decreased from public to package -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CLI-135) Backwards compatibility between 1.1 and 1.0 broken due to Option.addValue removal
[ https://issues.apache.org/jira/browse/CLI-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated CLI-135: -- Attachment: CLI-135.patch Attaching a patch to do both of these. The new method is addValueForProcessing. Backwards compatibility between 1.1 and 1.0 broken due to Option.addValue removal - Key: CLI-135 URL: https://issues.apache.org/jira/browse/CLI-135 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Reporter: Henri Yandell Fix For: 1.1 Attachments: CLI-135.patch ERROR: 7006: org.apache.commons.cli.Option: Return type of method 'public boolean addValue(java.lang.String)' has been changed to void ERROR: 7009: org.apache.commons.cli.Option: Accessibility of method 'public boolean addValue(java.lang.String)' has been decreased from public to package -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CLI-135) Backwards compatibility between 1.1 and 1.0 broken due to Option.addValue removal
[ https://issues.apache.org/jira/browse/CLI-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated CLI-135: -- Attachment: CLI-135-2nd.patch Got the parameter wrong on the new/old addValue. I did Object, should have been String. This patch fixes that. Backwards compatibility between 1.1 and 1.0 broken due to Option.addValue removal - Key: CLI-135 URL: https://issues.apache.org/jira/browse/CLI-135 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Reporter: Henri Yandell Fix For: 1.1 Attachments: CLI-135-2nd.patch, CLI-135.patch ERROR: 7006: org.apache.commons.cli.Option: Return type of method 'public boolean addValue(java.lang.String)' has been changed to void ERROR: 7009: org.apache.commons.cli.Option: Accessibility of method 'public boolean addValue(java.lang.String)' has been decreased from public to package -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (CLI-135) Backwards compatibility between 1.1 and 1.0 broken due to Option.addValue removal
[ https://issues.apache.org/jira/browse/CLI-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed CLI-135. - Resolution: Fixed Patches applied. Clirr no longer errors. Backwards compatibility between 1.1 and 1.0 broken due to Option.addValue removal - Key: CLI-135 URL: https://issues.apache.org/jira/browse/CLI-135 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Reporter: Henri Yandell Fix For: 1.1 Attachments: CLI-135-2nd.patch, CLI-135.patch ERROR: 7006: org.apache.commons.cli.Option: Return type of method 'public boolean addValue(java.lang.String)' has been changed to void ERROR: 7009: org.apache.commons.cli.Option: Accessibility of method 'public boolean addValue(java.lang.String)' has been decreased from public to package -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CLI-134) 1.1 is not backwards compatible because it adds methods to the CommandLineParser interface
[ https://issues.apache.org/jira/browse/CLI-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated CLI-134: -- Attachment: CLI-134-2nd.patch Last patch commented out the wrong method. This patch fixes that and fixes a unit test that breaks. 1.1 is not backwards compatible because it adds methods to the CommandLineParser interface -- Key: CLI-134 URL: https://issues.apache.org/jira/browse/CLI-134 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Reporter: Henri Yandell Fix For: 1.1 Attachments: CLI-134-2nd.patch, CLI-134.patch General problem - the interface adds methods. Solution - remove the interfaces from the methods and people who want to use them will have to use the Parser abstract class instead of the CommandLineParser interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (CLI-134) 1.1 is not backwards compatible because it adds methods to the CommandLineParser interface
[ https://issues.apache.org/jira/browse/CLI-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed CLI-134. - Resolution: Fixed Second patch solves it. 1.1 is not backwards compatible because it adds methods to the CommandLineParser interface -- Key: CLI-134 URL: https://issues.apache.org/jira/browse/CLI-134 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Reporter: Henri Yandell Fix For: 1.1 Attachments: CLI-134-2nd.patch, CLI-134.patch General problem - the interface adds methods. Solution - remove the interfaces from the methods and people who want to use them will have to use the Parser abstract class instead of the CommandLineParser interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (FILEUPLOAD-137) MultipartStream public API broken
[ https://issues.apache.org/jira/browse/FILEUPLOAD-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened FILEUPLOAD-137: -- Still a problem. According to findbugs, there are still errors: Message: Non-virtual method call in org.apache.commons.fileupload.MultipartStream.MultipartStream() passes null for unconditionally dereferenced parameter of org.apache.commons.fileupload.MultipartStream.MultipartStream(java.io.InputStream,byte[],MultipartStream) Looking at the code, the boundary parameter jumps out as one that will throw an NPE if you call new MultipartStream(). MultipartStream public API broken - Key: FILEUPLOAD-137 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-137 Project: Commons FileUpload Issue Type: Bug Affects Versions: 1.2 Reporter: Mark Sinke Assignee: Jochen Wiedmann Fix For: 1.2.1 In commons-transaction 1.2 the MultipartStream class has 2 public constructors. Both are deprecated; however their implementation delegates to non-visible (package-private) constructors. There are two issues here: 1. the deprecated, delegating constructors use a null pointer for the progress notifier, which in turn yield a NullPointerException when you try to use them 2. the non-deprecated constructors are not visible. Hence, I cannot really upgrade from 1.0 to 1.2. Thanks, Mark. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (COLLECTIONS-257) CollectionUtils.removeAll() calls ListUtils.retainAll()
[
https://issues.apache.org/jira/browse/COLLECTIONS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed COLLECTIONS-257.
-
Resolution: Duplicate
Fix Version/s: 3.3
Duplicate of COLLECTIONS-219, which has been fixed in trunk.
CollectionUtils.removeAll() calls ListUtils.retainAll()
---
Key: COLLECTIONS-257
URL: https://issues.apache.org/jira/browse/COLLECTIONS-257
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 3.2
Reporter: Sami Kallio
Fix For: 3.3
/**
* Returns a collection containing all the elements in
codecollection/code
* that are also in coderetain/code. The cardinality of an element
codee/code
* in the returned collection is the same as the cardinality of
codee/code
* in codecollection/code unless coderetain/code does not contain
codee/code, in which
* case the cardinality is zero. This method is useful if you do not wish
to modify
* the collection codec/code and thus cannot call
codec.retainAll(retain);/code.
*
* @param collection the collection whose contents are the target of the
#retailAll operation
* @param retain the collection containing the elements to be retained
in the returned collection
* @return a codeCollection/code containing all the elements of
codecollection/code
* that occur at least once in coderetain/code.
* @throws NullPointerException if either parameter is null
* @since Commons Collections 3.2
*/
public static Collection retainAll(Collection collection, Collection
retain) {
return ListUtils.retainAll(collection, retain);
}
/**
* Removes the elements in coderemove/code from
codecollection/code. That is, this
* method returns a collection containing all the elements in
codec/code
* that are not in coderemove/code. The cardinality of an element
codee/code
* in the returned collection is the same as the cardinality of
codee/code
* in codecollection/code unless coderemove/code contains
codee/code, in which
* case the cardinality is zero. This method is useful if you do not wish
to modify
* the collection codec/code and thus cannot call
codecollection.removeAll(remove);/code.
*
* @param collection the collection from which items are removed (in the
returned collection)
* @param remove the items to be removed from the returned
codecollection/code
* @return a codeCollection/code containing all the elements of
codecollection/code except
* any elements that also occur in coderemove/code.
* @throws NullPointerException if either parameter is null
* @since Commons Collections 3.2
*/
public static Collection removeAll(Collection collection, Collection
remove) {
return ListUtils.retainAll(collection, remove);
}
I guess the later method shoud be:
public static Collection removeAll(Collection collection, Collection
remove) {
return ListUtils.removeAll(collection, remove);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CLI-21) [cli] clone method in Option should use super.clone()
[ https://issues.apache.org/jira/browse/CLI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505282 ] Henri Yandell commented on CLI-21: -- Patch applied - thanks for doing that Brian. One question - when cloning, should the effects of addValue/processValue be undone? ie) Rather than: option.values = new ArrayList(values); it should be: option.values = new ArrayList(); Or should we just recommend in the javadoc for clone() that people will probably want to immediatley call clearValues()? [cli] clone method in Option should use super.clone() - Key: CLI-21 URL: https://issues.apache.org/jira/browse/CLI-21 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Environment: Operating System: other Platform: Other Reporter: Nathan McDonald Fix For: 1.1 Attachments: bug21.patch In org.apache.commons.cli.Option public method clone is implemented by creating a new instance through one of the class Constructors, and then assigning values as required through the setter methods. This means that any subclasses of the Option class will not return a true clone, but a new Option instance instead. A proper implementation of clone should use super.clone() to create a new instance, rather than calling the class constructor. This allows shallows clones to propogate correctly down to subclasses. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (CLI-21) [cli] clone method in Option should use super.clone()
[ https://issues.apache.org/jira/browse/CLI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell reopened CLI-21: -- [cli] clone method in Option should use super.clone() - Key: CLI-21 URL: https://issues.apache.org/jira/browse/CLI-21 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0 Environment: Operating System: other Platform: Other Reporter: Nathan McDonald Fix For: 1.1 In org.apache.commons.cli.Option public method clone is implemented by creating a new instance through one of the class Constructors, and then assigning values as required through the setter methods. This means that any subclasses of the Option class will not return a true clone, but a new Option instance instead. A proper implementation of clone should use super.clone() to create a new instance, rather than calling the class constructor. This allows shallows clones to propogate correctly down to subclasses. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EL-2) [el] Properties with second letter upper case are not resolved
[ https://issues.apache.org/jira/browse/EL-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504356 ] Henri Yandell commented on EL-2: Sorry for never replying on this one - and it's not much of a reply now :) I've no idea whether it would counter the spec or not. [el] Properties with second letter upper case are not resolved -- Key: EL-2 URL: https://issues.apache.org/jira/browse/EL-2 Project: Commons EL Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: navid vahdat Using JavaServer Faces (MyFaces implementation), it is not possible to access backing bean properties like xTest. This bug seems to have been filed with MyFaces before (see http://issues.apache.org/jira/browse/MYFACES-31) My application is generated by user input. I can't influence the naming of properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (EL-2) [el] Properties with second letter upper case are not resolved
[ https://issues.apache.org/jira/browse/EL-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated EL-2: --- Description: Using JavaServer Faces (MyFaces implementation), it is not possible to access backing bean properties like xTest. This bug seems to have been filed with MyFaces before (see MYFACES-31 ) My application is generated by user input. I can't influence the naming of properties. was: Using JavaServer Faces (MyFaces implementation), it is not possible to access backing bean properties like xTest. This bug seems to have been filed with MyFaces before (see http://issues.apache.org/jira/browse/MYFACES-31) My application is generated by user input. I can't influence the naming of properties. [el] Properties with second letter upper case are not resolved -- Key: EL-2 URL: https://issues.apache.org/jira/browse/EL-2 Project: Commons EL Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: navid vahdat Using JavaServer Faces (MyFaces implementation), it is not possible to access backing bean properties like xTest. This bug seems to have been filed with MyFaces before (see MYFACES-31 ) My application is generated by user input. I can't influence the naming of properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (EL-2) [el] Properties with second letter upper case are not resolved
[ https://issues.apache.org/jira/browse/EL-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated EL-2: --- Comment: was deleted [el] Properties with second letter upper case are not resolved -- Key: EL-2 URL: https://issues.apache.org/jira/browse/EL-2 Project: Commons EL Issue Type: Bug Environment: Operating System: other Platform: Other Reporter: navid vahdat Using JavaServer Faces (MyFaces implementation), it is not possible to access backing bean properties like xTest. This bug seems to have been filed with MyFaces before (see MYFACES-31 ) My application is generated by user input. I can't influence the naming of properties. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DBCP-218) basicDataSource.setLoginTimeout(n) not work?
[ https://issues.apache.org/jira/browse/DBCP-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed DBCP-218. -- Resolution: Fixed svn ci -m Adding the Javadoc to state that getLoginTimeout and setLoginTimeout are NOT supported by BasicDataSource as per DBCP-218 src/java/org/apache/commons/dbcp/BasicDataSource.java Sendingsrc/java/org/apache/commons/dbcp/BasicDataSource.java Transmitting file data . Committed revision 546583. basicDataSource.setLoginTimeout(n) not work? Key: DBCP-218 URL: https://issues.apache.org/jira/browse/DBCP-218 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.1, 1.2, 1.2.1, 1.2.2 Environment: Windows Reporter: Bill Liu Fix For: 1.3 Hi: We tried to set the login timeout value of the basic data source but got the exception. Is this feature (Login timeout is not supported.)? We want the connection pool not to wait forever if the database is too busy. Any ideas? Thanks. In the code: BasicDataSource bds = new BasicDataSource(); bds.setDriverClassName(oracle.jdbc.driver.OracleDriver); bds.setUsername(my username); bds.setPassword(my password); bds.setUrl(jdbc:oracle:thin:@mrhost:1521:test); bds.setMaxActive(2); bds.setLoginTimeout(5); Result: Exception in thread main java.lang.UnsupportedOperationException: Login timeout is not supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DBCP-211) Add m2 pom.xml for DBCP
[ https://issues.apache.org/jira/browse/DBCP-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed DBCP-211. -- Resolution: Fixed svn ci -m Adding a Maven2 pom.xml as per DBCP-211. I've removed a block of code from TestJOCLed that set the Xerces parser manually, I presume it was only there for odd situations in old JDKs. Adding pom.xml Sendingsrc/test/org/apache/commons/dbcp/TestJOCLed.java Transmitting file data .. Committed revision 546584. Add m2 pom.xml for DBCP --- Key: DBCP-211 URL: https://issues.apache.org/jira/browse/DBCP-211 Project: Commons Dbcp Issue Type: Improvement Reporter: Henri Yandell Fix For: 1.3 Attachments: DBCP-211.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (IO-116) Replace static FileCleaner methods
[ https://issues.apache.org/jira/browse/IO-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504120 ] Henri Yandell commented on IO-116: -- Agreed - that would be mad :) I think I meant: * Given that FileCleaner is static, why not implement FileCleaningTestCase inside FileCleanerTestCase? Or rather: Why have a FileCleanerTestCase? Will bring up on list. Replace static FileCleaner methods -- Key: IO-116 URL: https://issues.apache.org/jira/browse/IO-116 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 1.3.1 Reporter: Jochen Wiedmann Priority: Critical Fix For: 1.3.2 Attachments: commons-io-filecleaningtracker.patch, commons-io-filecleaningtracker.patch The attached patch aims to finally resolve the problems, which are named in IO-99, FILEUPLOAD-120, and FILEUPLOAD-125. I choosed a conservative strategy: Basically I copied the FileCleaner class to an instantiable class FileCleaningTracker with instance methods. The static FileCleaner methods are now implemented by a static instance of FileCleaningTracker. (The name FileCleaningTracker is, of course, questionable. The FileCleaningTestCase was also created by simply copying FileCleaner to FileCleaningTestCase. FileCleanerTestCase is now similarly implemented as a subclass of FileCleanerTestCase which uses the static instance of FileCleaner rather than a dynamically created instance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-333) ArrayUtils.toClass
[ https://issues.apache.org/jira/browse/LANG-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-333: --- Fix Version/s: 3.0 Another 'wish we had closures' one :) ArrayUtils.toClass -- Key: LANG-333 URL: https://issues.apache.org/jira/browse/LANG-333 Project: Commons Lang Issue Type: Improvement Reporter: Jörg Gottschling Fix For: 3.0 ArrayUtils should have a Method toClass(array : Object[]) : Class[] which creates a new Array with the Class-Objects of the Objects in the Array. Very nice for Reflection. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-337) Utility class constructor javadocs should acknowledge that they may sometimes be used, e.g. with Velocity.
[ https://issues.apache.org/jira/browse/LANG-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-337: --- Fix Version/s: 2.3.1 Utility class constructor javadocs should acknowledge that they may sometimes be used, e.g. with Velocity. -- Key: LANG-337 URL: https://issues.apache.org/jira/browse/LANG-337 Project: Commons Lang Issue Type: Wish Affects Versions: 2.3 Reporter: Keith R. Bennett Priority: Minor Fix For: 2.3.1 Utility class constructors currently have javadoc comments that say: StringUtils instances should NOT be constructed in standard programming. However, there are some cases where it is necessary to use them to create instances. For example, using the utility methods in a Velocity context requires that an instance be created. It is true that the current comment does not exclude this use, but the emphasis (NOT) implies that there is a possibility it will be deprecated, removed, or otherwise be made inaccessible in the future. I'd like to suggest modifying the message to more explicitly acknowledge that the constructor's use is approved in some cases, so as to reassure developers that it will continue to be available in the future. One possible wording would be to retain the existing comment, and add to it: However, in some cases (for example, for use with Velocity), it is necessary to create an instance of this class. It is recommended that this constructor be used only in special cases such as this. (This issue really applies to all projects with utility classes with this javadoc, so feel free to copy it them as well.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-339) StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, Japanes, etc.
[ https://issues.apache.org/jira/browse/LANG-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-339: --- Fix Version/s: 3.0 StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, Japanes, etc. --- Key: LANG-339 URL: https://issues.apache.org/jira/browse/LANG-339 Project: Commons Lang Issue Type: Bug Affects Versions: 2.3 Environment: Operating System: All Platform: All Reporter: Guo Yong Fix For: 3.0 StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, Japanes, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-339) StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, Japanes, etc.
[ https://issues.apache.org/jira/browse/LANG-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12503687 ] Henri Yandell commented on LANG-339: Probably the same code as LANG-66, but leaving open so a separate unit test can be written. StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, Japanes, etc. --- Key: LANG-339 URL: https://issues.apache.org/jira/browse/LANG-339 Project: Commons Lang Issue Type: Bug Affects Versions: 2.3 Environment: Operating System: All Platform: All Reporter: Guo Yong Fix For: 3.0 StringEscapeUtils.escapeHtml() escapes multibyte characters like Chinese, Japanes, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (BEANUTILS-59) [beanutils] Memory leak on webapp undeploy in WrapDynaClass
[ https://issues.apache.org/jira/browse/BEANUTILS-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed BEANUTILS-59. -- Resolution: Fixed Closing as Niall's fix is committed. [beanutils] Memory leak on webapp undeploy in WrapDynaClass --- Key: BEANUTILS-59 URL: https://issues.apache.org/jira/browse/BEANUTILS-59 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Affects Versions: 1.6 Environment: Operating System: All Platform: All Reporter: Simon Kitching Fix For: 1.8.0 Attachments: beanutils-59.patch Class WrapDynaClass has a HashMap dynaClasses containing a mapping from Class to WrapDynaClass. If this class were to be deployed via a shared webapp, then any reference in there to a class loaded via the webapp classloader will prevent the webapp classloader from being garbage-collected when the webapp is undeployed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-334) Enum is not thread-safe
[ https://issues.apache.org/jira/browse/LANG-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502464 ] Henri Yandell commented on LANG-334: I agree - but I really hate solving things without being able to show there was a problem and then confirming that the problem no longer appears. Did this change fix the symptoms you were seeing in your system? Enum is not thread-safe --- Key: LANG-334 URL: https://issues.apache.org/jira/browse/LANG-334 Project: Commons Lang Issue Type: Bug Reporter: Michael Sclafani Fix For: 2.3.1 Attachments: EnumPlay.java Enum uses no synchronization. Even if you assume that instances are only declared statically, the cEnumClasses map is global and can be written to when a thread triggers static initialization of B.class while some other thread is doing getEnumList(A.class). Unsynchronized access of a map undergoing mutation is not thread-safe. This isn't theoretical. We're seeing ValuedEnum.getEnum(X.class, 0) return null after returning the correct value over 100,000 times, and then return the correct value again on the next invocation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JXPATH-87) xmlURL field not set in XMLDocumentContainer
xmlURL field not set in XMLDocumentContainer Key: JXPATH-87 URL: https://issues.apache.org/jira/browse/JXPATH-87 Project: Commons JXPath Issue Type: Bug Affects Versions: Nightly Builds Reporter: Henri Yandell Assignee: Henri Yandell Fix For: 1.3 The only symptom of this is that if an exception is thrown, it will never show the url in the debug. [Found via: http://opensource.fortifysoftware.com/ ] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (COLLECTIONS-255) Unused variable in TreeBidiMap.java
Unused variable in TreeBidiMap.java --- Key: COLLECTIONS-255 URL: https://issues.apache.org/jira/browse/COLLECTIONS-255 Project: Commons Collections Issue Type: Bug Components: BidiMap Affects Versions: Nightly Builds Reporter: Henri Yandell Priority: Trivial Fix For: 3.3 Twice in TreeBidiMap there is an entrySet variable that is not used. Rather the entrySet() method returns a new TreeView every time. We should either: a) Delete the variable. b) Use the variable and always return the same TreeView. I'm thinking a). [Found via http://opensource.fortifysoftware.com/ ] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (JXPATH-87) xmlURL field not set in XMLDocumentContainer
[ https://issues.apache.org/jira/browse/JXPATH-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed JXPATH-87. --- Resolution: Fixed Fixed by storing the xmlURL for later. svn ci -m Fixing JXPATH-87 by storing the xmlURL src/ Sendingsrc/java/org/apache/commons/jxpath/XMLDocumentContainer.java Transmitting file data . Committed revision 545359. xmlURL field not set in XMLDocumentContainer Key: JXPATH-87 URL: https://issues.apache.org/jira/browse/JXPATH-87 Project: Commons JXPath Issue Type: Bug Affects Versions: Nightly Builds Reporter: Henri Yandell Assignee: Henri Yandell Fix For: 1.3 The only symptom of this is that if an exception is thrown, it will never show the url in the debug. [Found via: http://opensource.fortifysoftware.com/ ] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (CLI-133) NullPointerException in Util.stripLeadingHyphens when passed a null argument
[ https://issues.apache.org/jira/browse/CLI-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed CLI-133. - Resolution: Fixed Patch applied. NullPointerException in Util.stripLeadingHyphens when passed a null argument Key: CLI-133 URL: https://issues.apache.org/jira/browse/CLI-133 Project: Commons CLI Issue Type: Bug Components: CLI-1.x Affects Versions: 1.0, 1.1 Reporter: Brian Egge Priority: Minor Fix For: 1.1 Attachments: bug133.patch If you try to do a hasOption(null), you get a NPE: java.lang.NullPointerException at org.apache.commons.cli.Util.stripLeadingHyphens(Util.java:39) at org.apache.commons.cli.CommandLine.resolveOption(CommandLine.java:166) at org.apache.commons.cli.CommandLine.hasOption(CommandLine.java:68) Either hasOption should reject the null argument, or the function should simply return false. I think the latter makes more since, as this is how Java collections generally work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CLI-131) Options class returns options in random order
[ https://issues.apache.org/jira/browse/CLI-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501838 ] Henri Yandell commented on CLI-131: --- Patches applied. Thanks Brian :) I moved the HelpFormatterTest stuff into TestHelpFormatter. I'll rename that file to the more logical HelpFormatterTest in a moment. Options class returns options in random order - Key: CLI-131 URL: https://issues.apache.org/jira/browse/CLI-131 Project: Commons CLI Issue Type: Improvement Components: CLI-1.x Affects Versions: 1.0, 1.1 Reporter: Brian Egge Priority: Minor Fix For: 1.1 Attachments: bug131.patch, bug131b.patch The help formatter auto usage returns the options in a somewhat random order. This is because the options are inserted in a HashMap, and then a copy of the collection is returned with the getOptions() method. The getOptions method should return the options in the order they were added, or in a sorted order. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (CLI-131) Options class returns options in random order
[ https://issues.apache.org/jira/browse/CLI-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed CLI-131. - Resolution: Fixed Rename done. Options class returns options in random order - Key: CLI-131 URL: https://issues.apache.org/jira/browse/CLI-131 Project: Commons CLI Issue Type: Improvement Components: CLI-1.x Affects Versions: 1.0, 1.1 Reporter: Brian Egge Priority: Minor Fix For: 1.1 Attachments: bug131.patch, bug131b.patch The help formatter auto usage returns the options in a somewhat random order. This is because the options are inserted in a HashMap, and then a copy of the collection is returned with the getOptions() method. The getOptions method should return the options in the order they were added, or in a sorted order. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (BEANUTILS-281) BeanUtils.cloneBean and Covariant (Overriding) return types
[
https://issues.apache.org/jira/browse/BEANUTILS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated BEANUTILS-281:
Fix Version/s: LATER THAN 1.8.0
I doubt we'll do anything about this in 1.8.0 as covariant return types are a
JDK 1.5 feature and I'm sure 1.8.0 won't be 1.5 dependent. It's possible the
feature could be added without using 1.5, but I suspect the code requiring
change would turn out to be in java.beans.
BeanUtils.cloneBean and Covariant (Overriding) return types
---
Key: BEANUTILS-281
URL: https://issues.apache.org/jira/browse/BEANUTILS-281
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Environment: JDK1.5
Reporter: Onur Kutlu GAGO
Fix For: LATER THAN 1.8.0
BeanUtils.cloneBean(Object) method does not copy the fields that are
overriden by the subclasses. For example, consider an abstract
class(AbstractVehicle) where you define an abstract getter for a field.
**
public abstract class AbstractVehicle {
public abstract Serializable getField();
}
***
In a class (Car) that extends this abstract class (AbstractVehicle) you
define the field itself and override the return type of the getter method
(from Serializable to Integer):
***
public class Car extends AbstractVehicle {
private Integer field = null;
@Override
public Integer getField() {
return field;
}
public void setField(Integer field) {
this.field = field;
}
}
***
When you clone such objects (Car) this field is not copied! The following
code prints 'null' instead of 5!
***
public class CopyTestMain {
public static void main(String[] args) throws IllegalAccessException,
InstantiationException, InvocationTargetException, NoSuchMethodException {
final Car aCar = new Car();
aCar.setField(5);
final Car copyCar = (Car) BeanUtils.cloneBean(aCar);
System.out.println(Field = + copyCar.getField());
}
}
***
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-334) Enum is not thread-safe
[ https://issues.apache.org/jira/browse/LANG-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-334: --- Attachment: EnumPlay.java I made an attempt at a test, but it couldn't replicate the issue. Enum is not thread-safe --- Key: LANG-334 URL: https://issues.apache.org/jira/browse/LANG-334 Project: Commons Lang Issue Type: Bug Reporter: Michael Sclafani Fix For: 2.3.1 Attachments: EnumPlay.java Enum uses no synchronization. Even if you assume that instances are only declared statically, the cEnumClasses map is global and can be written to when a thread triggers static initialization of B.class while some other thread is doing getEnumList(A.class). Unsynchronized access of a map undergoing mutation is not thread-safe. This isn't theoretical. We're seeing ValuedEnum.getEnum(X.class, 0) return null after returning the correct value over 100,000 times, and then return the correct value again on the next invocation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-338) truncateNicely method which avoids truncating in the middle of a word
[ https://issues.apache.org/jira/browse/LANG-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-338: --- Fix Version/s: 3.0 A few bugs would need fixing first: http://issues.apache.org/bugzilla/show_bug.cgi?id=35569 (contains 2 other bugs) http://issues.apache.org/bugzilla/show_bug.cgi?id=36788 and a lot more unit testing. It is a popular tag in the String taglib though, so would ostensibly be a popular function for Lang. truncateNicely method which avoids truncating in the middle of a word - Key: LANG-338 URL: https://issues.apache.org/jira/browse/LANG-338 Project: Commons Lang Issue Type: New Feature Reporter: matt humphreys Priority: Trivial Fix For: 3.0 as provided by jakarta string taglib. It would be good if this was part of commons as it doesn't make sense to use a taglib jar for non-web projects. The taglib javadoc says: ...It will search for the first space after the lower limit and truncate the string there. It will also append any string passed as a parameter to the end of the string. The hard limit can be specified to forcibily truncate a string (in the case of an extremely long word or such)... http://jakarta.apache.org/taglibs/doc/string-doc/string-1.1.0/javadoc/org/apache/taglibs/string/util/StringW.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-334) Enum is not thread-safe
[ https://issues.apache.org/jira/browse/LANG-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502107 ] Henri Yandell commented on LANG-334: Sorry for missing the two class bit. I'm not looking for a unit test, just a way to replicate the issue so that a fix can be created. Failing that, find time to sit and think hard :) Enum is not thread-safe --- Key: LANG-334 URL: https://issues.apache.org/jira/browse/LANG-334 Project: Commons Lang Issue Type: Bug Reporter: Michael Sclafani Fix For: 2.3.1 Attachments: EnumPlay.java Enum uses no synchronization. Even if you assume that instances are only declared statically, the cEnumClasses map is global and can be written to when a thread triggers static initialization of B.class while some other thread is doing getEnumList(A.class). Unsynchronized access of a map undergoing mutation is not thread-safe. This isn't theoretical. We're seeing ValuedEnum.getEnum(X.class, 0) return null after returning the correct value over 100,000 times, and then return the correct value again on the next invocation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-336) Finally start using generics.
[ https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-336: --- Fix Version/s: LangTwo 1.0 Finally start using generics. - Key: LANG-336 URL: https://issues.apache.org/jira/browse/LANG-336 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.3 Reporter: Hendrik Maryns Fix For: LangTwo 1.0 Attachments: commons-lang-2.3-sources-generic.tar.gz, lang.patch It is obvious that the Jakarta project is reluctant in starting to use the 'new' (how old is it by now?) generics feature of Java. Nevertheless some other people would like to see it incorporated in the commons projects. I adapted commons Lang to usee generics. Took me about an afternoon. Would be nice if something is done with it, except for only me using it in my projects. Some stuff will have to be changed to conform to guidelines and stuff. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CLI-131) Options class returns options in random order
[ https://issues.apache.org/jira/browse/CLI-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501436 ] Henri Yandell commented on CLI-131: --- The usual JDK version worries. Can't remember if we're meant to be supporting 1.2 and 1.3. Personally; I vote 1.4. Sounds like a good improvement to me otherwise. Options class returns options in random order - Key: CLI-131 URL: https://issues.apache.org/jira/browse/CLI-131 Project: Commons CLI Issue Type: Improvement Components: CLI-1.x Affects Versions: 1.0, 1.1 Reporter: Brian Egge Priority: Minor Fix For: 1.1 Attachments: bug131.patch The help formatter auto usage returns the options in a somewhat random order. This is because the options are inserted in a HashMap, and then a copy of the collection is returned with the getOptions() method. The getOptions method should return the options in the order they were added, or in a sorted order. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (CLI-132) MissingOptionException should contain a useful error message
[ https://issues.apache.org/jira/browse/CLI-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed CLI-132. - Resolution: Fixed Applied (r544360). As it's an improvement, I wrapped the unit test into OptionsTest rather than having a separate bug test for it. MissingOptionException should contain a useful error message Key: CLI-132 URL: https://issues.apache.org/jira/browse/CLI-132 Project: Commons CLI Issue Type: Improvement Components: CLI-1.x Affects Versions: 1.0, 1.1 Reporter: Brian Egge Priority: Minor Fix For: 1.1 Attachments: bug132.patch Most exception message contain a useful message string like Missing argument for option:. The MissingOptionException contains only the missing options. Adding a message to the exception would make it easier to catch a ParseException and display the getMessage() string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CLI-131) Options class returns options in random order
[ https://issues.apache.org/jira/browse/CLI-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501442 ] Henri Yandell commented on CLI-131: --- Under 1.3, you get the following error. [junit] Exception in thread main java.lang.NoClassDefFoundError: org/w3c/dom/Node Which is a bit odd as I have xml-apis.jar in my ANT_HOME. Options class returns options in random order - Key: CLI-131 URL: https://issues.apache.org/jira/browse/CLI-131 Project: Commons CLI Issue Type: Improvement Components: CLI-1.x Affects Versions: 1.0, 1.1 Reporter: Brian Egge Priority: Minor Fix For: 1.1 Attachments: bug131.patch The help formatter auto usage returns the options in a somewhat random order. This is because the options are inserted in a HashMap, and then a copy of the collection is returned with the getOptions() method. The getOptions method should return the options in the order they were added, or in a sorted order. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-142) [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver
[ https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500254 ] Henri Yandell commented on BEANUTILS-142: - The RowSetDynaClass change still uses getObject, which on Oracle will return oracle.sql.Timestamp which extends Object. So unless the convert lookup handles oracle.sql.Timestamp as a String, it's not going to work and people will have to register their own workaround converter (which we could put on a wiki or something). [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver -- Key: BEANUTILS-142 URL: https://issues.apache.org/jira/browse/BEANUTILS-142 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Environment: Operating System: Windows XP Platform: All Reporter: Li Zhang Fix For: 1.8.0 Attachments: Beanutils-142.patch Beginning in Oracle 9.2, DATE is mapped to Date and TIMESTAMP is mapped to Timestamp. However if you were relying on DATE values to contain time information, there is a problem. When using Oracle 10g JDBC driver, the ResultSetMetaData.getColumnClassName returns java.sql.Timestamp but ResultSet.getObject(name).getClass() returns java.sql.Date. Obviously these two do not match each other. When the RowSetDynaClass.copy function tries to set the value to BasicDynaBean, it throws exception. Need a workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (CLI-130) Remove the Commons Lang dependency
Remove the Commons Lang dependency -- Key: CLI-130 URL: https://issues.apache.org/jira/browse/CLI-130 Project: Commons CLI Issue Type: Task Components: CLI-1.x Affects Versions: 1.0 Reporter: Henri Yandell Fix For: 1.1 The dependency is only there for the NumberUtils usage in TypeHandler. It should be possible to inline the necessary part of that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (CLI-130) Remove the Commons Lang dependency
[ https://issues.apache.org/jira/browse/CLI-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed CLI-130. - Resolution: Fixed svn ci -m Removing the Commons Lang dependency. This removes certain obscure number formats as being parseable by the PatternOptionBuilder, but I suspect they don't matter. project.xml src/ Sendingproject.xml Sendingsrc/java/org/apache/commons/cli/PatternOptionBuilder.java Sendingsrc/java/org/apache/commons/cli/TypeHandler.java Sendingsrc/test/org/apache/commons/cli/PatternOptionBuilderTest.java Transmitting file data Committed revision 542140. Remove the Commons Lang dependency -- Key: CLI-130 URL: https://issues.apache.org/jira/browse/CLI-130 Project: Commons CLI Issue Type: Task Components: CLI-1.x Affects Versions: 1.0 Reporter: Henri Yandell Fix For: 1.1 The dependency is only there for the NumberUtils usage in TypeHandler. It should be possible to inline the necessary part of that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-334) Enum is not thread-safe
[ https://issues.apache.org/jira/browse/LANG-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-334: --- Fix Version/s: 2.3.1 Fix for 2.3.1. First step, write a test. Enum is not thread-safe --- Key: LANG-334 URL: https://issues.apache.org/jira/browse/LANG-334 Project: Commons Lang Issue Type: Bug Reporter: Michael Sclafani Fix For: 2.3.1 Enum uses no synchronization. Even if you assume that instances are only declared statically, the cEnumClasses map is global and can be written to when a thread triggers static initialization of B.class while some other thread is doing getEnumList(A.class). Unsynchronized access of a map undergoing mutation is not thread-safe. This isn't theoretical. We're seeing ValuedEnum.getEnum(X.class, 0) return null after returning the correct value over 100,000 times, and then return the correct value again on the next invocation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LANG-331) Fix for LANG-259 broke ValuedEnum.compareTo() on subclassed enumerations
[ https://issues.apache.org/jira/browse/LANG-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-331: --- Fix Version/s: 2.3.1 Discuss what to do for this as a part of a 2.3.1. Fix for LANG-259 broke ValuedEnum.compareTo() on subclassed enumerations Key: LANG-331 URL: https://issues.apache.org/jira/browse/LANG-331 Project: Commons Lang Issue Type: Bug Reporter: Michael Sclafani Fix For: 2.3.1 I have a ValuedEnum abstract subclass that I further subclass to attach useful implementation behaviors. The base class overrides getEnumClass(). The fix for LANG-259 broke compareTo() since it compares getClass(), not getEnumClass(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-59) [beanutils] Memory leak on webapp undeploy in WrapDynaClass
[ https://issues.apache.org/jira/browse/BEANUTILS-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499397 ] Henri Yandell commented on BEANUTILS-59: Sounds good to me. [beanutils] Memory leak on webapp undeploy in WrapDynaClass --- Key: BEANUTILS-59 URL: https://issues.apache.org/jira/browse/BEANUTILS-59 Project: Commons BeanUtils Issue Type: Bug Components: DynaBean Affects Versions: 1.6 Environment: Operating System: All Platform: All Reporter: Simon Kitching Fix For: 1.8.0 Attachments: beanutils-59.patch Class WrapDynaClass has a HashMap dynaClasses containing a mapping from Class to WrapDynaClass. If this class were to be deployed via a shared webapp, then any reference in there to a class loaded via the webapp classloader will prevent the webapp classloader from being garbage-collected when the webapp is undeployed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (DIGESTER-113) Can sources attachment for Digester 1.8 be uploaded to Maven repo on ibiblio?
[ https://issues.apache.org/jira/browse/DIGESTER-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499336 ] Henri Yandell commented on DIGESTER-113: Both source and javadoc deployed to http://people.apache.org/repo/m1-ibiblio-rsync-repository/commons-digester/jars/. I'll give it a little bit and check central to make sure they moved over there properly. Can sources attachment for Digester 1.8 be uploaded to Maven repo on ibiblio? - Key: DIGESTER-113 URL: https://issues.apache.org/jira/browse/DIGESTER-113 Project: Commons Digester Issue Type: Wish Affects Versions: 1.8 Reporter: Matt Whitlock Assigned To: Henri Yandell Priority: Minor Please see http://jira.codehaus.org/browse/MAVENUPLOAD-1521 . I am supposed to ask if you will allow http://www.mattwhitlock.com/commons-digester-1.8-sources.jar to be uploaded to the Maven central repository on ibiblio as the source attachment for the commons-digester:commons-digester:1.8:jar artifact. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (LOGGING-113) pom.xml in maven repository does not list dependencies as optional
[ https://issues.apache.org/jira/browse/LOGGING-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LOGGING-113. - Resolution: Fixed Fix Version/s: 1.1.1 This has been fixed in HEAD (the version that has been published is not allowed to be edited). Just a question of a 1.1.1 release being made - c-logging releases seem pretty painful to do and no one is volunteering currently. pom.xml in maven repository does not list dependencies as optional -- Key: LOGGING-113 URL: https://issues.apache.org/jira/browse/LOGGING-113 Project: Commons Logging Issue Type: Improvement Affects Versions: 1.1.0 Environment: maven 2 Reporter: Max Berger Priority: Minor Fix For: 1.1.1 Dear Commons Logging Developers, I don't know if this is the right place, but I have a problem with the maven 2 artifact for commons-logging, available at: ftp://ibiblio.org/pub/packages/maven2/commons-logging/commons-logging/1.1/ ftp://ibiblio.org/pub/packages/maven2/commons-logging/commons-logging/1.1/commons-logging-1.1.pom The pom lists avalon-framework, servlet-api, junit, log4j, logkit as REQUIRED dependencies, while instead they should be optional dependencies. How to fix: add optionaltrue/optional to all dependencies that are optional, e.g. dependency groupIdlog4j/groupId artifactIdlog4j/artifactId version1.2.12/version optionaltrue/optional /dependency Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (CLI-71) [cli] A weakness of parser
[
https://issues.apache.org/jira/browse/CLI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498526
]
Henri Yandell commented on CLI-71:
--
Another option, which is relatively similar, is to clear the values list before
each parse. It breaks much the same other tests.
The tests that break are the ones where a parser parses the same option
multiple times. ie) My clearing out of the undesirably persistant data is too
deep, it needs to be higher.
[cli] A weakness of parser
--
Key: CLI-71
URL: https://issues.apache.org/jira/browse/CLI-71
Project: Commons CLI
Issue Type: Bug
Components: CLI-1.x
Environment: Operating System: other
Platform: All
Reporter: Amro Al-Akkad
Fix For: 1.1
Attachments: BugCLI71Test.java, BugCLI71Test.java,
CLI-71-badfix.patch, TestCommonsCLI.java
I found a weakness of Jakarta Commons CLI and want to explain it with a simple
example:
Our program provides 2 options:
1.-a or --algo name: The -a option requires an argument.
2.-k or --key value: The -k option requires an argument too.
a)
If you pass the following command line arguments everything will be ok:
-a Caesar -k A
After evaluation:
• Caesar is the parameter of the -a option and
• A is the parameter of the -k option.
b)
However an org.apache.commons.cli.MissingArgumentException: no argument for:k
is
thrown if you pass the following input:
-a Caesar -k a
The Parser assumes that the argument a after the -k option, is the -a option
missing the hyphen. At the end of this description there is Java code for
executing this problem.
Information:
The handling of this command line
-a Caesar -k a
works in Getopt without any problem:
• Caesar is the parameter of the -a option and
• a of the -k option.
After parsing a valid option Getopt always takes the next (available) command
line argument as the option's parameter if the option requires an argument -
means if you pass to the command line
-k -a Caesar
After evaluation:
• a is the parameter of the -k option
• the Caesar argument is just ignored
If the option's parameter (value) represents an optional argument the next
argument is not required, if it represents a valid option - means if you pass
to
the command line
-k -a Caesar
After evaluation:
• Caesar is the parameter of the -a option
• k option is set without a parameter - in this case a default value
makes sense.
Last but not least here is the code snippet for the CLI Test:
import org.apache.commons.cli.CommandLine;
import org.apache.commons.cli.CommandLineParser;
import org.apache.commons.cli.Option;
import org.apache.commons.cli.Options;
import org.apache.commons.cli.ParseException;
import org.apache.commons.cli.PosixParser;
public class TestCommonsCLI {
/**
* @param args
*/
public static void main(String[] args) {
Options options = new Options();
Option algorithm = new Option(a , algo, true, the
algorithm which it to
perform executing);
algorithm.setArgName(algorithm name);
options.addOption(algorithm);
Option key = new Option(k , key, true, the key the setted
algorithm uses
to process);
algorithm.setArgName(value);
options.addOption(key);
CommandLineParser parser = new PosixParser();
try {
CommandLine line = parser.parse( options, args);
if(line.hasOption('a')){
System.out.println(algo: + line.getOptionValue( a
));
}
if(line.hasOption('k')){
System.out.println(key: + line.getOptionValue('k'));
}
} catch (ParseException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CLI-71) [cli] A weakness of parser
[
https://issues.apache.org/jira/browse/CLI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated CLI-71:
-
Attachment: CLI-71-fix.patch
Attaching a fix for this issue. It clears the Option classes in the Options
class before parsing.
Opinions are very much desired, I'm not sure what side-effects this might have;
it seems to me that it is not an intended API to be able to say:
options.getOption(a).getValues()
rather than going via the CommandLine; so I don't think there is anything bad
with this.
Leaving open for the moment.
[cli] A weakness of parser
--
Key: CLI-71
URL: https://issues.apache.org/jira/browse/CLI-71
Project: Commons CLI
Issue Type: Bug
Components: CLI-1.x
Environment: Operating System: other
Platform: All
Reporter: Amro Al-Akkad
Fix For: 1.1
Attachments: BugCLI71Test.java, BugCLI71Test.java,
CLI-71-badfix.patch, CLI-71-fix.patch, TestCommonsCLI.java
I found a weakness of Jakarta Commons CLI and want to explain it with a simple
example:
Our program provides 2 options:
1.-a or --algo name: The -a option requires an argument.
2.-k or --key value: The -k option requires an argument too.
a)
If you pass the following command line arguments everything will be ok:
-a Caesar -k A
After evaluation:
• Caesar is the parameter of the -a option and
• A is the parameter of the -k option.
b)
However an org.apache.commons.cli.MissingArgumentException: no argument for:k
is
thrown if you pass the following input:
-a Caesar -k a
The Parser assumes that the argument a after the -k option, is the -a option
missing the hyphen. At the end of this description there is Java code for
executing this problem.
Information:
The handling of this command line
-a Caesar -k a
works in Getopt without any problem:
• Caesar is the parameter of the -a option and
• a of the -k option.
After parsing a valid option Getopt always takes the next (available) command
line argument as the option's parameter if the option requires an argument -
means if you pass to the command line
-k -a Caesar
After evaluation:
• a is the parameter of the -k option
• the Caesar argument is just ignored
If the option's parameter (value) represents an optional argument the next
argument is not required, if it represents a valid option - means if you pass
to
the command line
-k -a Caesar
After evaluation:
• Caesar is the parameter of the -a option
• k option is set without a parameter - in this case a default value
makes sense.
Last but not least here is the code snippet for the CLI Test:
import org.apache.commons.cli.CommandLine;
import org.apache.commons.cli.CommandLineParser;
import org.apache.commons.cli.Option;
import org.apache.commons.cli.Options;
import org.apache.commons.cli.ParseException;
import org.apache.commons.cli.PosixParser;
public class TestCommonsCLI {
/**
* @param args
*/
public static void main(String[] args) {
Options options = new Options();
Option algorithm = new Option(a , algo, true, the
algorithm which it to
perform executing);
algorithm.setArgName(algorithm name);
options.addOption(algorithm);
Option key = new Option(k , key, true, the key the setted
algorithm uses
to process);
algorithm.setArgName(value);
options.addOption(key);
CommandLineParser parser = new PosixParser();
try {
CommandLine line = parser.parse( options, args);
if(line.hasOption('a')){
System.out.println(algo: + line.getOptionValue( a
));
}
if(line.hasOption('k')){
System.out.println(key: + line.getOptionValue('k'));
}
} catch (ParseException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (DBCP-224) Null delegate possible
[ https://issues.apache.org/jira/browse/DBCP-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed DBCP-224. -- Resolution: Duplicate Thanks for the report Anatoliy. I'm closing this in favour of the slightly newer DBCP-225 as they appear to be the same issue and that issue has more information. Null delegate possible -- Key: DBCP-224 URL: https://issues.apache.org/jira/browse/DBCP-224 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Reporter: Anatoliy Salistra java.lang.NullPointerException at org.apache.commons.dbcp.DelegatingConnection.setAutoCommit(DelegatingConnection.java:268) at org.apache.commons.dbcp.PoolableConnectionFactory.activateObject(PoolableConnectionFactory.java:368) at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:786) at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95) at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540) at com.gfigroup.fmk.spine.db.NamedDBCPDataSource.getConnection(NamedDBCPDataSource.java:123) at com.gfigroup.fmk.spine.tx.TransactionContext.createConnection(TransactionContext.java:99) at com.gfigroup.fmk.spine.tx.TransactionContext.getConnection(TransactionContext.java:75) at com.gfigroup.fmk.spine.tx.TransactionContext.getConnectionFacility(TransactionContext.java:91) at com.gfigroup.fmk.spine.tx.AbstractTxObject.getConnectionFacility(AbstractTxObject.java:47) at com.gfigroup.ts.credit.service.feed.btc.BTCTradeTxObjectImpl.insertTrade(BTCTradeTxObjectImpl.java:104) at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.gfigroup.fmk.spine.tx.TxObjectService$TxObjectStub.invoke(TxObjectService.java:319) at $Proxy15.insertTrade(Unknown Source) at com.gfigroup.ts.credit.service.feed.btc.BTCListenerService.handleTrade(BTCListenerService.java:323) at com.gfigroup.ts.credit.service.feed.btc.BTCListenerService.handleTradeMessage(BTCListenerService.java:308) at com.gfigroup.ts.credit.service.feed.btc.BTCListenerService.access$800(BTCListenerService.java:37) at com.gfigroup.ts.credit.service.feed.btc.BTCListenerService$ProcessTradeMessageTask.run(BTCListenerService.java:512) at edu.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:88) at java.lang.Thread.run(Unknown Source) This happens intermittently and very mysteriously. Eventually our pool becomes clogged with undead connections like this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-336) Finally start using generics.
[ https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498737 ] Henri Yandell commented on LANG-336: Check out: http://svn.apache.org/repos/asf/jakarta/commons/proper/lang/branches/LangTwo-1.x/ It's an experimental version of Lang that is intended to be 1.5+ (or maybe 1.6+ if there's cause). Currently it's not generified, so any help there would be much appreciated. Your work from above should map pretty easily over, all I've done so far is to cull the deprecated packages and methods. Your patch didn't work btw. Finally start using generics. - Key: LANG-336 URL: https://issues.apache.org/jira/browse/LANG-336 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.3 Reporter: Hendrik Maryns Attachments: commons-lang-2.3-sources-generic.tar.gz, lang.patch It is obvious that the Jakarta project is reluctant in starting to use the 'new' (how old is it by now?) generics feature of Java. Nevertheless some other people would like to see it incorporated in the commons projects. I adapted commons Lang to usee generics. Took me about an afternoon. Would be nice if something is done with it, except for only me using it in my projects. Some stuff will have to be changed to conform to guidelines and stuff. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-336) Finally start using generics.
[
https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498754
]
Henri Yandell commented on LANG-336:
I wonder if this kind of method can be legal...
public ObjectT[] foo(T ... t) {
}
Must play.
Btw, don't just blindly generify things, rethink APIs if it makes sense. We do
need to keep a lot of our primitive stuff in NumberUtils etc; I imagine there's
enough of a performance loss in autoboxing to make us not want to blindly use
that in many places.
Finally start using generics.
-
Key: LANG-336
URL: https://issues.apache.org/jira/browse/LANG-336
Project: Commons Lang
Issue Type: Improvement
Affects Versions: 2.3
Reporter: Hendrik Maryns
Attachments: commons-lang-2.3-sources-generic.tar.gz, lang.patch
It is obvious that the Jakarta project is reluctant in starting to use the
'new' (how old is it by now?) generics feature of Java. Nevertheless some
other people would like to see it incorporated in the commons projects.
I adapted commons Lang to usee generics. Took me about an afternoon. Would
be nice if something is done with it, except for only me using it in my
projects.
Some stuff will have to be changed to conform to guidelines and stuff.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LANG-336) Finally start using generics.
[ https://issues.apache.org/jira/browse/LANG-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498791 ] Henri Yandell commented on LANG-336: Rethinks I suspect I went too far. Here's my thought process: * We should add varargs to some of our XxxUtils methods. * We need closures, so we don't have T[] versions of T methods that just loop over the T[] and implement. * How do varargs and Object[] work. Need to play. * That got me into thinking the above :) Varargs seem a bit lame in that we don't have tuple returns. So you can't do: public String... capitalize(String ... input); Not that that would make for nice programming. The LHS would be evil. So first question to work out is... what parts of Lang would benefit from varargs. Seems that it'll only be ones that return void, or where the return type is an aggregation of the input and not a 1:1 mapping. Whether things need generifying would then follow from there. Finally start using generics. - Key: LANG-336 URL: https://issues.apache.org/jira/browse/LANG-336 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.3 Reporter: Hendrik Maryns Attachments: commons-lang-2.3-sources-generic.tar.gz, lang.patch It is obvious that the Jakarta project is reluctant in starting to use the 'new' (how old is it by now?) generics feature of Java. Nevertheless some other people would like to see it incorporated in the commons projects. I adapted commons Lang to usee generics. Took me about an afternoon. Would be nice if something is done with it, except for only me using it in my projects. Some stuff will have to be changed to conform to guidelines and stuff. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
