from:"Niall Pemberton"

Merge Bean-Collections back into core BeanUtils and remove Bean-Collections 
sub-project
---

 Key: BEANUTILS-290
 URL: https://issues.apache.org/jira/browse/BEANUTILS-290
 Project: Commons BeanUtils
  Issue Type: Task
  Components: Bean-Collections
Affects Versions: 1.7.0
Reporter: Niall Pemberton
Assignee: Niall Pemberton
Priority: Minor
 Fix For: 1.8.0


This issue has been discussed in the following thread: http://tinyurl.com/2xdpku

For BeanUtils 1.7.0 the following classes which had a dependency on Commons 
Collections were split into a separate bean-collections sub-module:
BeanComparator.java
BeanMap.java
BeanPredicate.java
BeanPropertyValueChangeClosure.java
BeanPropertyValueEqualsPredicate.java
BeanToPropertyValueTransformer.java

Three flavours of jars were released in 1.7.0

   commons-beanutils.jar - containing all BeanUtils classes, including above 
bean-collections ones
   commons-beanutils-bean-collections.jar - containing just the above  
bean-collections classes
   commons-beanutils-core.jar - containing BeanUtils classes excluding above 
bean-collections ones

BeanUtils 1.7.0 was created using ant and (I presume) the maven poms for the 
above artifacts were manually created - unfortunately with mistakes:

1) The pom for commons-beanutils.jar DOESN'T declare any Commons Collections 
dependency (which it has for the bean-collections classes)
2) The pom for commons-beanutils-core.jar DOES declare a Commons Collections 
dependency (which it doesn't actually have)

The proposal for BeanUtils 1.8.0 (see http://tinyurl.com/2xdpku) is to merge 
the bean-collections classes back into core BeanUtils and get rid of the 
bean-collections sub-module - releasing just a single jar for BeanUtils and 
marking the Commons Collections dependency as optional in the maven pom (see 
http://tinyurl.com/2nm2bu).

-- 
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-19 Thread Niall Pemberton


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

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.


As the majority are in favour and with no-one vetoing this proposal -
I'll go ahead and do this later tonight. I created a Jira issue[1] to
document this (since they're far easier to find later down the road
than mailing list threads)

[1] https://issues.apache.org/jira/browse/BEANUTILS-290

Niall


Hen


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

Re: Commons Logging 1.1.1 - when?

2007-07-19 Thread Niall Pemberton


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

On 7/19/07, Sullivan, Sean [EMAIL PROTECTED] wrote:

 Are there plans to release Commons Logging 1.1.1?

 I am eager to see Commons Logging 1.1.1 because JCL 1.1 throws
 exceptions when running in a Java applet sandbox.  (This bug is already
 fixed:  https://issues.apache.org/jira/browse/LOGGING-106)

 The roadmap shows 4 issues that are resolved in Commons Logging 1.1.1:

Plus I seem to recall that when I was digging through it for work, I
found a significant bugfix that wasn't in JIRA.

 https://issues.apache.org/jira/browse/LOGGING?report=com.atlassian.jira.
 plugin.system.project:roadmap-panel

 Is anybody working on JCL 1.1.1?

Not afaik. I put some effort in a bit back, but the release process
was too confusing for the time I wanted to put in.


Is it worth pinging Simon or Robert (last 2 release managers) directly
for help - this may be going under their radar.

Niall


Hen


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

Re: Commons Logging 1.1.1 - when?

2007-07-19 Thread Niall Pemberton


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

On 7/19/07, Henri Yandell [EMAIL PROTECTED] wrote:
 On 7/19/07, Sullivan, Sean [EMAIL PROTECTED] wrote:
 
  Are there plans to release Commons Logging 1.1.1?
 
  I am eager to see Commons Logging 1.1.1 because JCL 1.1 throws
  exceptions when running in a Java applet sandbox.  (This bug is already
  fixed:  https://issues.apache.org/jira/browse/LOGGING-106)
 
  The roadmap shows 4 issues that are resolved in Commons Logging 1.1.1:

 Plus I seem to recall that when I was digging through it for work, I
 found a significant bugfix that wasn't in JIRA.

  https://issues.apache.org/jira/browse/LOGGING?report=com.atlassian.jira.
  plugin.system.project:roadmap-panel
 
  Is anybody working on JCL 1.1.1?

 Not afaik. I put some effort in a bit back, but the release process
 was too confusing for the time I wanted to put in.

Is it worth pinging Simon or Robert (last 2 release managers) directly
for help - this may be going under their radar.


Doh! wrong thread :(

Niall


Niall

 Hen



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

Re: [logging] Running tests on earlier JVMs

2007-07-19 Thread Niall Pemberton


Is it worth pinging Simon or Robert (last 2 release managers) directly
for help - this may be going under their radar.

Niall

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

Anyone?

Dennis Lundberg wrote:
 Hi

 I'm trying to put together an an script that will do nothing more than
 run the tests for commons logging. It's going fairly well. A couple of
 issues that I found though that I need assistance with.

 Failing test
 

 The two test files in the security package both fail. These tests were
 run using a 1.3 jvm (see below why that is).


 Testsuite: org.apache.commons.logging.security.SecurityAllowedTestCase
 Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,016 sec
 - Standard Output ---


 testing permission:class
 java.util.PropertyPermission:(java.util.PropertyPermission
 sun.net.inetaddr.ttl read)
 -  ---

 Testcase: testAllAllowed took 0,016 sec
 Caused an ERROR
 null
 java.lang.NoClassDefFoundError
 at java.lang.System.setSecurityManager0(System.java:239)
 at java.lang.System.setSecurityManager(System.java:208)
 at
 
org.apache.commons.logging.security.SecurityAllowedTestCase.tearDown(SecurityAllowedTestCase.java:77)

 at
 
org.apache.commons.logging.PathableTestSuite.runTest(PathableTestSuite.java:142)




 Testsuite: org.apache.commons.logging.security.SecurityForbiddenTestCase
 Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,015 sec

 Testcase: testAllForbidden took 0,015 sec
 Caused an ERROR
 null
 java.lang.NoClassDefFoundError
 at java.lang.System.setSecurityManager0(System.java:239)
 at java.lang.System.setSecurityManager(System.java:208)
 at
 
org.apache.commons.logging.security.SecurityForbiddenTestCase.tearDown(SecurityForbiddenTestCase.java:80)

 at
 
org.apache.commons.logging.PathableTestSuite.runTest(PathableTestSuite.java:142)




 Finding a (really old) platform to run on
 =

 We've said earlier that we should ideally run the tests using a 1.2 jvm.
 So I installed 1.2.2_17 on my Windows machine and started running tests.
 That didn't go to well. Here's what I get:


 Buildfile: build-testing.xml
 A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has
 occurred in :
   'org/apache/tools/ant/Project.addReference
 (Ljava/lang/String;Ljava/lang/Object;)V': Interpreting method.
   Please report this error in detail to
 http://java.sun.com/cgi-bin/bugreport.cgi

 A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has
 occurred in :
   'org/apache/tools/ant/Project.fireMessageLoggedEvent
 (Lorg/apache/tools/ant/BuildEvent;Ljava/lang/String;I)V': Interpreting
 method
 .
   Please report this error in detail to
 http://java.sun.com/cgi-bin/bugreport.cgi

 A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has
 occurred in :
   'org/apache/tools/ant/ComponentHelper.addCreatedTask
 (Ljava/lang/String;Lorg/apache/tools/ant/Task;)V': Interpreting method.
   Please report this error in detail to
 http://java.sun.com/cgi-bin/bugreport.cgi


 init:
  [echo]  Logging Wrapper Library 1.1.1-SNAPSHOT 

 discovery:

 log4j12-test-warning:

 test:
  [echo] Test output can be found in directory
 G:\apache\jakarta\commons-logging/target/test-reports.
[delete] Deleting directory
 G:\apache\jakarta\commons-logging\target\test-reports
 [mkdir] Created dir:
 G:\apache\jakarta\commons-logging\target\test-reports
  [echo] executing tests [**/*TestCase.java]
 A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has
 occurred in :
   'org/apache/tools/ant/ComponentHelper.getDataTypeDefinitions
 ()Ljava/util/Hashtable;': Interpreting method.
   Please report this error in detail to
 http://java.sun.com/cgi-bin/bugreport.cgi

 A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has
 occurred in :
   'org/apache/tools/ant/DirectoryScanner.scan ()V': Interpreting method.
   Please report this error in detail to
 http://java.sun.com/cgi-bin/bugreport.cgi

 A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has
 occurred in :
   'org/apache/tools/ant/util/FileUtils.createTempFile
 (Ljava/lang/String;Ljava/lang/String;Ljava/io/File;)Ljava/io/File;':
 Interpret
 ing method.
   Please report this error in detail to
 http://java.sun.com/cgi-bin/bugreport.cgi

 A nonfatal internal JIT (3.10.107(x)) error 'chgTarg: Conditional' has
 occurred in :
   'org/apache/tools/ant/taskdefs/ProcessDestroyer.add
 (Ljava/lang/Process;)Z': Interpreting method.
   Please report this error in detail to
 http://java.sun.com/cgi-bin/bugreport.cgi

 [junit] java.lang.IllegalMonitorStateException: current thread not
 owner
 [junit] at
 org.apache.tools.ant.taskdefs.StreamPumper.run(StreamPumper.java,
 Compiled Code)
 [junit] at java.lang.Thread.run(Thread.java:479)
 [junit] java.lang.IllegalMonitorStateException:

[jira] Resolved: (BEANUTILS-290) Merge Bean-Collections back into core BeanUtils and remove Bean-Collections sub-project


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-290.
---

Resolution: Fixed

I have merged the classes and unit tests back into core BeanUtils and removed 
the bean-collections sub-module. Ant, Maven1 and Maven2 builds all work.

 Merge Bean-Collections back into core BeanUtils and remove Bean-Collections 
 sub-project
 ---

 Key: BEANUTILS-290
 URL: https://issues.apache.org/jira/browse/BEANUTILS-290
 Project: Commons BeanUtils
  Issue Type: Task
  Components: Bean-Collections
Affects Versions: 1.7.0
Reporter: Niall Pemberton
Assignee: Niall Pemberton
Priority: Minor
 Fix For: 1.8.0


 This issue has been discussed in the following thread: 
 http://tinyurl.com/2xdpku
 For BeanUtils 1.7.0 the following classes which had a dependency on Commons 
 Collections were split into a separate bean-collections sub-module:
 BeanComparator.java
 BeanMap.java
 BeanPredicate.java
 BeanPropertyValueChangeClosure.java
 BeanPropertyValueEqualsPredicate.java
 BeanToPropertyValueTransformer.java
 Three flavours of jars were released in 1.7.0
commons-beanutils.jar - containing all BeanUtils classes, including above 
 bean-collections ones
commons-beanutils-bean-collections.jar - containing just the above  
 bean-collections classes
commons-beanutils-core.jar - containing BeanUtils classes excluding above 
 bean-collections ones
 BeanUtils 1.7.0 was created using ant and (I presume) the maven poms for the 
 above artifacts were manually created - unfortunately with mistakes:
 1) The pom for commons-beanutils.jar DOESN'T declare any Commons Collections 
 dependency (which it has for the bean-collections classes)
 2) The pom for commons-beanutils-core.jar DOES declare a Commons Collections 
 dependency (which it doesn't actually have)
 The proposal for BeanUtils 1.8.0 (see http://tinyurl.com/2xdpku) is to merge 
 the bean-collections classes back into core BeanUtils and get rid of the 
 bean-collections sub-module - releasing just a single jar for BeanUtils and 
 marking the Commons Collections dependency as optional in the maven pom 
 (see http://tinyurl.com/2nm2bu).

-- 
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-280) Check binary compatibility is still good


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-280:
--

Attachment: (was: CLIRR.txt)

 Check binary compatibility is still good
 

 Key: BEANUTILS-280
 URL: https://issues.apache.org/jira/browse/BEANUTILS-280
 Project: Commons BeanUtils
  Issue Type: Task
Reporter: Henri Yandell
 Fix For: 1.8.0

 Attachments: CLIRR.txt


 Clirr/jardiff/whatever.

-- 
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-280) Check binary compatibility is still good


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-280:
--

Attachment: CLIRR.txt

Attach latest CLIRR report showing BeanUtils trunk is binary compatible with 
version 1.7.0

 Check binary compatibility is still good
 

 Key: BEANUTILS-280
 URL: https://issues.apache.org/jira/browse/BEANUTILS-280
 Project: Commons BeanUtils
  Issue Type: Task
Reporter: Henri Yandell
 Fix For: 1.8.0

 Attachments: CLIRR.txt


 Clirr/jardiff/whatever.

-- 
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] Resolved: (BEANUTILS-280) Check binary compatibility is still good


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-280.
---

Resolution: Fixed
  Assignee: Niall Pemberton

 Check binary compatibility is still good
 

 Key: BEANUTILS-280
 URL: https://issues.apache.org/jira/browse/BEANUTILS-280
 Project: Commons BeanUtils
  Issue Type: Task
Reporter: Henri Yandell
Assignee: Niall Pemberton
 Fix For: 1.8.0

 Attachments: CLIRR.txt


 Clirr/jardiff/whatever.

-- 
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] Resolved: (BEANUTILS-92) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException

2007-07-17 Thread Niall Pemberton (JIRA)

[
https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Niall Pemberton resolved BEANUTILS-92.
--

Resolution: Fixed

Looks good to me, thanks :)

Closing this as resolved.

PropertyUtilsBean.copyProperties does not catch NoSuchMethodException
-

Key: BEANUTILS-92
URL: https://issues.apache.org/jira/browse/BEANUTILS-92
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.7.0
Environment: Operating System: other
Platform: Other
Reporter: Will Pugh
Assignee: Niall Pemberton
Fix For: 1.8.0

Attachments: Beanutils-92-updated.patch, fixCopyPropertyException,
Jira92TestCase.java

I ran into a problem where I had a bean that had an IndexedSetter but no
simple
setter. This caused a NoSuchMethodException to get thrown in
PropertyUtilsBean.copyProperties. This is inconsistant with BeanUtilsBean
which
catches this case and continues copying the other properties.
When I asked about this in on the mailing list, the answer seemed to come back
that this is probabaly incorrect behaviour, but it is possible people depend
on
this behaviour so this might be too big a change for a point release. I'm
attaching the patch so it can be added to the next major release (if it is
determined to be incorrect behaviour).
The scenario I ran into this was one where I had a bean that I then used CGLib
for enhancing. After that, the bean failed to be clonable by BeanUtils.clone.
This could potentially become a big deal since Hibernate used CGLib for adding
proxies to beans for lazy loading.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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

[jira] Updated: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate

2007-07-17 Thread Niall Pemberton (JIRA)


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-35:
-

Fix Version/s: (was: 1.8.0)
   LATER THAN 1.8.0

Moving to post 1.8.0

 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: LATER THAN 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 Niall Pemberton


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

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?


If you want to do it, I don't have a problem with it.

Niall

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 Niall Pemberton


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

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


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

Niall


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 Niall Pemberton


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

On 7/17/07, Henri Yandell [EMAIL PROTECTED] wrote:
 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).

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

Niall


Niall

 Hen



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

Re: [beanutils] Release plan for a beta

2007-07-17 Thread Niall Pemberton


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

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.


All sounds good to me.


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.


Not that I've done a m2 release, but normal distro should be no extra effort.


Outstanding questions:

1) Fold optional source back in?


Yes


2) Get rid of JUnit cruft that nothing is using?


Up to You - if you or anyone else can be bothered.


3) Remove Maven1 build?


I'm against this - it works and is doing no harm. I'd rather we kept
it at the moment.


Thoughts?


Sounds good - need a release manager - any volunteers?

Niall


Hen



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

[jira] Updated: (BEANUTILS-142) RowSetDynaClass fails to copy ResultSet to DynaBean with Oracle 10g JDBC driver

[
https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Niall Pemberton updated BEANUTILS-142:
--

Affects Version/s: 1.7.0
Summary: RowSetDynaClass fails to copy ResultSet to DynaBean with
Oracle 10g JDBC driver (was: [beanutils] RowSetDynaClass fails to copy
resulset to DynaBean with Oracle 10g JDBC driver)

RowSetDynaClass fails to copy ResultSet 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
Affects Versions: 1.7.0
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] Resolved: (BEANUTILS-142) RowSetDynaClass fails to copy ResultSet to DynaBean with Oracle 10g JDBC driver


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-142.
---

Resolution: Fixed

 RowSetDynaClass fails to copy ResultSet 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
Affects Versions: 1.7.0
 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] Updated: (BEANUTILS-18) PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-18:
-

Affects Version/s: 1.7.0
  Summary: PropertyUtils.isReadable() and 
PropertyUtils.getProperty() not consistent  (was: [beanutils] 
PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent)

 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
Affects Versions: 1.7.0
 Environment: Operating System: Windows 2000
 Platform: PC
Reporter: Maarten Coene
Assignee: Niall Pemberton
 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] Resolved: (BEANUTILS-18) PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-18.
--

Resolution: Fixed

Fixed http://svn.apache.org/viewvc?view=revrevision=556237

 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
Affects Versions: 1.7.0
 Environment: Operating System: Windows 2000
 Platform: PC
Reporter: Maarten Coene
Assignee: Niall Pemberton
 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]

Re: [BeanUtils] Progressing towards a 1.8.0 release

2007-07-14 Thread Niall Pemberton


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.


Theres two separate issues here:

1) What artifacts are packaged and distributed
2) How the structure of the project and the project's build is organised

Although at first sight the Collections dependency was removed from
BeanUtils 1.7.0 - in reality it is still there as a optional
dependency in the main jar (i.e. commons-beanutils.jar) since that
packages up everything currently under BeanUtils. Merging BeanUtils
back into one component with an optional dependency in the pom on
Collections just reflects reality and will produce a
commons-beanutils-1.8.0.jar that ties up with what was distributed
under 1.7.0. We can then also add assemblies to re-create the separate
core and collections jars - so providing a Collections free jar
as before. The net result is a simpler project structure and build -
but effectively the same artifacts with the same dependencies as
before (just a slightly more honest pom).

So I'm +1 to Henri's suggestion.

Niall


Stephen


-
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 Niall Pemberton


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

Niall Pemberton 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, I saw a couple of commits suggesting a Maven 2 site. Are you
aiming for that? If so I could go through it, if you want me to.


Hi Dennis,

Yes, I'm aiming to use m2 for the release ATM - just need to decide on
Henri's project structure suggestion to finish up on it. Any help /
suggestions would be much appreciated - thanks.

Niall


--
Dennis Lundberg


-
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 Niall Pemberton


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

If I understood Henri correctly, his proposal is to distribute one artifact
with optional collection dependencies. True? If so, I am for it. I don't see
any technical advantage in creating collection-free or collection-only jars.


I was around (just) when 1.7.0 was released but I have no recollection
of the decisions made on packaging. I believe the bean-collections
related bean stuff came originally from commons collections - so I
presume this allows people to continue to use these classes wihout
taking on the whole of beanutils - and for the bean-collections free
version - assures people there are no other dependencies. Anyway the
main reason to continue to provide them is so anyone who has chosen to
use them can continue to do so.

Niall


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

 On 7/14/07, Dennis Lundberg [EMAIL PROTECTED] wrote:
  Niall Pemberton 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, I saw a couple of commits suggesting a Maven 2 site. Are you
  aiming for that? If so I could go through it, if you want me to.

 Hi Dennis,

 Yes, I'm aiming to use m2 for the release ATM - just need to decide on
 Henri's project structure suggestion to finish up on it. Any help /
 suggestions would be much appreciated - thanks.

 Niall

  --
  Dennis Lundberg

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

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

[
https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Niall Pemberton updated BEANUTILS-92:
-

Attachment: Jira35TestCase.java

The changes for BEANUTILS-18 does prevent some of the scenrios that caused
NoSuchMethodException to be thrown in the past - unfortunately not the one
reportted by Will (i.e. only indexed setter in the target bean).

Attaching a test case that demonstrates Will's issue is not yet resolved.

So IMO we should go with Will's original suggestion of catching
NoSuchMethodException.

PropertyUtilsBean.copyProperties does not catch NoSuchMethodException
-

Attachments: fixCopyPropertyException, Jira35TestCase.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: (BEANUTILS-91) PropertyUtils.copyProperties throws exceptions contrary to documentation

[
https://issues.apache.org/jira/browse/BEANUTILS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Niall Pemberton updated BEANUTILS-91:
-

Summary: PropertyUtils.copyProperties throws exceptions contrary to
documentation (was: [beanutils] PropertyUtils.copyProperties throws exceptions
contrary to documentation)

PropertyUtils.copyProperties throws exceptions contrary to documentation

Key: BEANUTILS-91
URL: https://issues.apache.org/jira/browse/BEANUTILS-91
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.5
Environment: Operating System: other
Platform: Other
Reporter: Arun Mammen Thomas
Priority: Minor
Fix For: 1.8.0

Attachments: PropertyUtilsTest.java, temp.java

1) The copyProperties method is documented as throwing IllegalAccessException
when access to a particular method is not available. In fact, because
internally the methods to be invoked are filtered for accessiblity
(MethodUtils.getAccessibleMethod) before invocation, the possible sources of
the IllegalAccessException will never actually throw an
IllegalAccessException.
Worse, however, is that the result of a failure to return an accessible
method
is actually taken as occasion to throw a NoSuchMethodException instead.
2) The copyProperties method is also documented as throwing
NoSuchMethodException when a method cannot be found. I'm not sure if this is
an error or not, but a NoSuchMethodException is not thrown when a property of
the same name but a different type is found. (This would, to my mind, be an
occasion of not finding an appropriate method for the setter to function
properly).
Unfortunately, again, there is something worse. In this case, instead of
throwing NoSuchMethodException, an IllegalArgumentException is thrown.
IllegalArgumentException, as a runtime exception, might have been
appropriateexcept for the fact that it is explicitly documented as being
thrown when either the source or the destination arguments are null - no
other
reasons for throwing this are detailed. (Wouldn't NullPointerException be
more appropriate anyway? Curious about the decision to recast this to
IllegalArgumentException) While this is certainly allowed for
RuntimeExceptions, in this case, the documentation is quite misleading about
what is actually to be expected.
I'll attach a JUnitTestCase that captures both of these items.

--
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-35) [beanutils] Indexed properties with Array type cause IllegalArgumentException in setProperty/populate


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-35:
-

Attachment: Beanutils-35-updated.patch

Attaching updated patch for PropertyUtilsBean's copyProperties() to catch 
NoSuchMethodException. Because Maps and DynaBeans can be used as a facade to 
wrap a regular bean I think NoSuchMethodException should be caught in all 
three cases.

 [beanutils] 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: Nightly Builds
 Environment: Operating System: All
 Platform: All
Reporter: David Wood
Assignee: Niall Pemberton
 Fix For: 1.8.0

 Attachments: ArrayIndexedProperty.patch, Beanutils-35-updated.patch, 
 beanutils-indexed-arrays.patch


 If you attempt:
 public String[] getIndexedArrayProperty(int index)
 public void setIndexedArrayProperty(int index,String newvalue[])
 ...this will fail with an IllegalArgumentException in PropertyUtilsBean, 
 because
 setProperty will decide to store the first element of the newvalue array 
 rather
 than the whole array.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (BEANUTILS-91) PropertyUtils.copyProperties throws exceptions contrary to documentation

[
https://issues.apache.org/jira/browse/BEANUTILS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512767
]

Niall Pemberton commented on BEANUTILS-91:
--

If the proposed changes for BEANUTILS-35 get implemented (catching
NoSuchMethodException) then that will mean NoSuchMethodException is not thrown.
Plus the use of isReadable() / isWriteable() should mean IllegalAccessException
is never thrown as well.

Suggest we remove both these exceptions as being declared thrown - is that
considered an incompatible change to the method signature?

PropertyUtils.copyProperties throws exceptions contrary to documentation

Attachments: PropertyUtilsTest.java, temp.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: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-35:
-

Comment: was deleted

 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-indexed-arrays.patch


 If you attempt:
 public String[] getIndexedArrayProperty(int index)
 public void setIndexedArrayProperty(int index,String newvalue[])
 ...this will fail with an IllegalArgumentException in PropertyUtilsBean, 
 because
 setProperty will decide to store the first element of the newvalue array 
 rather
 than the whole array.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-35:
-

Attachment: (was: Beanutils-35-updated.patch)

 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-indexed-arrays.patch


 If you attempt:
 public String[] getIndexedArrayProperty(int index)
 public void setIndexedArrayProperty(int index,String newvalue[])
 ...this will fail with an IllegalArgumentException in PropertyUtilsBean, 
 because
 setProperty will decide to store the first element of the newvalue array 
 rather
 than the whole array.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-35:
-

Attachment: Beanutils-35-updated.patch

Attaching updated patch for PropertyUtilsBean's copyProperties() to catch 
NoSuchMethodException. Because Maps and DynaBeans can be used as a facade to 
wrap a regular bean I think NoSuchMethodException should be caught in all 
three cases.


 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-updated.patch, 
 beanutils-indexed-arrays.patch


 If you attempt:
 public String[] getIndexedArrayProperty(int index)
 public void setIndexedArrayProperty(int index,String newvalue[])
 ...this will fail with an IllegalArgumentException in PropertyUtilsBean, 
 because
 setProperty will decide to store the first element of the newvalue array 
 rather
 than the whole array.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

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

[
https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Niall Pemberton updated BEANUTILS-92:
-

Attachment: Jira92TestCase.java

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] Updated: (BEANUTILS-92) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException

[
https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Niall Pemberton updated BEANUTILS-92:
-

Attachment: (was: Jira35TestCase.java)

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] Updated: (BEANUTILS-92) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException

[
https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Niall Pemberton updated BEANUTILS-92:
-

Attachment: Beanutils-92-updated.patch

Attaching updated patch for PropertyUtilsBean's copyProperties() to catch
NoSuchMethodException. Because Maps and DynaBeans can be used as a facade to
wrap a regular bean I think NoSuchMethodException should be caught in all
three cases.

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] Updated: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-35:
-

Comment: was deleted

 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-indexed-arrays.patch


 If you attempt:
 public String[] getIndexedArrayProperty(int index)
 public void setIndexedArrayProperty(int index,String newvalue[])
 ...this will fail with an IllegalArgumentException in PropertyUtilsBean, 
 because
 setProperty will decide to store the first element of the newvalue array 
 rather
 than the whole array.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-35:
-

Attachment: (was: Beanutils-35-updated.patch)

 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-indexed-arrays.patch


 If you attempt:
 public String[] getIndexedArrayProperty(int index)
 public void setIndexedArrayProperty(int index,String newvalue[])
 ...this will fail with an IllegalArgumentException in PropertyUtilsBean, 
 because
 setProperty will decide to store the first element of the newvalue array 
 rather
 than the whole array.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Issue Comment Edited: (BEANUTILS-91) PropertyUtils.copyProperties throws exceptions contrary to documentation

[
https://issues.apache.org/jira/browse/BEANUTILS-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512767
]

Niall Pemberton edited comment on BEANUTILS-91 at 7/14/07 6:43 PM:
---

If the proposed changes for BEANUTILS-92 get implemented (catching
NoSuchMethodException) then that will mean NoSuchMethodException is not thrown.
Plus the use of isReadable() / isWriteable() should mean IllegalAccessException
is never thrown as well.

Suggest we remove both these exceptions as being declared thrown - is that
considered an incompatible change to the method signature?

was:
If the proposed changes for BEANUTILS-35 get implemented (catching
NoSuchMethodException) then that will mean NoSuchMethodException is not thrown.
Plus the use of isReadable() / isWriteable() should mean IllegalAccessException
is never thrown as well.

Suggest we remove both these exceptions as being declared thrown - is that
considered an incompatible change to the method signature?

PropertyUtils.copyProperties throws exceptions contrary to documentation

Attachments: PropertyUtilsTest.java, temp.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: (BEANUTILS-35) Indexed properties with Array type cause IllegalArgumentException in setProperty/populate


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-35:
-

Attachment: BEANUTILS-35-PropertyUtilsBean-getPropertyType.patch

I agree there are IMO flaws in how BeanUtilsBean's setProperty() method 
determines the type to convert to for simple properties that have indexed or 
mapped descriptors. I started work on a new getPropertyType() method for 
PropertyUtilsBean that I believe resolves these and could be used to replace 
that logic in  BeanUtilsBean's setProperty() method.

Attaching a patch to demonstrate the idea - I haven't yet tested this method or 
tried plugging it into BeanUtilsBean's setProperty() method. Also need to 
review if there are any adverse implications on compatibility of implementing 
this.

P.S. If this approach is OK then also use for LocaleBeanUtils.

 Indexed properties with Array type cause IllegalArgumentException in 
 setProperty/populate
 -

 Key: BEANUTILS-35
 URL: https://issues.apache.org/jira/browse/BEANUTILS-35
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Bean / Property Utils
Affects Versions: 1.7.0
 Environment: Operating System: All
 Platform: All
Reporter: David Wood
Assignee: Niall Pemberton
 Fix For: 1.8.0

 Attachments: ArrayIndexedProperty.patch, 
 BEANUTILS-35-PropertyUtilsBean-getPropertyType.patch, 
 beanutils-indexed-arrays.patch


 If you attempt:
 public String[] getIndexedArrayProperty(int index)
 public void setIndexedArrayProperty(int index,String newvalue[])
 ...this will fail with an IllegalArgumentException in PropertyUtilsBean, 
 because
 setProperty will decide to store the first element of the newvalue array 
 rather
 than the whole array.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Created: (BEANUTILS-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass

JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
---

 Key: BEANUTILS-289
 URL: https://issues.apache.org/jira/browse/BEANUTILS-289
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: DynaBean
Affects Versions: 1.7.0
Reporter: Niall Pemberton
 Fix For: 1.8.0


JDBCDynaClass / RowSetDynaClass has an option to convert the column names to 
lower case when creating the associated DynaProperty - this causea a problem in 
RowSetDynaClass's rows() method which uses the DynaProperty name to access the 
column value in the ResultSet. I can only think no-one is really using this 
since its been this way since created (over 4 years ago) - otherwise everyone 
is using lower case column names in the database anyway!

The proxy TestResultSet and TestResultSetMetaData implementations used by 
DynaRowSetTestCase are hacked by using normal case in the meta data - but lower 
case in the result set.

Since the DynaProperties are created in column index order - I suggest changing 
rows() to use the column index, rather than DynaProperty name.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (BEANUTILS-142) [beanutils] RowSetDynaClass fails to copy resulset to DynaBean with Oracle 10g JDBC driver


[ 
https://issues.apache.org/jira/browse/BEANUTILS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512504
 ] 

Niall Pemberton commented on BEANUTILS-142:
---

I've added a test case which uses a proxy ResultSetMetaData impl. which returns 
the wrong class name (i.e. java.sql.Timestamp instead of java.sql.Date) and 
everything works fine for me. I can only get the ConversionException: Cannot 
assign value... issue you do when I remove my change to RowSetDynaClass which 
calls ConvertUtils. So the only explanation I have ATM is that you're using a 
version of bean utils prior to that change?

Also looking at your test results above - there seems to be two issues?

1) Oracles driver is incorrectly returning java.sql.Timestamp as the column 
class name for date columns (should be java.sql.Date)
2) Oracles driver is incorrectly returning oracle.sql.TIMESTAMP as the column 
class name for timestamp columns (should be java.sql.Timestamp);

So even if my ConvertUtils fix works to stop issue #1 from causing an exception 
- the end result (java.sql.Timestamp values instead of java.sql.Date in the 
DynaBean) still seems wrong to me. And for issue #2 we don't have a solution.

I would be interested to know what the ResultSetMetaData's getColumnType(idx) 
returned for the above - since if they return java.sql.Types.DATE and  
java.sql.Types.TIMESTAMP correctly then we could use that as the basis for a 
solution?
  

 [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] Updated: (BEANUTILS-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-289:
--

Attachment: beanutils-289.patch

 JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
 ---

 Key: BEANUTILS-289
 URL: https://issues.apache.org/jira/browse/BEANUTILS-289
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: DynaBean
Affects Versions: 1.7.0
Reporter: Niall Pemberton
 Fix For: 1.8.0

 Attachments: beanutils-289.patch


 JDBCDynaClass / RowSetDynaClass has an option to convert the column names to 
 lower case when creating the associated DynaProperty - this causea a problem 
 in RowSetDynaClass's rows() method which uses the DynaProperty name to access 
 the column value in the ResultSet. I can only think no-one is really using 
 this since its been this way since created (over 4 years ago) - otherwise 
 everyone is using lower case column names in the database anyway!
 The proxy TestResultSet and TestResultSetMetaData implementations used by 
 DynaRowSetTestCase are hacked by using normal case in the meta data - but 
 lower case in the result set.
 Since the DynaProperties are created in column index order - I suggest 
 changing rows() to use the column index, rather than DynaProperty name.

-- 
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-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-289:
--

Attachment: beanutils-289-revision1.patch

Revised patch attached - also affects ResultSetIterator

 JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
 ---

 Key: BEANUTILS-289
 URL: https://issues.apache.org/jira/browse/BEANUTILS-289
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: DynaBean
Affects Versions: 1.7.0
Reporter: Niall Pemberton
 Fix For: 1.8.0

 Attachments: beanutils-289-revision1.patch


 JDBCDynaClass / RowSetDynaClass has an option to convert the column names to 
 lower case when creating the associated DynaProperty - this causea a problem 
 in RowSetDynaClass's rows() method which uses the DynaProperty name to access 
 the column value in the ResultSet. I can only think no-one is really using 
 this since its been this way since created (over 4 years ago) - otherwise 
 everyone is using lower case column names in the database anyway!
 The proxy TestResultSet and TestResultSetMetaData implementations used by 
 DynaRowSetTestCase are hacked by using normal case in the meta data - but 
 lower case in the result set.
 Since the DynaProperties are created in column index order - I suggest 
 changing rows() to use the column index, rather than DynaProperty name.

-- 
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-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-289:
--

Attachment: (was: beanutils-289-revision1.patch)

 JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
 ---

 Key: BEANUTILS-289
 URL: https://issues.apache.org/jira/browse/BEANUTILS-289
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: DynaBean
Affects Versions: 1.7.0
Reporter: Niall Pemberton
 Fix For: 1.8.0

 Attachments: beanutils-289-revision1.patch


 JDBCDynaClass / RowSetDynaClass has an option to convert the column names to 
 lower case when creating the associated DynaProperty - this causea a problem 
 in RowSetDynaClass's rows() method which uses the DynaProperty name to access 
 the column value in the ResultSet. I can only think no-one is really using 
 this since its been this way since created (over 4 years ago) - otherwise 
 everyone is using lower case column names in the database anyway!
 The proxy TestResultSet and TestResultSetMetaData implementations used by 
 DynaRowSetTestCase are hacked by using normal case in the meta data - but 
 lower case in the result set.
 Since the DynaProperties are created in column index order - I suggest 
 changing rows() to use the column index, rather than DynaProperty name.

-- 
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-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-289:
--

Attachment: beanutils-289-revision1.patch

Woops - attaching revised patch again after deleteing it by mistake instead of 
the older version

 JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
 ---

 Key: BEANUTILS-289
 URL: https://issues.apache.org/jira/browse/BEANUTILS-289
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: DynaBean
Affects Versions: 1.7.0
Reporter: Niall Pemberton
 Fix For: 1.8.0

 Attachments: beanutils-289-revision1.patch


 JDBCDynaClass / RowSetDynaClass has an option to convert the column names to 
 lower case when creating the associated DynaProperty - this causea a problem 
 in RowSetDynaClass's rows() method which uses the DynaProperty name to access 
 the column value in the ResultSet. I can only think no-one is really using 
 this since its been this way since created (over 4 years ago) - otherwise 
 everyone is using lower case column names in the database anyway!
 The proxy TestResultSet and TestResultSetMetaData implementations used by 
 DynaRowSetTestCase are hacked by using normal case in the meta data - but 
 lower case in the result set.
 Since the DynaProperties are created in column index order - I suggest 
 changing rows() to use the column index, rather than DynaProperty name.

-- 
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-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-289:
--

Attachment: (was: beanutils-289.patch)

 JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
 ---

 Key: BEANUTILS-289
 URL: https://issues.apache.org/jira/browse/BEANUTILS-289
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: DynaBean
Affects Versions: 1.7.0
Reporter: Niall Pemberton
 Fix For: 1.8.0

 Attachments: beanutils-289-revision1.patch


 JDBCDynaClass / RowSetDynaClass has an option to convert the column names to 
 lower case when creating the associated DynaProperty - this causea a problem 
 in RowSetDynaClass's rows() method which uses the DynaProperty name to access 
 the column value in the ResultSet. I can only think no-one is really using 
 this since its been this way since created (over 4 years ago) - otherwise 
 everyone is using lower case column names in the database anyway!
 The proxy TestResultSet and TestResultSetMetaData implementations used by 
 DynaRowSetTestCase are hacked by using normal case in the meta data - but 
 lower case in the result set.
 Since the DynaProperties are created in column index order - I suggest 
 changing rows() to use the column index, rather than DynaProperty name.

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

Niall Pemberton updated BEANUTILS-142:
--

Attachment: beanutils-142-oracle-bug.patch

I tested with Oracle (version 10.2.0.1 express edition) and I get the same 
results as you for the meta data and the types returned by ResultSet 
getObject() - but I don't see the exception you're getting - the date column is 
converted to a java.sql.Timestamp.

Also the getColumnType(idx) does return the correct types for date and 
timestamp columns - so this could be used as a solution. Whether we do that or 
not - IMO we should remove my ConvertUtils change for the reason I put in my 
previous post.

Attaching a patch for possible solution using sql type

 [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] Resolved: (BEANUTILS-289) JDBCDynaClass lowerCase option causes problems in RowSetDynaClass


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-289.
---

Resolution: Fixed
  Assignee: Niall Pemberton

Implemented something slightly different:

http://svn.apache.org/viewvc?view=revrevision=556221

 - added a Cross Reference for DynaProperty name to column name to JDBCDynaClass
 - added lookup methods for column names and values
 - modified RowSetDynaClass and ResultSetIterator to use the new methods


 JDBCDynaClass lowerCase option causes problems in RowSetDynaClass
 ---

 Key: BEANUTILS-289
 URL: https://issues.apache.org/jira/browse/BEANUTILS-289
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: DynaBean
Affects Versions: 1.7.0
Reporter: Niall Pemberton
Assignee: Niall Pemberton
 Fix For: 1.8.0

 Attachments: beanutils-289-revision1.patch


 JDBCDynaClass / RowSetDynaClass has an option to convert the column names to 
 lower case when creating the associated DynaProperty - this causea a problem 
 in RowSetDynaClass's rows() method which uses the DynaProperty name to access 
 the column value in the ResultSet. I can only think no-one is really using 
 this since its been this way since created (over 4 years ago) - otherwise 
 everyone is using lower case column names in the database anyway!
 The proxy TestResultSet and TestResultSetMetaData implementations used by 
 DynaRowSetTestCase are hacked by using normal case in the meta data - but 
 lower case in the result set.
 Since the DynaProperties are created in column index order - I suggest 
 changing rows() to use the column index, rather than DynaProperty name.

-- 
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-284) Locale aware Converters doesn't handle conversion direction Object-String


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-284:
--

Fix Version/s: (was: 1.8.0)
   LATER THAN 1.8.0

The new Object--String conversion used by the ConvertUtilsBean lookup has been 
made a configurable option for compatibility reasons - so the need to do this 
is lower and I'm moving this to post 1.8.0

 Locale aware Converters doesn't handle conversion direction Object-String 
 ---

 Key: BEANUTILS-284
 URL: https://issues.apache.org/jira/browse/BEANUTILS-284
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
 Environment: sources from SVN head
Reporter: Josef Cacek
Assignee: Niall Pemberton
 Fix For: LATER THAN 1.8.0

 Attachments: Test.java


 Locale aware Converters doesn't handle conversion direction Object-String 
 according to new implementation of lookup method in ConvertUtilsBean class.
 E.g. BigDecimalLocaleConverter handles conversion String-BigDecimal but not 
 BigDecimal-String

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (BEANUTILS-10) [beanutils] StringLocaleConverter uses same pattern for numbers and dates

[
https://issues.apache.org/jira/browse/BEANUTILS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Niall Pemberton updated BEANUTILS-10:
-

Fix Version/s: (was: 1.8.0)
LATER THAN 1.8.0
Affects Version/s: 1.7.0

[beanutils] StringLocaleConverter uses same pattern for numbers and dates
-

Key: BEANUTILS-10
URL: https://issues.apache.org/jira/browse/BEANUTILS-10
Project: Commons BeanUtils
Issue Type: Bug
Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
Environment: Operating System: All
Platform: All
Reporter: Brian Rodgers
Fix For: LATER THAN 1.8.0

Attachments: mixed-bean-test.zip

StringLocaleConverter doesn't appear to allow for the fact that you need
separate patterns when converting a date field than you do when converting a
number field. Hence, when copying values from a typed bean to a String bean
(such as when copying data into an ActionForm), if the typed bean has both
numbers and dates, one or the other will be corrupted.
To reproduce:
1. Create a bean that contains a java.util.Date field and a number (any
numeric object or primative) field.
2. Create another bean with matching String fields.
3. Populate data into the typed bean from step 1.
4. Register a StringLocaleConverter using a date pattern.
5. User LocalBeanUtils.copyProperties to copy from the typed bean (step 1) to
the String bean (step 2).
6. Print the fields in the String bean. The date field will be properly
converted, but the number field will be formatted (to the extent that it can
be) using the date pattern.
Of course, it also works the other way -- specify a number pattern and the
date field will be corrupted.

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

[BeanUtils] Progressing towards a 1.8.0 release

2007-07-12 Thread Niall Pemberton


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]

[jira] Resolved: (BEANUTILS-263) Improve ClassConverter robustness


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-263.
---

Resolution: Fixed
  Assignee: Niall Pemberton

 Improve ClassConverter robustness
 -

 Key: BEANUTILS-263
 URL: https://issues.apache.org/jira/browse/BEANUTILS-263
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: ConvertUtils  Converters
Affects Versions: 1.7.0
Reporter: Alex Albu
Assignee: Niall Pemberton
Priority: Minor
 Fix For: 1.8.0

 Attachments: ClassConverter.java.patch.txt


 To load a class by name, ClassConverter attempts to use (in order) the 
 current thread's context class loader and the class loader that loaded the 
 class itself.  But in my opinion it is a little inconsistent in the way it 
 does it.  Basically, it will use the second class loader as a fallback *only* 
 if the first one (context class loader) is not set (null).  That causes the 
 converter to fail in environments where the context class loader is set but 
 does not have access to the class it's trying to load (Weblogic 9.2 is an 
 example).
 I think a more robust behavior would be to try the second class loader *any* 
 time using the context one fails (be it because it's not set, or it cannot 
 load the class for some reason).

-- 
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: svn commit: r555489 - in /jakarta/commons/proper/beanutils/trunk/src: java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java test/org/apache/commons/beanutils/locale/convert

2007-07-12 Thread Niall Pemberton


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

This is trivial, but supplied is spelled wrong. Needs two P's.


Thanks, fixed :)

Niall


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

 Author: niallp
 Date: Wed Jul 11 21:53:26 2007
 New Revision: 555489

 URL: http://svn.apache.org/viewvc?view=revrev=555489
 Log:
 BEANUTILS-44 FloatLocaleConverter cannot parse negative values - reported
 by Paul Jenkins

 Modified:

 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java

 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java

 Modified:
 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java
 URL:
 
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java?view=diffrev=555489r1=555488r2=555489

 ==
 ---
 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java
 (original)
 +++
 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/locale/converters/FloatLocaleConverter.java
 Wed Jul 11 21:53:26 2007
 @@ -214,8 +214,10 @@
  */
 protected Object parse(Object value, String pattern) throws
 ParseException {
final Number parsed = (Number) super.parse(value, pattern);
 -  if( Math.abs(parsed.doubleValue() - parsed.floatValue()) 
 parsed.floatValue() * 0.1 ) {
 - throw new ConversionException(Suplied number is not of type
 Float: +parsed.longValue());
 +  double doubleValue = parsed.doubleValue();
 +  double posDouble = (doubleValue = (double)0) ? doubleValue :
 (doubleValue * (double)-1);
 +  if (posDouble  Float.MIN_VALUE || posDouble  Float.MAX_VALUE) {
 +  throw new ConversionException(Suplied number is not of type
 Float: +parsed);
}
return new Float(parsed.floatValue()); // unlike superclass it
 returns Float type
 }

 Modified:
 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java
 URL:
 
http://svn.apache.org/viewvc/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java?view=diffrev=555489r1=555488r2=555489

 ==
 ---
 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java
 (original)
 +++
 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/FloatLocaleConverterTestCase.java
 Wed Jul 11 21:53:26 2007
 @@ -17,6 +17,8 @@

 package org.apache.commons.beanutils.locale.converters;

 +import java.text.DecimalFormat;
 +import org.apache.commons.beanutils.ConversionException;

 /**
   * Test Case for the FloatLocaleConverter class.
 @@ -256,6 +258,49 @@
  convertInvalid(converter, defaultValue);
  convertNull(converter, defaultValue);

 +}
 +
 +/**
 + * Test Float limits
 + */
 +public void testFloatLimits() {
 +
 +converter = new FloatLocaleConverter(defaultLocale,
 defaultDecimalPattern);
 +DecimalFormat fmt = new
 
DecimalFormat(#.#);
 +
 +assertEquals(new Float(-0.12), converter.convert(-0.12));
 +assertEquals(Positive Float.MAX_VALUE, new Float(
 Float.MAX_VALUE), converter.convert(fmt.format(Float.MAX_VALUE)));
 +assertEquals(Positive Float.MIN_VALUE, new Float(
 Float.MIN_VALUE), converter.convert(fmt.format(Float.MIN_VALUE)));
 +
 +assertEquals(Negative Float.MAX_VALUE, new Float(
 Float.MAX_VALUE * -1), converter.convert(fmt.format(Float.MAX_VALUE *
 -1)));
 +assertEquals(Negative Float.MIN_VALUE, new Float(
 Float.MIN_VALUE * -1), converter.convert(fmt.format(Float.MIN_VALUE *
 -1)));
 +
 +
 +try {
 +converter.convert(fmt.format((double)Float.MAX_VALUE *
 (double)10));
 +fail(Positive Too Large should throw ConversionException);
 +} catch (ConversionException e) {
 +// expected result
 +}
 +try {
 +converter.convert(fmt.format((double)Float.MAX_VALUE *
 (double)-10));
 +fail(Negative Too Large should throw ConversionException);
 +} catch (ConversionException e) {
 +// expected result
 +}
 +
 +try {
 +converter.convert(fmt.format((double)Float.MIN_VALUE /
 (double)10));
 +fail(Positive Too Small should throw ConversionException);
 +} catch (ConversionException e) {
 +// expected result
 +

[jira] Created: (BEANUTILS-288) Don't try parsing values that are already Dates/Numbers in Date/Number locale Converters

Don't try parsing values that are already Dates/Numbers in Date/Number locale 
Converters


 Key: BEANUTILS-288
 URL: https://issues.apache.org/jira/browse/BEANUTILS-288
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
Reporter: Niall Pemberton
Assignee: Niall Pemberton
 Fix For: 1.8.0


DateLocaleConverter shouldn't try and parse values that are already Date or 
Calendar objects
DecimalLocaleConverter shouldn't try and parse values that are 
alreadyjava.lang.Number objects

-- 
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] Resolved: (BEANUTILS-288) Don't try parsing values that are already Dates/Numbers in Date/Number locale Converters


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-288.
---

Resolution: Fixed

 Don't try parsing values that are already Dates/Numbers in Date/Number locale 
 Converters
 

 Key: BEANUTILS-288
 URL: https://issues.apache.org/jira/browse/BEANUTILS-288
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
Reporter: Niall Pemberton
Assignee: Niall Pemberton
 Fix For: 1.8.0


 DateLocaleConverter shouldn't try and parse values that are already Date or 
 Calendar objects
 DecimalLocaleConverter shouldn't try and parse values that are 
 alreadyjava.lang.Number objects

-- 
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] Resolved: (BEANUTILS-271) DateLocaleConverter does not always throw an Exception for invalid dates


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-271.
---

Resolution: Fixed

Fixed thanks!

 DateLocaleConverter does not always throw an Exception for invalid dates
 

 Key: BEANUTILS-271
 URL: https://issues.apache.org/jira/browse/BEANUTILS-271
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
 Environment: jdk1.5
Reporter: Nico Hoogervorst
Priority: Minor
 Fix For: 1.8.0

 Attachments: DateConverter.java


 example pattern: MMdd
 example value  : 2007011x
 is accepted. The 'x' is ignored.

-- 
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-271) DateLocaleConverter does not always throw an Exception for invalid dates


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-271:
--

Summary: DateLocaleConverter does not always throw an Exception for invalid 
dates  (was: [beanutils] converters - DateLocaleConverter does not always throw 
an Exception for invalid dates)

 DateLocaleConverter does not always throw an Exception for invalid dates
 

 Key: BEANUTILS-271
 URL: https://issues.apache.org/jira/browse/BEANUTILS-271
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
 Environment: jdk1.5
Reporter: Nico Hoogervorst
Priority: Minor
 Fix For: 1.8.0

 Attachments: DateConverter.java


 example pattern: MMdd
 example value  : 2007011x
 is accepted. The 'x' is ignored.

-- 
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-92) PropertyUtilsBean.copyProperties does not catch NoSuchMethodException


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-92:
-

Affects Version/s: (was: Nightly Builds)
   1.7.0
 Assignee: Niall Pemberton
  Summary: PropertyUtilsBean.copyProperties does not catch 
NoSuchMethodException  (was: [beanutils] PropertyUtilsBean.copyProperties does 
not catch NoSuchMethodException)

I believe this will be fixed when the proposed changes for BEANUTILS-18 are 
implemented - will re-check this after that

 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: fixCopyPropertyException


 I ran into a problem where I had a bean that had an IndexedSetter but no 
 simple
 setter.  This caused a NoSuchMethodException to get thrown in
 PropertyUtilsBean.copyProperties.  This is inconsistant with BeanUtilsBean 
 which
 catches this case and continues copying the other properties.
 When I asked about this in on the mailing list, the answer seemed to come back
 that this is probabaly incorrect behaviour, but it is possible people depend 
 on
 this behaviour so this might be too big a change for a point release.  I'm
 attaching the patch so it can be added to the next major release (if it is
 determined to be incorrect behaviour).
 The scenario I ran into this was one where I had a bean that I then used CGLib
 for enhancing.  After that, the bean failed to be clonable by BeanUtils.clone.
 This could potentially become a big deal since Hibernate used CGLib for adding
 proxies to beans for lazy loading.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (BEANUTILS-255) Date and Calendar Converter implementations


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-255:
--

   Issue Type: New Feature  (was: Bug)
Affects Version/s: 1.7.0
  Summary: Date and Calendar Converter implementations  (was: 
ConvertUtilsBean does not support converts to a java.util.Date)

 Date and Calendar Converter implementations
 ---

 Key: BEANUTILS-255
 URL: https://issues.apache.org/jira/browse/BEANUTILS-255
 Project: Commons BeanUtils
  Issue Type: New Feature
  Components: ConvertUtils  Converters
Affects Versions: 1.7.0
Reporter: Henri Yandell
Assignee: Niall Pemberton
 Fix For: 1.8.0


 It's impossible to convert a String to a java.util.Date (see commons-user 
 mail thread 'Digester and using of java.util.Date').

-- 
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-185) Map decorator for DynaBeans to allow BeanUtils to operate with technologies such as JSTL


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-185:
--

Issue Type: New Feature  (was: Improvement)
   Summary: Map decorator for DynaBeans to allow BeanUtils to operate with 
technologies such as JSTL  (was: New Map decorator for DynaBeans to allow 
BeanUtils to operate with technologies such as JSTL)

 Map decorator for DynaBeans to allow BeanUtils to operate with technologies 
 such as JSTL
 

 Key: BEANUTILS-185
 URL: https://issues.apache.org/jira/browse/BEANUTILS-185
 Project: Commons BeanUtils
  Issue Type: New Feature
  Components: DynaBean
Affects Versions: 1.7.0
 Environment: Operating System: other
 Platform: Other
Reporter: Gabriel Belingueres
Assignee: Niall Pemberton
Priority: Minor
 Fix For: 1.8.0

 Attachments: AbstractRowSetDynaClass.java, 
 BasicDirectAccessDynaBean.java, BasicDirectAccessDynaBeanTestCase.java, 
 BasicIndirectAccessDynaBean.java, beanutil-diff.txt, 
 DirectAccessDynaBean.java, DirectRowSetDynaClass.java, 
 DynaBeanMapDecorator.java, DynaBeanMapDecoratorTestCase.java, 
 IndirectAccessDynaBean.java, IndirectRowSetDynaClass.java


 Hi,
 I've done some modifications to the beanutils package to better support the 
 use 
 of DynaBeans with the JSTL tags. Some of the changes are discussed in this 
 thread of the commons-user mailing list:
 http://marc.theaimsgroup.com/?l=jakarta-commons-userm=114669123403779w=2
 I attach the diff file that comprises changes to the RowSetDynaClass.java 
 file 
 and build.xml file (since I added a TestCase.) Note: Please try to filter 
 carefully the diffs in the build.xml file since they include some local 
 settings I have for compilation on my machine. :-(
 Together with the diff file, I attach the new java files added to the package.
 Regards,
 Gabriel Belingueres
 [EMAIL PROTECTED]

-- 
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-259) Plugable Property Name Expression Resolver

[
https://issues.apache.org/jira/browse/BEANUTILS-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Niall Pemberton updated BEANUTILS-259:
--

Issue Type: New Feature (was: Improvement)

Plugable Property Name Expression Resolver
--

Key: BEANUTILS-259
URL: https://issues.apache.org/jira/browse/BEANUTILS-259
Project: Commons BeanUtils
Issue Type: New Feature
Components: Expression Syntax
Affects Versions: 1.7.0
Reporter: Niall Pemberton
Assignee: Niall Pemberton
Priority: Minor
Fix For: 1.8.0

Attachments: BasicResolver.java, BasicResolverTestCase.java,
Resolver.java

There are a number of outstanding bugs against the BeanUtils expression
syntax with people wanting BeanUtils to support different variations. There
is also a duplication of the expression evaluation code in various methods
which can't be tested in isolation and is difficult to maintain as changes
have to be applied uniformly to various places.
The main places where the code is duplicated:
PropertyUtilsBean
- getNestedProperty
- setNestedProperty
- getPropertyDescriptor
BeanUtilsBean
- copyProperty
- setProperty
LocaleBeanUtils has also implemented an alternative mechanism - using a
Descriptor object to resolve references. BeanUtils and PropertyUtils also
work in slightly different ways. There are also other methods (e.g.
PropertyUtilsBean's getIndexedProperty() method) which also have related code.
I propose to add a new expression resolver interface, which would be a
singleton and everywhere would delegate to to resolve property expressions.
This will allow easy testing as it can be tested in isolation and provide a
uniform mechanism accross BeanUtils. It will also allow alternative syntax to
be implemented if the resolver implementation can be configured.

--
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] Resolved: (BEANUTILS-254) Run Checkstyle/PMD on the source and get things fixed up


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-254.
---

Resolution: Fixed
  Assignee: Niall Pemberton

 Run Checkstyle/PMD on the source and get things fixed up
 

 Key: BEANUTILS-254
 URL: https://issues.apache.org/jira/browse/BEANUTILS-254
 Project: Commons BeanUtils
  Issue Type: Task
Reporter: Henri Yandell
Assignee: Niall Pemberton
 Fix For: 1.8.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: (BEANUTILS-18) [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-18:
-

Attachment: BEANUTILS-18-PropertyUtilsBean.patch

As well as PropertyUtilsBean's isReadable() and isWriteable() methods  the 
indexed and mapped get/set methods are also missing the checks that the simple 
get/set methods use. Attaching a patch for review

 [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] Updated: (BEANUTILS-41) Provide better error message for No value specified


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-41:
-

Issue Type: Improvement  (was: Bug)
   Summary: Provide better error message for No value specified  (was: 
[beanutils] Provide better error message for No value specified)

Changing to improvement

 Provide better error message for No value specified
 -

 Key: BEANUTILS-41
 URL: https://issues.apache.org/jira/browse/BEANUTILS-41
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: ConvertUtils  Converters
 Environment: Operating System: other
 Platform: Other
Reporter: Ralf Hauser
 Fix For: LATER THAN 1.8.0


 Got org.apache.commons.beanutils.ConversionException: No value specified
 at
 org.apache.commons.beanutils.converters.SqlDateConverter.convert(SqlDateConverter.java:103)
 at
 org.apache.commons.beanutils.BeanUtilsBean.copyProperty(BeanUtilsBean.java:444)
 at
 org.apache.commons.beanutils.BeanUtilsBean.copyProperties(BeanUtilsBean.java:261)
 at
 org.apache.commons.beanutils.BeanUtils.copyProperties(BeanUtils.java:114)
  
 Suggestion:
 1) cite the propName and the bean className
this probably implies that the interface
  org.apache.commons.beanutils.Converter.convert(Class type, Object value)
is extended to 
  org.apache.commons.beanutils.Converter.convert(Class type, Object value,
 String propName, String beanClassName)
 2) also cite the concerned class name (probably java.sql.Date) 
 3) mention that there is the possibility to use a default value

-- 
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-95) Handling exceptions during BeanUtils.populate()


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-95:
-

Issue Type: Improvement  (was: Bug)
   Summary: Handling exceptions during BeanUtils.populate()  (was: 
[beanutils] Handling exceptions during BeanUtils.populate())

Changing to improvement

 Handling exceptions during BeanUtils.populate()
 ---

 Key: BEANUTILS-95
 URL: https://issues.apache.org/jira/browse/BEANUTILS-95
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: Bean / Property Utils
 Environment: Operating System: other
 Platform: Other
Reporter: Xavier Dury
 Fix For: LATER THAN 1.8.0


 Hi,
 I know this has been asked already before but could there be a way to handle 
 exceptions that occur during population? The populate() function could either 
 return a map(property, exception), take that kind of map as argument or -even 
 better- take a PopulateExceptionHandler as argument.
 The reason I would like to see this feature implemented is to allow struts to 
 use this mechanism to convert parameters from the request to actionform's 
 properties without *falling apart* when encountering one that is not well-
 formed. 
 It would be nice too if we were not *forced* to use string-only properties 
 for 
 actionforms (which in fact is a way to circumvent this conversion problem). I 
 would like my ActionForm or DynaActionForm declare strongly-typed properties 
 (maybe custom classes), register proper Converters into ConvertUtils in the 
 ActionServlet.initServlet() for example, and then maybe get back conversion 
 errors from within my action (maybe the PopulateExceptionHandler could add 
 some ActionErrors to the request).
 What do you think? I know this issue is tightly coupled to struts but 
 well... ;-)
 Thanks a lot,
 Xavier

-- 
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-140) LocaleBeanUtils setProperty does not work on nested property


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-140:
--

 Assignee: Niall Pemberton
Affects Version/s: 1.7.0
  Summary: LocaleBeanUtils setProperty does not work on nested 
property  (was: [beanutils] LocaleBeanUtils setProperty does not work on nested 
property)

 LocaleBeanUtils setProperty does not work on nested property
 

 Key: BEANUTILS-140
 URL: https://issues.apache.org/jira/browse/BEANUTILS-140
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
 Environment: Operating System: All
 Platform: All
Reporter: Marco La Porta
Assignee: Niall Pemberton
 Fix For: 1.8.0


 LocaleBeanUtils setProperty does not work on nested property.
 I think the problem is in the method definePropertyType(Object target, String 
 name, String propName).
 When property is a nested property (prop1.propnested) target is the result 
 of a call of the prop1 getter on the oroginal bean, name is the property 
 name complete (prop1.propnested) and propName is the property name in 
 target 
 object (propnested).
 At line 601 the property descriptor is defined as
 descriptor = PropertyUtils.getPropertyDescriptor(target, name);
 and in case of nested propery it is never found (null)
 I think the correct line 601 is
 descriptor = PropertyUtils.getPropertyDescriptor(target, propName);

-- 
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] Resolved: (BEANUTILS-140) LocaleBeanUtils setProperty does not work on nested property


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-140.
---

Resolution: Invalid

I added a test case for this  but can't reproduce this in either the current 
trunk or BeanUtils 1.7.0

 LocaleBeanUtils setProperty does not work on nested property
 

 Key: BEANUTILS-140
 URL: https://issues.apache.org/jira/browse/BEANUTILS-140
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
 Environment: Operating System: All
 Platform: All
Reporter: Marco La Porta
Assignee: Niall Pemberton
 Fix For: 1.8.0


 LocaleBeanUtils setProperty does not work on nested property.
 I think the problem is in the method definePropertyType(Object target, String 
 name, String propName).
 When property is a nested property (prop1.propnested) target is the result 
 of a call of the prop1 getter on the oroginal bean, name is the property 
 name complete (prop1.propnested) and propName is the property name in 
 target 
 object (propnested).
 At line 601 the property descriptor is defined as
 descriptor = PropertyUtils.getPropertyDescriptor(target, name);
 and in case of nested propery it is never found (null)
 I think the correct line 601 is
 descriptor = PropertyUtils.getPropertyDescriptor(target, propName);

-- 
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-204) [beanutils] LocaleBeanUtils.copyProperties() does not use Locale aware converions


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-204:
--

Fix Version/s: (was: 1.8.0)
   LATER THAN 1.8.0

Needs someone to provide a copyProperties() implementation for 
LocaleBeanUtilsBean (currently just inheriting from BeanUtilsBean) - punting to 
post 1.8.0 since no one has stepped up to do this.

 [beanutils] LocaleBeanUtils.copyProperties() does not use Locale aware 
 converions
 -

 Key: BEANUTILS-204
 URL: https://issues.apache.org/jira/browse/BEANUTILS-204
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: Locale BeanUtils / Converters
Affects Versions: 1.5
 Environment: Operating System: other
 Platform: Other
Reporter: Robert Burrell Donkin
Priority: Minor
 Fix For: LATER THAN 1.8.0


 for more details see
 http://marc.theaimsgroup.com/?l=jakarta-commons-userm=104239393332710w=2
 this functionality would be a little tricky to add and can wait until after 
 the
 1.6 release.

-- 
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-44) FloatLocaleConverter cannot parse negative values


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-44:
-

Affects Version/s: 1.7.0
  Summary: FloatLocaleConverter cannot parse negative values  (was: 
[beanutils] FloatLocaleConverter cannot parse negative values)

 FloatLocaleConverter cannot parse negative values
 -

 Key: BEANUTILS-44
 URL: https://issues.apache.org/jira/browse/BEANUTILS-44
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
 Environment: Operating System: All
 Platform: All
Reporter: Paul Jenkins
 Fix For: 1.8.0


 Problem found in Build 1.7
 LocaleBeanUtils.setProperty(bean, name, value);
 Does not handle negative values. When processing negative values the 
 FloatLocaleConverter.parse(value, pattern) throws a ConversionException 
 because 
 of the following if test: -
 if(Math.abs(parsed.doubleValue() - parsed.floatValue())  
   parsed.floatValue() * 0.1) {
   throw new ConversionException(...);
 }
 This test will always fail for a valid negative value because the 
 multiplication by 0.1 will result in a negative value which will be less 
 then the abs subtraction.
 A solution to this problem would be to check Math.abs(parsed.floatValue() * 
 0.1)
 We also suffer from the previously reported problem of the locale converters 
 not supporting boolean to get round this problem we have to determine the 
 property type and call either LocaleBeanUtils.setProperty() or 
 BeanUtils.setProperty() this would be made easier if the: -
 protected Descriptor calculate(Object bean, String name) 
 method was made public.

-- 
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] Resolved: (BEANUTILS-44) FloatLocaleConverter cannot parse negative values


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-44.
--

Resolution: Fixed
  Assignee: Niall Pemberton

 FloatLocaleConverter cannot parse negative values
 -

 Key: BEANUTILS-44
 URL: https://issues.apache.org/jira/browse/BEANUTILS-44
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Locale BeanUtils / Converters
Affects Versions: 1.7.0
 Environment: Operating System: All
 Platform: All
Reporter: Paul Jenkins
Assignee: Niall Pemberton
 Fix For: 1.8.0


 Problem found in Build 1.7
 LocaleBeanUtils.setProperty(bean, name, value);
 Does not handle negative values. When processing negative values the 
 FloatLocaleConverter.parse(value, pattern) throws a ConversionException 
 because 
 of the following if test: -
 if(Math.abs(parsed.doubleValue() - parsed.floatValue())  
   parsed.floatValue() * 0.1) {
   throw new ConversionException(...);
 }
 This test will always fail for a valid negative value because the 
 multiplication by 0.1 will result in a negative value which will be less 
 then the abs subtraction.
 A solution to this problem would be to check Math.abs(parsed.floatValue() * 
 0.1)
 We also suffer from the previously reported problem of the locale converters 
 not supporting boolean to get round this problem we have to determine the 
 property type and call either LocaleBeanUtils.setProperty() or 
 BeanUtils.setProperty() this would be made easier if the: -
 protected Descriptor calculate(Object bean, String name) 
 method was made public.

-- 
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: (VALIDATOR-233) Update location of dojo compressor library


[ 
https://issues.apache.org/jira/browse/VALIDATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511380
 ] 

Niall Pemberton commented on VALIDATOR-233:
---

Unfortunately changing the URL in the ant build script (i.e.  
build-javascript.xml) produces the following error:

java.net.UnknownHostException: svn.dojotoolkit.org

So it looks like the automated download can't be fixed ATM. I opened a ticket 
10 months ago asking dojo to add the jar to the maven repo - but no progress so 
far:

http://trac.dojotoolkit.org/ticket/910

 Update location of dojo compressor library
 --

 Key: VALIDATOR-233
 URL: https://issues.apache.org/jira/browse/VALIDATOR-233
 Project: Commons Validator
  Issue Type: Task
  Components: JavaScript
Affects Versions: 1.4
Reporter: Paul Benedict
 Fix For: 1.4


 build-javascript.xml no longer has a valid URL to the compressor library. It 
 is now located at:
 http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/

-- 
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: (VALIDATOR-232) Add script attribute to control script generation


[ 
https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511390
 ] 

Niall Pemberton commented on VALIDATOR-232:
---

Out of interest what's your use case for this? The only one I've seen in the 
past is for password fields, where people don't want things such as min/max 
length and regular expression rules revealed in javascript.

One way to do this currently would be to configure additional non-script 
equivalent validators - or in the case of password validation its probably 
better to develop a custom password validator.

Anyway STR-1888 doesn't give a use-case and its not something that I recall 
being much requested in Struts - so I'd be interested to hear yours.

 Add script attribute to control script generation
 -

 Key: VALIDATOR-232
 URL: https://issues.apache.org/jira/browse/VALIDATOR-232
 Project: Commons Validator
  Issue Type: New Feature
  Components: Framework
Reporter: Paul Benedict
Priority: Minor
 Fix For: 1.4

 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch


 Add a script=true|false attribute to field to control whether JavaScript 
 should be generated.
 Also see: https://issues.apache.org/struts/browse/STR-1888

-- 
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: (VALIDATOR-233) Update location of dojo compressor library


[ 
https://issues.apache.org/jira/browse/VALIDATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511429
 ] 

Niall Pemberton commented on VALIDATOR-233:
---

Yes sorry, this was a firewall issue on my end

 Update location of dojo compressor library
 --

 Key: VALIDATOR-233
 URL: https://issues.apache.org/jira/browse/VALIDATOR-233
 Project: Commons Validator
  Issue Type: Task
  Components: JavaScript
Affects Versions: 1.4
Reporter: Paul Benedict
 Fix For: 1.4


 build-javascript.xml no longer has a valid URL to the compressor library. It 
 is now located at:
 http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/

-- 
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: (VALIDATOR-233) Switch to using Version 0.4.3 of the Dojo Compressor from the maven repo


 [ 
https://issues.apache.org/jira/browse/VALIDATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated VALIDATOR-233:
--

Summary: Switch to using Version 0.4.3 of the Dojo Compressor from the 
maven repo  (was: Update location of dojo compressor library)

The Dojo Compressor has been added to the maven repo - which is good news since 
now we can use a versioned version - updating the title of this ticket to 
reflect that

 Switch to using Version 0.4.3 of the Dojo Compressor from the maven repo
 

 Key: VALIDATOR-233
 URL: https://issues.apache.org/jira/browse/VALIDATOR-233
 Project: Commons Validator
  Issue Type: Task
  Components: JavaScript
Affects Versions: 1.4
Reporter: Paul Benedict
 Fix For: 1.4


 build-javascript.xml no longer has a valid URL to the compressor library. It 
 is now located at:
 http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/

-- 
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: (VALIDATOR-233) Switch to using Version 0.4.3 of the Dojo Compressor from the maven repo


 [ 
https://issues.apache.org/jira/browse/VALIDATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated VALIDATOR-233:
--

 Priority: Minor  (was: Major)
Affects Version/s: (was: 1.4)
   1.3.1 Release

 Switch to using Version 0.4.3 of the Dojo Compressor from the maven repo
 

 Key: VALIDATOR-233
 URL: https://issues.apache.org/jira/browse/VALIDATOR-233
 Project: Commons Validator
  Issue Type: Task
  Components: JavaScript
Affects Versions: 1.3.1 Release
Reporter: Paul Benedict
Priority: Minor
 Fix For: 1.4


 build-javascript.xml no longer has a valid URL to the compressor library. It 
 is now located at:
 http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/

-- 
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] Resolved: (VALIDATOR-233) Switch to using Version 0.4.3 of the Dojo Compressor from the maven repo


 [ 
https://issues.apache.org/jira/browse/VALIDATOR-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved VALIDATOR-233.
---

Resolution: Fixed
  Assignee: Niall Pemberton

 Switch to using Version 0.4.3 of the Dojo Compressor from the maven repo
 

 Key: VALIDATOR-233
 URL: https://issues.apache.org/jira/browse/VALIDATOR-233
 Project: Commons Validator
  Issue Type: Task
  Components: JavaScript
Affects Versions: 1.3.1 Release
Reporter: Paul Benedict
Assignee: Niall Pemberton
Priority: Minor
 Fix For: 1.4


 build-javascript.xml no longer has a valid URL to the compressor library. It 
 is now located at:
 http://svn.dojotoolkit.org/dojo/trunk/buildscripts/lib/

-- 
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: (VALIDATOR-232) Add script attribute to control script generation


[ 
https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511455
 ] 

Niall Pemberton commented on VALIDATOR-232:
---

Not sure what you mean by Because I don't have this ability, neither do I use 
javascript at all on my Struts apps - are you saying the lack of this feature 
prevents you using javascript validation?

If theres a bug in one of the javascript validators then people would 
presumably want to turn it off for all validations of that type (or override it 
with their own custom javascript version with the bug fixed). I also don't 
really see how switching on/off individual field's client validation has a use 
for different intranet/internet deployments.

If the only use-case is the password scenario - then IMO would be more useful 
to provide a password validator (combination of required, mix/max length and 
mask) than this enhancement. If none of us have any other use case and the 
users are not clamouring for it - then my preference is to not bother and focus 
on other things instead.

 Add script attribute to control script generation
 -

 Key: VALIDATOR-232
 URL: https://issues.apache.org/jira/browse/VALIDATOR-232
 Project: Commons Validator
  Issue Type: New Feature
  Components: Framework
Reporter: Paul Benedict
Priority: Minor
 Fix For: 1.4

 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch


 Add a script=true|false attribute to field to control whether JavaScript 
 should be generated.
 Also see: https://issues.apache.org/struts/browse/STR-1888

-- 
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: (VALIDATOR-232) Add script attribute to control script generation


[ 
https://issues.apache.org/jira/browse/VALIDATOR-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511625
 ] 

Niall Pemberton commented on VALIDATOR-232:
---

OK fair enough, not a priority IMO, but if you want it I'll stop arguing :)

On the name of the attribute - I agree we shouldn't use script - but I don't 
really like scripting either and was wondering if we could come up with 
something better - unfortunately I could only come up with  ignoreScript, 
skipScript, doScript, execScript, useScript, noScript and I'm not 
sure if they're any better - got any ideas? ATM I'd probably go for noScript.

 Add script attribute to control script generation
 -

 Key: VALIDATOR-232
 URL: https://issues.apache.org/jira/browse/VALIDATOR-232
 Project: Commons Validator
  Issue Type: New Feature
  Components: Framework
Reporter: Paul Benedict
Priority: Minor
 Fix For: 1.4

 Attachments: VALIDATOR-232.dtd.patch, VALIDATOR-232.patch


 Add a script=true|false attribute to field to control whether JavaScript 
 should be generated.
 Also see: https://issues.apache.org/struts/browse/STR-1888

-- 
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] Resolved: (BEANUTILS-273) Public methods overriden in anonymous or private subclasses are not recognized by PropertyUtils


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-273.
---

Resolution: Fixed
  Assignee: Niall Pemberton

Thanks for taking the time to provide a patch and test case - although I 
decided to use a slightly different approach - leave the interface checking 
alone and provide and additional check through the parent class hierarchy if 
all else failed.

 Public methods overriden in anonymous or private subclasses are not 
 recognized by PropertyUtils
 ---

 Key: BEANUTILS-273
 URL: https://issues.apache.org/jira/browse/BEANUTILS-273
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Bean / Property Utils
Affects Versions: 1.7.0
Reporter: Marcelo Liberato
Assignee: Niall Pemberton
 Fix For: 1.8.0

 Attachments: anonymous-subclass-override-patch.txt


 When you do something like:
   TestBean anonymous = new TestBean() {
   public String getStringProperty() {
   return foo;
   }
   };
   PropertyUtils.getProperty(anonymous, stringProperty);
 PropertyUtils fails as:
 java.lang.NoSuchMethodException: Property 'stringProperty' has no getter 
 method in class 'class org.apache.commons.beanutils.PropertyUtilsTestCase$1'

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Commented: (BEANUTILS-18) [beanutils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent


[ 
https://issues.apache.org/jira/browse/BEANUTILS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12511662
 ] 

Niall Pemberton commented on BEANUTILS-18:
--

IMO isReadable() returning true for properties which throw an exception when 
getProperty() is called is a bug - so I don't agree with Simon that we need to 
retain backward compatibility - bugs just need to be fixed.

I have changes ready to commit for this, but I'll hold off to allow for 
comments/objections before committing anything.

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

Re: board report

2007-07-08 Thread Niall Pemberton


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

I need to prepare the first Commons board report. So far I came up with:

Releases
  o 02 July Commons IO 1.3.2

Infrastructure
  o Still work to be done for TLP https://issues.apache.org/jira/
browse/INFRA-1283

Community
  o We agreed to only migrate commit rights of committers that did a
commit in the past 2 years. Of course any previous committer just has
to ask to get his rights back at any time. See the jira issue for the
initial list of committers
  o No new committers
  o No new PMC members

Anything else we should add?


June 25 - Modeler 2.0.1 release

Niall


cheers
--
Torsten


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

Re: svn commit: r553747 - in /jakarta/commons/proper/dbcp/trunk: pom.xml src/site/ src/site/site.xml

2007-07-06 Thread Niall Pemberton


Phil,

Dennis released Verson 3 of the parent pom a while ago - do you not
want to use that?

Niall

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

Author: psteitz
Date: Thu Jul  5 23:04:45 2007
New Revision: 553747

URL: http://svn.apache.org/viewvc?view=revrev=553747
Log:
Updates / fixes to get site generation working on Maven 2
- Added site.xml based on navigation.xml
POM fixes:
- Updated version to 1.3-SNAPSHOT
- Added reporting section
- Updated commons parent version

Added:
jakarta/commons/proper/dbcp/trunk/src/site/
jakarta/commons/proper/dbcp/trunk/src/site/site.xml
Modified:
jakarta/commons/proper/dbcp/trunk/pom.xml

Modified: jakarta/commons/proper/dbcp/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/jakarta/commons/proper/dbcp/trunk/pom.xml?view=diffrev=553747r1=553746r2=553747
==
--- jakarta/commons/proper/dbcp/trunk/pom.xml (original)
+++ jakarta/commons/proper/dbcp/trunk/pom.xml Thu Jul  5 23:04:45 2007
@@ -22,12 +22,12 @@
   parent
 groupIdorg.apache.commons/groupId
 artifactIdcommons-parent/artifactId
-version1/version
+version2/version
   /parent
   modelVersion4.0.0/modelVersion


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

[jira] Updated: (BEANUTILS-176) Exception if property doesn't exist in BeanUtilsBean.setProperty()


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-176:
--

Fix Version/s: (was: 1.8.0)
   LATER THAN 1.8.0
  Summary: Exception if property doesn't exist in 
BeanUtilsBean.setProperty()  (was: [beanutils]: Exception if property doesn't 
exist in BeanUtilsBean.setProperty())

 Exception if property doesn't exist in BeanUtilsBean.setProperty()
 --

 Key: BEANUTILS-176
 URL: https://issues.apache.org/jira/browse/BEANUTILS-176
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: Bean / Property Utils
 Environment: Operating System: other
 Platform: Other
Reporter: Lars Beuster
Priority: Minor
 Fix For: LATER THAN 1.8.0


 I'd like a have an exception thrown if I use
 BeanUilsBean.setProperty()/populate()/... with an invalid property name, so 
 that
 I can see immediately if I've done something wrong.
 An optional boolean parameter for these methods would be nice.
 Thanks
 Lars

-- 
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] Resolved: (BEANUTILS-49) Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-49.
--

Resolution: Fixed

 Lock in BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
 

 Key: BEANUTILS-49
 URL: https://issues.apache.org/jira/browse/BEANUTILS-49
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Bean / Property Utils
Affects Versions: 1.7.0
 Environment: Operating System: other
 Platform: Other
Reporter: Jesper Richter-Reichhelm
Assignee: Niall Pemberton
 Fix For: 1.8.0

 Attachments: beanutils-49-ContextClassLoaderLocale.patch, 
 BEANUTILS-49.patch


 Commons Beanutils 1.7 introduced a new problem:
 During high traffic times threads begin to wait at the synchronized method
 org.apache.commons.beanutils.BeanUtilsBean.getInstance() which causes the
 complete thread pool to be used up in our Struts 1.2.7 based web application. 
 In
 our live environment this caused all 70 threads to be blocked by the same 
 lock.
 This behaviour can be easily reproduced by a calling a test JSP provided below
 with multiple threads. Using the tool siege to concurrently call the JSP with
 two threads is enough to reproduce the lock scenario, the situation gets worse
 the more concurrent threads are used (i.e. the throughput decreases).
 !-- begin of test JSP --
 %@ taglib uri=/struts-logic.tld prefix=logic %
 %@ taglib uri=/struts-bean.tld prefix=bean %
 %@ taglib uri=/struts-tiles.tld prefix=tiles %
 %@ taglib uri=/struts-html.tld prefix=html %
 %@ taglib uri=/JLog.tld prefix=jlog %
 %@ page import=java.util.*%
 %
final long t0 = System.currentTimeMillis();
  Collection col = new ArrayList();
  for(int i = 0; i5; i++)
  {
   org.apache.struts.util.LabelValueBean lvb = new
 org.apache.struts.util.LabelValueBean(col+i, col+i);
   col.add(lvb);
  }
pageContext.setAttribute(col, col);
 %
 logic:notEmpty name=collogic:iterate name=col id=testlogic:iterate
 name=col id=test2logic:iterate name=col id=test3logic:iterate
 name=col id=test3logic:iterate name=col id=test4logic:iterate
 name=col id=test4
 bean:define id=foo name=test4 property=value/bean:define id=bar
 name=test4 property=label/
 /logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:iterate/logic:notEmpty
 Finished!
 !-- end of test JSP -- 
 A test run with Struts 1.2.7 and Commons Beanutls 1.7.0 reproduces the lock 
 (in
 this example with 10 concurrent threads):
 siege -c10 -r20 localhost:1701/dcw/test.jsp
 = Thread dump is full with threads like this:
 ExecuteThread: '4' for queue: 'weblogic.kernel.Default' daemon prio=1
 tid=0x083859f8 nid=0x76f4 waiting for monitor entry [7628c000..7628c8bc]
 at
 org.apache.commons.beanutils.BeanUtilsBean.getInstance(BeanUtilsBean.java:78)
 - waiting to lock 0x6c86eab0 (a java.lang.Class)
 at
 org.apache.commons.beanutils.PropertyUtilsBean.getInstance(PropertyUtilsBean.java:101)
 at
 org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:290)
 at org.apache.struts.taglib.TagUtils.lookup(TagUtils.java:950)
 at 
 org.apache.struts.taglib.bean.DefineTag.doEndTag(DefineTag.java:230)
 at jsp_servlet.__test._jspService(__test.java:309)
 ...
 This behaviour is new to version 1.7. The same test using Commons Beanutils
 1.6.1 showed no problems: By falling back to the old version we could
 temporarily solve our live problems and could continue to use Struts 1.2.7.
 Nevertheless this should be fixed.

-- 
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] Resolved: (BEANUTILS-251) PropertyUtils.describe() returns wrong fields names


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-251.
---

Resolution: Invalid

 PropertyUtils.describe() returns wrong fields names
 ---

 Key: BEANUTILS-251
 URL: https://issues.apache.org/jira/browse/BEANUTILS-251
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Bean / Property Utils
Affects Versions: 1.7.0
 Environment: WinXP SP2
Reporter: Oleg Timoshenko
Assignee: Henri Yandell
 Fix For: 1.8.0


 I have the following bean:
 public class SumTestBean2 {
   private int iVal;
   public int getIVal() {
   return iVal;
   }
   public void setIVal(int val) {
   iVal = val;
   }
 }
 ... and the following snippet of code:
 SumTestBean2 stb = new SumTestBean2();
 stb.setIVal(12);
 Map map = PropertyUtils.describe(stb);
 for(Object o : map.keySet()) System.out.println(o);
 .. prints out the following:
 IVal
 class
 
 Note that instead of IVal there should be iVal - uppercase letter appears 
 instead of lowercase. 
 This happens only when field has first letter - in lower case followed by 
 uppercase letter.

-- 
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-156) Memory leak on webapp undeploy in MappedPropertyDescriptor


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-156:
--

Summary: Memory leak on webapp undeploy in MappedPropertyDescriptor  (was: 
[beanutils] Memory leak on webapp undeploy in MappedPropertyDescriptor)

 Memory leak on webapp undeploy in MappedPropertyDescriptor
 --

 Key: BEANUTILS-156
 URL: https://issues.apache.org/jira/browse/BEANUTILS-156
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Bean / Property Utils
Affects Versions: 1.6
 Environment: Operating System: All
 Platform: All
Reporter: Simon Kitching
Assignee: Niall Pemberton
 Fix For: 1.8.0


 Class MappedPropertyDescriptor has a Hashtable declaredMethodCache containing 
 a
 mapping from Class to Method[]. If this class were to be deployed via a shared
 webapp, then any reference in there to a class loaded via the webapp 
 classloader
 will prevent the webapp classloader from being garbage-collected when the 
 webapp
 is undeployed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Resolved: (BEANUTILS-156) Memory leak on webapp undeploy in MappedPropertyDescriptor


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-156.
---

Resolution: Fixed

 Memory leak on webapp undeploy in MappedPropertyDescriptor
 --

 Key: BEANUTILS-156
 URL: https://issues.apache.org/jira/browse/BEANUTILS-156
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Bean / Property Utils
Affects Versions: 1.6
 Environment: Operating System: All
 Platform: All
Reporter: Simon Kitching
Assignee: Niall Pemberton
 Fix For: 1.8.0


 Class MappedPropertyDescriptor has a Hashtable declaredMethodCache containing 
 a
 mapping from Class to Method[]. If this class were to be deployed via a shared
 webapp, then any reference in there to a class loaded via the webapp 
 classloader
 will prevent the webapp classloader from being garbage-collected when the 
 webapp
 is undeployed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

[jira] Updated: (BEANUTILS-157) Beanutils's describe() method cannot determine reader methods for anonymous class


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-157:
--

 Assignee: Niall Pemberton
 Priority: Minor  (was: Major)
Affects Version/s: 1.6.1
  Summary: Beanutils's describe() method cannot determine reader 
methods for anonymous class  (was: [beanutils] 1.6.1 cannot determine reader 
methods for anonymous class)

 Beanutils's describe() method cannot determine reader methods for anonymous 
 class
 -

 Key: BEANUTILS-157
 URL: https://issues.apache.org/jira/browse/BEANUTILS-157
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: Bean / Property Utils
Affects Versions: 1.6.1
 Environment: Operating System: Windows XP
 Platform: PC
Reporter: Thorbjørn Ravn Andersen
Assignee: Niall Pemberton
Priority: Minor
 Fix For: 1.8.0


 I have the following snippet in a JSP-page which uses BeanUtils 1.6.1 and I 
 get
 an exception.
 Code snippet (the anonymous class is to get a JavaBean defined in the 
 JSP-page):
 ---
   List l = new ArrayList();
   for(int i = 1; i  10; i++) {
 final int i2 = i;
Object o = new Serializable() {
   String x =  + i2;
   String y =  + (100+i2) ;
   public String getX() {
 return x;
   }
   public String getY() {
 return y;
   }   
   public String toString() {
   return getX() +   + getY();
   }   
   };
   l.add(o);
   Map map = BeanUtils.describe(o);
  ---
 which gives me the following exception:
 ---
 javax.servlet.ServletException: Property 'y' has no getter method
   at
 org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:825)
   at
 org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:758)
   at org.apache.jsp.main_jsp._jspService(main_jsp.java:257)
   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
   at 
 org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
   at 
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292)
   at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
   at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
   at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
   at
 org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:704)
   at
 org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:474)
   at
 org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:409)
   at
 org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:312)
   at 
 com.transaxiom.axsWHSweb.servlet.GetCurrentStock.doPost(GetCurrentStock.java:31)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
   at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
   at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
   at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
   at
 org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
   at 
 org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at
 org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
   at
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
   at
 org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
   at 
 org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
   at
 org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
   at
 org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
   at 
 org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109

Re: request karma to commons validator/i18n

2007-07-06 Thread Niall Pemberton


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.

Niall


Thanks,
Paul


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

Re: request karma to commons validator/i18n

2007-07-06 Thread Niall Pemberton


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

Niall, that's fine by me. You're the lead of the project and I respect your
contributions and leadership. I'll be passing everything by you. No worries.


OK great that will be much appreciated to start with :) Not sure about
the lead business, just seem to have inherited it from others - which
you may do from me.

Niall


Paul

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

 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]





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

[jira] Updated: (BEANUTILS-61) PropertyUtilsBean isReadable() and isWriteable() methods do not work correctly for WrapDynaBean

2007-07-04 Thread Niall Pemberton (JIRA)


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-61:
-

Assignee: Niall Pemberton
 Summary: PropertyUtilsBean isReadable() and isWriteable() methods do not 
work correctly for WrapDynaBean  (was: [beanutils] PropertyUtilsBean does not 
work correctly for WrapDynaBean)

 PropertyUtilsBean isReadable() and isWriteable() methods do not work 
 correctly for WrapDynaBean
 ---

 Key: BEANUTILS-61
 URL: https://issues.apache.org/jira/browse/BEANUTILS-61
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: DynaBean
Affects Versions: Nightly Builds
 Environment: Operating System: other
 Platform: All
Reporter: Brian Ewins
Assignee: Niall Pemberton
Priority: Minor
 Fix For: 1.8.0


 Try this: given any pojo class MyBean.java,
 MyBean orig = new MyBean();
 MyBean dest = new MyBean();
 DynaBean db = new WrapDynaBean(dest);
 PropertyUtils.copyProperties(db, orig);
 You'll see an exception like:
 java.lang.IllegalArgumentException: Property 'class' has no write method
 at 
 org.apache.commons.beanutils.WrapDynaBean.set(WrapDynaBean.java:266)
 This surprised me because 'copyProperties()' does an 'isWritable()' check 
 before
 it sets properties. However, what PropertyUtilsBean.isWritable actually does 
 is
 this:
 if (bean instanceof DynaBean) {
 // All DynaBean properties are writeable
 return (((DynaBean) bean).getDynaClass().getDynaProperty(name) != 
 null);
 } ...
 That's plainly wrong for a WrapDynaBean, since pretty much every wrapped 
 object
 has a non-writable 'class' property. 
 A workaround for the immediate problem:
 if (db instanceof WrapDynaBean) {
   PropertyUtils.copyProperties(((WrapDynaBean) db).getInstance(), src);
 } else {
   PropertyUtils.copyProperties(dest, src);
 }
 ... the problem affects isReadable and isWritable, and hence copyProperties; 
 to
 fix it for all cases would (I think) require unwrapping any WrapDynaBeans 
 passed
 into those calls.
 I guess having a situation where you'd use PropertyUtils /and/ WrapDynaBeans 
 is
 fairly unusual so this is just a minor bug.

-- 
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] Resolved: (BEANUTILS-61) PropertyUtilsBean isReadable() and isWriteable() methods do not work correctly for WrapDynaBean

2007-07-04 Thread Niall Pemberton (JIRA)


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-61.
--

Resolution: Fixed

I have made the following changes:

PropertyUtilsBean:
   - isReadable() and isWriteable() methods now unwrap  any WrapDynaBean as 
you suggest.
   - copyProperties() now checks isReadable() when the source is a DynaBean
 (it already checked isWriteable() for target DynaBean)

BeanUtilsBean
   - copyProperties() now checks isReadable() when the source is a DynaBean
 (it already checked isWriteable() for target DynaBean)

http://svn.apache.org/viewvc?view=revrevision=553357

 PropertyUtilsBean isReadable() and isWriteable() methods do not work 
 correctly for WrapDynaBean
 ---

 Key: BEANUTILS-61
 URL: https://issues.apache.org/jira/browse/BEANUTILS-61
 Project: Commons BeanUtils
  Issue Type: Bug
  Components: DynaBean
Affects Versions: Nightly Builds
 Environment: Operating System: other
 Platform: All
Reporter: Brian Ewins
Assignee: Niall Pemberton
Priority: Minor
 Fix For: 1.8.0


 Try this: given any pojo class MyBean.java,
 MyBean orig = new MyBean();
 MyBean dest = new MyBean();
 DynaBean db = new WrapDynaBean(dest);
 PropertyUtils.copyProperties(db, orig);
 You'll see an exception like:
 java.lang.IllegalArgumentException: Property 'class' has no write method
 at 
 org.apache.commons.beanutils.WrapDynaBean.set(WrapDynaBean.java:266)
 This surprised me because 'copyProperties()' does an 'isWritable()' check 
 before
 it sets properties. However, what PropertyUtilsBean.isWritable actually does 
 is
 this:
 if (bean instanceof DynaBean) {
 // All DynaBean properties are writeable
 return (((DynaBean) bean).getDynaClass().getDynaProperty(name) != 
 null);
 } ...
 That's plainly wrong for a WrapDynaBean, since pretty much every wrapped 
 object
 has a non-writable 'class' property. 
 A workaround for the immediate problem:
 if (db instanceof WrapDynaBean) {
   PropertyUtils.copyProperties(((WrapDynaBean) db).getInstance(), src);
 } else {
   PropertyUtils.copyProperties(dest, src);
 }
 ... the problem affects isReadable and isWritable, and hence copyProperties; 
 to
 fix it for all cases would (I think) require unwrapping any WrapDynaBeans 
 passed
 into those calls.
 I guess having a situation where you'd use PropertyUtils /and/ WrapDynaBeans 
 is
 fairly unusual so this is just a minor bug.

-- 
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] Resolved: (VALIDATOR-231) Missing unit tests using maven

2007-07-03 Thread Niall Pemberton (JIRA)


 [ 
https://issues.apache.org/jira/browse/VALIDATOR-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved VALIDATOR-231.
---

Resolution: Invalid

MultipleTests has already been renamed to MultipleTest in January (revision 
493905)

 Missing unit tests using maven
 --

 Key: VALIDATOR-231
 URL: https://issues.apache.org/jira/browse/VALIDATOR-231
 Project: Commons Validator
  Issue Type: Bug
Affects Versions: 1.3.1 Release
Reporter: Gail Badner

 The maven build uses the file pattern **/*Test.java, so it misses 
 org.apache.commons.validator.MultipleTests. This test is run when using ant.
 MultipleTests should probably be renamed to MultipleTest.
 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: Issue for TLP move

2007-07-03 Thread Niall Pemberton


+1 Looks good to me :)

Niall

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

Hope I captured all the input. So if no one objects I will submit the
following issue to infrastructure

cheers
--
Torsten

-
The board has agreed to create the Commons project. (Please note that
there has been a previous commons TLP)

To aid in the process, would the Infrastructure team please do the
following:

#===

[1] Root Tasks

Create unix group commons. If it already exists remove previous
members.

Add following usernames to group commons:

 antoine
 bayard
 billbarker
 bodewig
 brentworden
 brett
 bspeakmon
 craigmcc
 dennisl
 dflorey
 dfs
 dims
 dion
 dlr
 dmitri
 ebourg
 epugh
 felipeal
 fredrik
 germuska
 ggregory
 hchar
 henning
 hgilde
 imario
 jcarman
 jfclere
 jkeyes
 jmitchell
 jochen
 joehni
 joerg
 knut
 kohsuke
 leosutic
 luc
 martinc
 mbecke
 mbenson
 mrdon
 mturk
 mvdb
 ngn
 niallp
 nuttycom
 oglueck
 oheger
 olegk
 ozeigermann
 pietsch
 polx
 proyal
 psteitz
 rahul
 rdonkin
 rolandw
 roxspring
 rwinston
 sandymac
 scohen
 scolebourne
 sebb
 sgoeschl
 skitching
 stevencaswell
 sullis
 tcurdt
 tobrien
 trygvis
 vgritsenko
 yonik

Verify that domain commons.apache.org is correctly setup.


#===
[1] Mailing List

(i) addresses

 I. [EMAIL PROTECTED]

 * Henri Yandell[EMAIL PROTECTED]
 * Jochen Wiedmann  [EMAIL PROTECTED]
 * Mario Ivankovits [EMAIL PROTECTED]
 * Stephen Colebourne   [EMAIL PROTECTED]
 * Dennis Lundberg  [EMAIL PROTECTED]
 * Niall Pemberton  [EMAIL PROTECTED]
 * Martin van den Bemt  [EMAIL PROTECTED]
 * Oliver Zeigermann[EMAIL PROTECTED]
 * Jörg Schaible[EMAIL PROTECTED]
 * Oliver Heger [EMAIL PROTECTED]
 * Matt Benson  [EMAIL PROTECTED]
 * Martin Cooper[EMAIL PROTECTED]
 * Phil Steitz  [EMAIL PROTECTED]
 * Torsten Curdt[EMAIL PROTECTED]
 * Daniel Savarese  [EMAIL PROTECTED]
 * Rory Winston [EMAIL PROTECTED]
 * Luc Maisonobe[EMAIL PROTECTED]
 * Joerg Pietschmann[EMAIL PROTECTED]
 * Dion Gillard [EMAIL PROTECTED]
 * Brent Worden [EMAIL PROTECTED]
 * Simon Kitching   [EMAIL PROTECTED]
 * Rahul Akolkar[EMAIL PROTECTED]


II. [EMAIL PROTECTED]  subscribers from  commons-
[EMAIL PROTECTED]
   III. [EMAIL PROTECTED]   subscribers from  commons-
[EMAIL PROTECTED]
IV. [EMAIL PROTECTED]   subscribers from  commons-
[EMAIL PROTECTED]
 V. [EMAIL PROTECTED]subscribers from  commons-
[EMAIL PROTECTED]

(ii) remote moderators ...

 I. [EMAIL PROTECTED]   moderators are
[EMAIL PROTECTED],[EMAIL PROTECTED]
II. [EMAIL PROTECTED]  moderators from  commons-
[EMAIL PROTECTED]
   III. [EMAIL PROTECTED]   moderators from  commons-
[EMAIL PROTECTED]
IV. [EMAIL PROTECTED]   moderators from  commons-
[EMAIL PROTECTED]
 V. [EMAIL PROTECTED]moderators from  commons-
[EMAIL PROTECTED]


(iii) archives

I. [EMAIL PROTECTED] to be archived in the private area.
   II. http://commons.apache.org/mail/commons/user/MM.gz
III. http://commons.apache.org/mail/commons/dev/MM.gz
   IV. http://commons.apache.org/mail/commons/commits/MM.gz
V. http://commons.apache.org/mail/commons/issues/MM.gz

(iv) options

I. Reply-To: Header [X] yes [ ] no
   II. Message Trailer  [X] yes [ ] no

#===
[2] Source Control

(i) Subversion

 Move the existing jakarta/commons tree to TLP

(ii) Authorization

 Commit access should be granted to all members of the commons
group [1]

#===
[3] Wiki

(i) Wiki pages need to be migrated

 http://wiki.apache.org/jakarta-commons/FrontPage

 This is/will be done by the community itself.

#===
[4] Bug tracking

(i) Project URLs need to be migrated

 This is/will be done by the community itself.


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

[jira] Commented: (BEANUTILS-287) Missing unit tests using ant and unit test errors using maven

2007-07-03 Thread Niall Pemberton (JIRA)


[ 
https://issues.apache.org/jira/browse/BEANUTILS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509964
 ] 

Niall Pemberton commented on BEANUTILS-287:
---

-1 to generating the build.xml using maven ant - IMO it creates a right mess 
and theres no point ruining a working ant build.xml

 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]

Fwd: [DBCP] Managed Connection support

2007-07-03 Thread Niall Pemberton

Forwarding to Commons Dev...

-- Forwarded message --
From: Dain Sundstrom [EMAIL PROTECTED]
Date: Jul 4, 2007 2:21 AM
Subject: [DBCP] Managed Connection support
To: Jakarta General List [EMAIL PROTECTED]

I just posted a patch JIRA which adds support for container managed
connections to DBCP.  In an environment where you have an accessible
transaction manger such as Tomcat (when installed), Geronimo or
OpenEJB, this patch allows adds support for pooling managed
connections to an XA or non-XA data base.

There are many libraries that use DBCP for non-managed environments,
but when additional resources such as a JMS provider are added to the
mix, they have to replace DBCP with something else.  If you search
google for XA and DBCP, you will loads of painful direction on how to
replace DBCP with something else.  I personally want to use DBCP in
Tomcat with ActiveMQ.

Anyways, enough with motivation

To use the new code, you need access to a TranactionManager (this
code just creates a new Geronimo one).

transactionManager = new TransactionManagerImpl();

Then you either create an XADataSource and
DataSourceXAConectionFactory or as this code does, create a normal
DBCP ConnectionFactory and wrap it with a LocalXAConectionFactory

Properties properties = new Properties();
properties.setProperty(user, username);
properties.setProperty(password, password);
ConnectionFactory connectionFactory = new
DriverConnectionFactory(
new TesterDriver(),
jdbc:apache:commons:testdriver, properties);

// wrap it with a LocalXAConnectionFactory
XAConnectionFactory xaConnectionFactory = new
LocalXAConnectionFactory(
transactionManager,
connectionFactory);

Now you create a pool as normal (full reuse here).

pool = new GenericObjectPool();
pool.setMaxActive(getMaxActive());
pool.setMaxWait(getMaxWait());

// create the pool object factory
PoolableConnectionFactory factory = new
PoolableConnectionFactory(
xaConnectionFactory,
pool,
null,
SELECT DUMMY FROM DUAL,
true,
true);
pool.setFactory(factory);

Finally, you create a special ManagedDataSource using the pool above
and the special TransactionRegistry object obtained from the
XAConnectionFactory.

ds = new ManagedDataSource(pool,
xaConnectionFactory.getTransactionRegistry());
ds.setAccessToUnderlyingConnectionAllowed(true);

That's it.  The data source and connections work as normal until you
start a transaction using the TransactionManager.  When you use a
connection while the transaction is active, the connection is
enlisted in the transaction.  When the transaction is complete, the
connection is committed (or rolledback) and the connection returns to
normal.

Most of the new code extends existing classes or uses existing
classes without modification.  The key to this reuse is the
TransactionRegistry abstraction which maintains a map from the
Connection to the XAResource for that connection.  The XAResource is
needed to enlist a connection in a transaction.  The
TransactionRegistry and associated TransationContext class
encapsulate all interactions with the TransactionManager leaving the
Connection implementation relatively simple (making reuse easier).

For now the code is contained in the org.apache.commons.dbcp.managed
package, but I would suspect we may want to spread it out amongst the
existing packages instead of creating a feature specific package.
I'm also not sure what additional interfaces people may want such as
equivalents of the BasicDataSource or BasicDataSourceFactory.

The code has tests and has javadoc, but it needs real world testing
and some real docs.  I'm going try hooking it into OpenEJB and
running it's massive test suite with a couple of opensource DBs.

Anyways, I hope you all like it and accept the patch.  I'm around to
help with changes or whatever.  I also ran into a few bugs while
working on this that are already reported in JIRA (like the close
bugs) and am willing to help with those also.

-dain

-
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: [io] Tag names (was: svn commit: r552581)

2007-07-02 Thread Niall Pemberton


On 7/2/07, Rahul Akolkar [EMAIL PROTECTED] wrote:

On 7/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Author: jochen
 Date: Mon Jul  2 13:21:44 2007
 New Revision: 552581

 URL: http://svn.apache.org/viewvc?view=revrev=552581
 Log: (empty)

 Added:
 jakarta/commons/proper/io/tags/commons-io-1.3.2/
   - copied from r552580, jakarta/commons/proper/io/branches/b1_3/

snip/

Please use consistent names for release tags. This is a misfit:

 http://svn.apache.org/repos/asf/jakarta/commons/proper/io/tags/

It would be even better, IMO, if you tag RCs and copy the appropriate
one as the release tag.


+1

Niall


-Rahul


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

Re: [beanutils] Public methods overriden in anonymous subclasses

2007-07-01 Thread Niall Pemberton


On 7/1/07, Marcelo Liberato [EMAIL PROTECTED] wrote:

Hi folks,

  did anyone take a look at JIRA ticket BEANUTILS-273? I've attached a patch
for this issue as well.

  The problem occurs when you anonymously subclass a class overriding a
public method. If that method was not declared in any interface by
superclass chain, beanutils fails trying to access it.

  In my patch, I adjusted
MethodUtils.getAccessibleMethodFromInterfaceNestto check for that
method on superclass chain, besides interfaces from
superclass chain (which was already done).

  Let me know if I could help with something else.


Not yet, but it has a target fix version for the next release (i.e.
version 1.8.0) in Jira so its on the to do list :)

Niall


Cheers,
Marcelo Liberato



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

[jira] Commented: (BEANUTILS-285) Consider options for BeanUtils compatibility in light of Conversion improvements


[ 
https://issues.apache.org/jira/browse/BEANUTILS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509364
 ] 

Niall Pemberton commented on BEANUTILS-285:
---

OK I have reverted the behaviour in BeanUtils (and Martin's change to betwixt, 
as the method used by betwixt is now nack to how it was in BeanUtils 1.7.0). If 
I find the time and desire to provide the new behaviour I'll do it as new 
additional implementations (BeanUtilsBean2 / ConvertUtilsBean2) that people can 
chose to configure if they want.

BeanUtils: http://svn.apache.org/viewvc?view=revrevision=552279
Betwixt: http://svn.apache.org/viewvc?view=revrevision=552283

 Consider options for BeanUtils compatibility in light of Conversion 
 improvements
 

 Key: BEANUTILS-285
 URL: https://issues.apache.org/jira/browse/BEANUTILS-285
 Project: Commons BeanUtils
  Issue Type: New Feature
  Components: ConvertUtils  Converters
Affects Versions: 1.8.0
Reporter: Niall Pemberton
Assignee: Niall Pemberton
 Attachments: betwixt-beanutils-gump-fix.patch


 The Conversion improvements associated with BEANUTILS-258 potentially create 
 compatibility issues - this was highlighted by Betwixt's tests failing 
 recently in the gump run - see http://tinyurl.com/2mxbv8 for more details.
 Quite a bit of effort has been put into making the new conversion facilities 
 as painless as possible for existing users. However it is not fully backwards 
 compatible in terms of behaviour (stiil binary compatible). Need to give this 
 some consideration before a BeanUtils release - at the moment there are two 
 options on the table (more welcome!):
 1) The compatibility as it stands is good enough (covers most cases) - so do 
 nothing
 2) Provide a compatibility option - so that users can choose either the new 
 behaviour or behaviour compatible with BeanUtils 1.7.0. This probably 
 involves quite a bit of work - adding back the old behaviour alongside the new

-- 
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-178) New implementation in commons-beanutils


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton updated BEANUTILS-178:
--

Fix Version/s: (was: 1.8.0)
   LATER THAN 1.8.0

Punting to post 1.8.0

The issue with swallowing the SQLExcepton in the createDynaProperty() method 
still exists - although its been refactored into JDBCDynaClass




 New implementation in commons-beanutils
 ---

 Key: BEANUTILS-178
 URL: https://issues.apache.org/jira/browse/BEANUTILS-178
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: DynaBean
Affects Versions: 1.6
 Environment: Operating System: All
 Platform: All
Reporter: Fabio Lourencetti GonÃ§alves
Priority: Minor
 Fix For: LATER THAN 1.8.0


 typing...

-- 
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] Resolved: (BEANUTILS-285) Consider options for BeanUtils compatibility in light of Conversion improvements


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niall Pemberton resolved BEANUTILS-285.
---

   Resolution: Fixed
Fix Version/s: 1.8.0

I have added new BeanUtilsBean (BeanUtilsBean2) and ConvertUtilsBean 
(ConvertUtilsBean2) implementations which take full davantage of the improved 
Converter implementations. The default behaviour is compatible with BeanUtils 
1.7.0, but these new implementations can be configured by calling 
BeanUtilsBean.setInstance(new BeanUtilsBean2()).

http://svn.apache.org/viewvc?view=revrevision=552381

Closing this as resolved

 Consider options for BeanUtils compatibility in light of Conversion 
 improvements
 

 Key: BEANUTILS-285
 URL: https://issues.apache.org/jira/browse/BEANUTILS-285
 Project: Commons BeanUtils
  Issue Type: New Feature
  Components: ConvertUtils  Converters
Affects Versions: 1.8.0
Reporter: Niall Pemberton
Assignee: Niall Pemberton
 Fix For: 1.8.0

 Attachments: betwixt-beanutils-gump-fix.patch


 The Conversion improvements associated with BEANUTILS-258 potentially create 
 compatibility issues - this was highlighted by Betwixt's tests failing 
 recently in the gump run - see http://tinyurl.com/2mxbv8 for more details.
 Quite a bit of effort has been put into making the new conversion facilities 
 as painless as possible for existing users. However it is not fully backwards 
 compatible in terms of behaviour (stiil binary compatible). Need to give this 
 some consideration before a BeanUtils release - at the moment there are two 
 options on the table (more welcome!):
 1) The compatibility as it stands is good enough (covers most cases) - so do 
 nothing
 2) Provide a compatibility option - so that users can choose either the new 
 behaviour or behaviour compatible with BeanUtils 1.7.0. This probably 
 involves quite a bit of work - adding back the old behaviour alongside the new

-- 
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] Resolved: (BEANUTILS-247) Arrays with multiple dimension are not supported