[
https://issues.apache.org/jira/browse/BEANUTILS-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niall Pemberton resolved BEANUTILS-347.
---------------------------------------
Resolution: Fixed
Fix Version/s: 1.8.1
Assignee: Niall Pemberton
Hi, thanks for the test case. I agree with your comment about the first
parameter not being a String for a write method, but I'm reluctant to change
existing behaviour.
I have fixed this so that the method is found after garbage collection
http://svn.apache.org/viewvc?view=rev&revision=806915
> MappedPropertyDescriptor throws an exception after method reference has been
> garbage collected
> ----------------------------------------------------------------------------------------------
>
> Key: BEANUTILS-347
> URL: https://issues.apache.org/jira/browse/BEANUTILS-347
> Project: Commons BeanUtils
> Issue Type: Bug
> Components: Bean / Property Utils
> Affects Versions: 1.8.0
> Reporter: Eickvonder
> Assignee: Niall Pemberton
> Fix For: 1.8.1
>
> Attachments: Jira347TestCase.java
>
>
> If a bean contains a method
> setAnyMapped(anyTypeButString,anyType)
> without a corresponding getter the first calls to getMappedWriteMethod return
> the corresponding method, but if the soft reference to the method has been
> garbage collected the runtime exception 'Method ... for ... could not be
> reconstructed - method not found" is thrown.
> First of all I think it is a bug that getMappedWriteMethod is not invariant
> in its behaviour concerning garbage collection (at least it should not throw
> an exception in this case), but secondly I wonder if it is correct at all
> that constructing a MappedPropertyDescriptor is possible though the first
> parameter is not of type String. But this "odd" behaviour is actually tested
> within MappedPropertyTestCase.testAnyArgsProperty().
> For me I would be fine if either construction of MappedPropertyDescriptor
> would fail or getMappedWriteMethod would return null or the method in both
> cases before and after garbage collection. The only thing that breaks my app
> is the exception being thrown as this is not catched within my call of
> BeanUtils.populate.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.