from:"Henri Yandell"


[ 
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

2007-07-17 Thread Henri Yandell (JIRA)

[
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]

Re: [BeanUtils] Progressing towards a 1.8.0 release

2007-07-17 Thread Henri Yandell


On 7/14/07, Stephen Colebourne [EMAIL PROTECTED] wrote:

Henri Yandell wrote:
 One area for discussion is the split between the optional Collections
 component and the 'Core' beanutils. Do we maintain that, or should we
 just fold the code back together?

 1.7.0 shipped three versions:

 commons-beanutils-1.7.0.jar
 commons-beanutils-core-1.7.0.jar
 commons-beanutils-collections-1.7.0.jar

 where the first is the sum of the second and third.

 Personally I think we should just merge them back together. It's not
 worth the effort.

The purpose is to avoid forcing users to take dependencies that they are
not interested in, [collections] in this case. As such I think that the
split is a Good Thing.


Main problems with this are that we didn't do that. We kept a merged
version for the normal beanutils jars, and released a couple of lesser
jars that are probably not used.

Given that BeanUtils is looking pretty old and tired, I'm not sure its
users really want to discover classes missing when next they upgrade
the beanutils jar. In which case, we're just wasting effort by having
a separate pair of jars.

My view is that we have the following options:

1) Merge em back in and just release the 1 jar.
2) Split them; do not release a beanutils.jar (or if we do, it's
beanutils-core renamed) and setup beanutils-collections as a separate
component in Commons or as a child of beanutils with core as an
equivalent child (ie: Maven2 multiproject).

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (BEANUTILS-92) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException

2007-07-17 Thread Henri Yandell (JIRA)

[
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
-

Attachments: Beanutils-92-updated.patch, fixCopyPropertyException,
Jira92TestCase.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] Commented: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate

2007-07-17 Thread Henri Yandell (JIRA)


[ 
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]

Re: [BeanUtils] Progressing towards a 1.8.0 release

2007-07-17 Thread Henri Yandell


On 7/11/07, Niall Pemberton [EMAIL PROTECTED] wrote:

BeanUtils is getting close to being ready for a 1.8.0 release IMO
(under 10 issues left targeted for 1.8.0).

  http://issues.apache.org/jira/browse/BEANUTILS

One thought I had was to do a 1.8.0 Beta release first to (hopefully)
get wider testing - thoughts/opinions on that welcome.


On a different note (to the jar stuff), what do people think to
cleaning up the JUnit tests?

Currently they all define a constructor, a setup, a teardown, a main
and a suite. None of those are needed (unless there's actually code in
the setup/teardown), so I'd like to tidy the code up by stripping them
out.

Any thoughts?

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [BeanUtils] Progressing towards a 1.8.0 release

2007-07-17 Thread Henri Yandell


On 7/17/07, Niall Pemberton [EMAIL PROTECTED] wrote:

On 7/17/07, Niall Pemberton [EMAIL PROTECTED] wrote:
 On 7/17/07, Henri Yandell [EMAIL PROTECTED] wrote:



  My view is that we have the following options:
 
  1) Merge em back in and just release the 1 jar.
  2) Split them; do not release a beanutils.jar (or if we do, it's
  beanutils-core renamed) and setup beanutils-collections as a separate
  component in Commons or as a child of beanutils with core as an
  equivalent child (ie: Maven2 multiproject).

 I don't want to do a maven multi-project - but I also don't see whats
 wrong with releasing the three jars as they were last time - as I said
 eariler in this thread - merge in the bean-collections sub-project,
 but use an assembly to re-create the core and bean-collections jars.
 As attached artifacts then people would have the option to depend on
 those if they so desired (as my understanding of maven goes).

Assemblies work except you only get a default manifest - not sure
where I got the attachment idea from, can't find any reference to that
- so I think we should keep it simple and stick to option #1


That has my +1 [obviously]. I think we should keep it simple.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[beanutils] Release plan for a beta

2007-07-17 Thread Henri Yandell


So, with a mind to getting a beta out pretty soon, here's what it
looks like to me:

1] Close BEANUTILS-91
2] Fold the separate optional source back into the main codeline.
3] Check binary compatibility, close BEANUTILS-280
4] Tag as 1.8.0-beta1
5] Create a distribution from the tag using Maven2.
6] Update the site to mention the 1.8.0-beta-1; and if 2] happens, to
update the relevant text.

One question is just what we distribute. It needs to at least be
source, which means a tar.gz. We need a jar for ease of use (ie: maven
repo); so I suspect we'll just end up doing a normal distribution.

Outstanding questions:

1) Fold optional source back in?
2) Get rid of JUnit cruft that nothing is using?
3) Remove Maven1 build?

Thoughts?

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dbcp][pool] Performance / load tests

2007-07-16 Thread Henri Yandell


On 7/15/07, Phil Steitz [EMAIL PROTECTED] wrote:

I have cleaned up some of my performance / load test code for [dbcp]
and [pool] and would like to commit it somewhere so others can use and
improve it.  There is some common load generation code that should be
factored out and I don't want to clutter the component codebases, so I
am hesitant to commit to either pool or dbcp trunk.

Any objections to my starting a [performance] sandbox component and
seeding it with [dbcp] and [pool] performance tests?  Any better ideas
on where to put this code?


+1 on putting it in as a component in sandbox.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [BeanUtils] Progressing towards a 1.8.0 release

2007-07-14 Thread Henri Yandell


One area for discussion is the split between the optional Collections
component and the 'Core' beanutils. Do we maintain that, or should we
just fold the code back together?

1.7.0 shipped three versions:

commons-beanutils-1.7.0.jar
commons-beanutils-core-1.7.0.jar
commons-beanutils-collections-1.7.0.jar

where the first is the sum of the second and third.

Personally I think we should just merge them back together. It's not
worth the effort.

Hen

On 7/11/07, Niall Pemberton [EMAIL PROTECTED] wrote:

BeanUtils is getting close to being ready for a 1.8.0 release IMO
(under 10 issues left targeted for 1.8.0).

  http://issues.apache.org/jira/browse/BEANUTILS

One thought I had was to do a 1.8.0 Beta release first to (hopefully)
get wider testing - thoughts/opinions on that welcome.

Niall

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven2 snapshot repo?

2007-07-14 Thread Henri Yandell


On 7/13/07, Dennis Lundberg [EMAIL PROTECTED] wrote:

Dain Sundstrom wrote:
 Are snapshot jars for commons (specifically commons-dbcp) published
 anywhere?  I expected to see them here
 http://people.apache.org/repo/m2-snapshot-repository/

Almost none of the commons components use Maven 2 to build or publish
their jar-files. So you won't find many commons-snapshots in the
directory you mention.

There is however a nightly-build script that runs and creates
snapshots of all commons components, using their preferred build
system (Ant, Maven 1 or Maven 2). You can find the artifacts it produces
here:

   http://vmbuild.apache.org/~commons/nightly/builds/


Or as a legacy maven-1 repository:

http://vmbuild.apache.org/~commons/nightly/maven/

The aim being to get them back into
http://people.apache.org/repo/m1-snapshot-repository/ at some point.

Hen

-
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

2007-07-13 Thread Henri Yandell (JIRA)


[ 
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

2007-07-13 Thread Henri Yandell (JIRA)

[
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

2007-07-13 Thread Henri Yandell (JIRA)

[
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
--

Attachments: beanutils-142-oracle-bug.patch, Beanutils-142.patch,
Play.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] 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

2007-07-11 Thread Henri Yandell (JIRA)


[ 
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

2007-07-10 Thread Henri Yandell (JIRA)

[
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]

Re: New M2 snapshots use org.apache.commons?

2007-07-10 Thread Henri Yandell


On 7/9/07, Wendy Smoak [EMAIL PROTECTED] wrote:

On 7/9/07, Paul Benedict [EMAIL PROTECTED] wrote:

 For development of new releases, should the commons-* folders be forgone
 and use org.apache.commons now?

Check the list archives for some past discussion... it has to be
handled carefully with old releases relocated in the central
repository, or downstream users will be adversely affected.

Nabble turns up a few relevant posts:
http://www.nabble.com/forum/Search.jtp?forum=317local=yquery=commons+maven+groupid


Yeah, my view is that Maven need a better system :) I keep meaning to
dig into the code of how to do such a thing.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: New M2 snapshots use org.apache.commons?

2007-07-10 Thread Henri Yandell


The core issue is one of transitive dependencies clashes.

For example, I had a problem the other day with the antrun plugin
which depends on ant.ant-1.6.5, and we had a dependency of ant-trax
(1.7.0), which depends on org.apache.ant.ant-1.7.0. Those aren't the
same project, so Maven couldn't yell at us for having a clashing
dependency. Not that I know if the plugin system would have warned me
of the clash, it was a fun bug :)

With something as low as Commons, this transitive dependency clash is
really, really valuable.

Hen

On 7/10/07, Paul Benedict [EMAIL PROTECTED] wrote:

Because it has already been discussed, I might as well throw in my two
cents.

Whatever direction commons decides to take, it's worth acknowledging
that more than a few popular Apache projects moved to
org.apache.whatever.* without relocating their previous releases. They
broke with the Maven 1 conventions and released new versions under the
naming conventions for Maven 2. Because developers must modify their POM
to update the version number anyway, editing the groupId is a trivial
additive.

Paul

Henri Yandell wrote:
 On 7/9/07, Wendy Smoak [EMAIL PROTECTED] wrote:
 On 7/9/07, Paul Benedict [EMAIL PROTECTED] wrote:

  For development of new releases, should the commons-* folders be
 forgone
  and use org.apache.commons now?

 Check the list archives for some past discussion... it has to be
 handled carefully with old releases relocated in the central
 repository, or downstream users will be adversely affected.

 Nabble turns up a few relevant posts:
 
http://www.nabble.com/forum/Search.jtp?forum=317local=yquery=commons+maven+groupid


 Yeah, my view is that Maven need a better system :) I keep meaning to
 dig into the code of how to do such a thing.

 Hen

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[RESULT] Release CLI 1.1 (3rd RC)

2007-07-08 Thread Henri Yandell


Binding +1s from:

Henri Yandell
Dion Gillard
Jörg Schaible
Phil Steitz
Rahul Alkolkar

and +1s from the barely different RC2:

Torsten Curdt
Oliver Heger


I'll go ahead and make the release, thanks for all the feedback and help.

Hen

On 7/4/07, Henri Yandell [EMAIL PROTECTED] wrote:

I've updated the release notes to match the website page:

http://people.apache.org/~bayard/commons-cli/1.0-rc3/

with the site in:

http://people.apache.org/~bayard/commons-cli/1.0-rc3/site/

One quirk to note. The site is from trunk while the release is from
the 1.0.x branch.

[ ] +1, before 6 years since 1.0 arrives
[ ] -1, we can make 6 years

---

The only changes to svn are Rahul's NOTICE fix for our TLP change and
my updating the RELEASE-NOTES.txt with the latest information. So I
plan to consider any existing +1s for the RC2 as applying to this (ie:
Don't revote unless you want to).

Hen



-
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

2007-07-08 Thread Henri Yandell (JIRA)


 [ 
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]

Re: [proposal] No VOTE needed to elect ASF committers to commons WAS: Re: request karma to commons validator/i18n

2007-07-07 Thread Henri Yandell


On 7/6/07, Phil Steitz [EMAIL PROTECTED] wrote:


So my proposal is that any ASF committer who wishes to become a
commons committer just needs to make that request here on the
commons-dev mailing list and they will granted karma for both commons
proper and commons sandbox.  Expectation is of course that ASF
committers joining the commons will behave
(http://wiki.apache.org/jakarta-commons/JakartaCommonsEtiquette).


Obviously I'm +1 on making it easier. As far as behaving - the
solution is that the quiet majority have to step up and yell if
someone is being a rude .

We've a bit of a technical issue on it; it's quite easy to show up and
if a component is in a lull, to charge in and make sweeping changes.
The release is a point where we can nip that in the bud, but that's a
long time after lots of work.

So I think something I would be looking for when someone wants to hop
in is that there is an active commons committer managing the component
they're about to commit to. Other than that, I believe in as open a
door as possible.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: request karma to commons validator/i18n

2007-07-06 Thread Henri Yandell


Done.

On 7/6/07, Phil Steitz [EMAIL PROTECTED] wrote:

Can someone with karma karma pls set Paul up?

It would be great to get i18n promoted to proper and released.  Any
other volunteers to help with this?

Phil

On 7/5/07, Paul Benedict [EMAIL PROTECTED] wrote:
 I would like to commit to commons validator and commons i18n to enhance
 them for Struts. For validator, I want to add and finish some issues in
 the current snapshot, and, respectively, port some good i18n code from
 other Apache projects. Can I get karma for this?

 Thanks,
 Paul

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release CLI 1.1 (3rd RC)

2007-07-06 Thread Henri Yandell


I'm +1 btw :)

Hen

On 7/4/07, Henri Yandell [EMAIL PROTECTED] wrote:

I've updated the release notes to match the website page:

http://people.apache.org/~bayard/commons-cli/1.0-rc3/

with the site in:

http://people.apache.org/~bayard/commons-cli/1.0-rc3/site/

One quirk to note. The site is from trunk while the release is from
the 1.0.x branch.

[ ] +1, before 6 years since 1.0 arrives
[ ] -1, we can make 6 years

---

The only changes to svn are Rahul's NOTICE fix for our TLP change and
my updating the RELEASE-NOTES.txt with the latest information. So I
plan to consider any existing +1s for the RC2 as applying to this (ie:
Don't revote unless you want to).

Hen



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: request karma to commons validator/i18n

2007-07-06 Thread Henri Yandell


On 7/6/07, Niall Pemberton [EMAIL PROTECTED] wrote:

On 7/6/07, Paul Benedict [EMAIL PROTECTED] wrote:
 I would like to commit to commons validator and commons i18n to enhance
 them for Struts. For validator, I want to add and finish some issues in
 the current snapshot, and, respectively, port some good i18n code from
 other Apache projects. Can I get karma for this?

Although Commons has a liberal policy on giving Karma to ASF
committers a better (more ASF like) first step IMO would have been to
start talking about what you want to do first - a good recent example
of that is Dain:

http://tinyurl.com/yrmgpf

Even though I'm already a committer I still regularly create Jira
tickets and post patches (for code changes) to components that I don't
have much history on rather than diving straight in.  I'm hoping
you'll do the same, 'coz I'm going to be unhappy if I start seeing
Validator commits with no prior discussion.


Ack - Martin just pointed out that it's Sandbox karma on request, not
all of Commons.

I'll adjust - ie: Paul will have commit for i18n, but we'll have to
vote to give him commit to validator.

Hen

-
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

2007-07-05 Thread Henri Yandell (JIRA)


 [ 
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]

[VOTE] Release CLI 1.1 (3rd RC)

2007-07-04 Thread Henri Yandell


I've updated the release notes to match the website page:

http://people.apache.org/~bayard/commons-cli/1.0-rc3/

with the site in:

http://people.apache.org/~bayard/commons-cli/1.0-rc3/site/

One quirk to note. The site is from trunk while the release is from
the 1.0.x branch.

[ ] +1, before 6 years since 1.0 arrives
[ ] -1, we can make 6 years

---

The only changes to svn are Rahul's NOTICE fix for our TLP change and
my updating the RELEASE-NOTES.txt with the latest information. So I
plan to consider any existing +1s for the RC2 as applying to this (ie:
Don't revote unless you want to).

Hen

-
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

2007-07-03 Thread Henri Yandell (JIRA)


 [ 
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

2007-07-03 Thread Henri Yandell (JIRA)


[ 
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

2007-07-03 Thread Henri Yandell (JIRA)


[ 
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]

Re: [VOTE] Release CLI 1.1 (RC2)

2007-07-01 Thread Henri Yandell


On 7/1/07, Oliver Heger [EMAIL PROTECTED] wrote:

+1 from me.

Some minor remarks:

- When building with maven, in the manifest of the resulting jar some
entries are duplicated with different values.


I get:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.5.3
Created-By: Apache Maven
Built-By: hen
Package: org.apache.commons
Build-Jdk: 1.4.2_12
Extension-Name: commons-cli
Specification-Title: Jakarta Commons CLI
Specification-Vendor: Apache Software Foundation
Implementation-Title: Jakarta Commons CLI
Implementation-Vendor: Apache Software Foundation
Implementation-Version: 1.1
Implementation-Vendor-Id: org.apache
X-Compile-Source-JDK: 1.3
X-Compile-Target-JDK: 1.3
Specification-Version: 1.1


- When building with ant the resulting jar does not contain LICENSE and
the manifest is pretty poor.


Not too bothered.


A question about the release notes: Are they in line with the clirr
report? They talk about some binary incompatibilities, but the report is
clean.


Curses. I updated the release notes in the site, but not the text
file. Guess I need to do an RC3.

Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release CLI 1.1 (RC2)

2007-07-01 Thread Henri Yandell


On 7/1/07, Torsten Curdt [EMAIL PROTECTED] wrote:

+1 from me

Would be nice to have more keys in the KEYS file though.


Thinking about it - don't even need the KEYS file anymore. We merged
all the Commons ones together. So now testing should involve getting
the central KEYS file and making sure the RM has their key in there.

Hen

-
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()

2007-06-30 Thread Henri Yandell (JIRA)


 [ 
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]

[VOTE] Release CLI 1.1 (RC2)

2007-06-30 Thread Henri Yandell


I believe the RC1 issues have been taken care of, so here goes with a
second try:

http://people.apache.org/~bayard/commons-cli/1.0-rc2/

with the site in:

http://people.apache.org/~bayard/commons-cli/1.0-rc2/site/

One quirk to note. The site is from trunk while the release is from
the 1.0.x branch.

[ ] +1, before 6 years since 1.0 arrives
[ ] -1, we can make 6 years


Hen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (COLLECTIONS-3) NPE: map.LRUMap.reuseMapping(LRUMap.java:272)

2007-06-30 Thread Henri Yandell (JIRA)


[ 
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]

Re: [cli] Fixing backwards compatabilities

2007-06-29 Thread Henri Yandell


On 6/13/07, Henri Yandell [EMAIL PROTECTED] wrote:

4 items to fix:


1) Make the fields in HelpFormatter public.   DONE.

2) Make the Option class cloneable again. See:
https://issues.apache.org/jira/browse/CLI-21


Brian had a nice patch adding clone(), but he did it the right way
(protected :) ), and that still fails backwards compat. So I've
modified his change to make the clone method public, and I catch the
CloneNotSupportedException and throw a RuntimeException.

Clirr didn't seem to care that a checked exception was being added to
a method. I'm not sure what would happen in that case without testing
- anyone know? Is it fine to add a checked exception without having to
consider it non-backwards compat?


3) Deal with the public boolean addValue-package private void addValue.

Current thinking is to move the new one to a new name and have the old
method throw an UnsupportedOperationException.


Done. New method is addValueForProcessing. The old method throws an
UnsupportedOperationException.

I see little point for this change and am only making it so clirr will
look pretty - if that's what is needed for a release. Is there any
difference between a NoSuchMethodError and an
UnsupportedOperationException at runtime? The short explanatory text
in the UOE is all I can think of.


4) Deal with the new methods on the CommandLineParser interface. I'm
tempted to just delete them from the interface and leave them on the
abstract Parser class. Thoughts?


Removed from the interface. Still in the abstract class.

Clirr is now a happy little camper, as is jardiff which only points
out that various bits have been deprecated.

Before I call a vote, it'd be good to know if these ugly soul
destroying hacks pass muster or not with the backwards compat view.
Any opinions?

Hen

-
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