[
https://issues.apache.org/jira/browse/BEANUTILS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13598624#comment-13598624
]
Benedikt Ritter commented on BEANUTILS-425:
-------------------------------------------
{quote}
Renaming {{getCurrentClass()}} to {{getClass()}} is probably a bad idea because
this conflicts with the {{getClass()}} method inherited from {{Object}}.
{quote}
Ouch :) Okay, I see the problem. How about {{getTarget()}}?
About test coverage: If you run {{mvn site}} on trunk it should generate a
cobertura report, because I updated to the lastest commons parent.
> Support customization of introspection mechanism
> ------------------------------------------------
>
> Key: BEANUTILS-425
> URL: https://issues.apache.org/jira/browse/BEANUTILS-425
> Project: Commons BeanUtils
> Issue Type: New Feature
> Components: Bean / Property Utils
> Affects Versions: 1.8.3
> Reporter: Oliver Heger
> Assignee: Oliver Heger
> Priority: Minor
> Attachments: beanutils-425.patch
>
>
> So far BeanUtils can cope with properties conforming to the Java Beans
> specification. In some situations it makes sense to relax this requirement
> and allow the detection of other forms of get and set methods as well.
> For instance, fluent APIs have become popular. Here you have a set method
> which does not return *void* and thus violates the Java Beans specification.
> Objects using such an API cannot be dealt with by BeanUtils currently.
> For reasons of backwards compatibility the current behavior should remain the
> default. But it would be cool if there was an option to set a custom
> introspection policy. The policy would be invoked during property discovery
> and can decide which properties to include or not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
