[
https://issues.apache.org/jira/browse/BEANUTILS-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604313#comment-13604313
]
Benedikt Ritter edited comment on BEANUTILS-425 at 3/16/13 4:06 PM:
--------------------------------------------------------------------
Hi Oliver,
for testing the exception handling in {{introspect(IntrospectionContext)}}, I
see two possibilities:
* create an instance delegator that the call to the introspector can be
delegated to. In the test setup simply inject a mock that throws an exception
* create a protected method that delegates to Introspector. In the test case
create a private static TestBeanIntrospector that overrides the method and
throws an exception.
Now both solutions are a bit tricky to implement with the current design,
because of the singleton pattern. For now I think we are good to go with the
82% coverage.
was (Author: britter):
Hi Oliver,
for testing the exception handling in introspect, I see two possibilities:
* create an instance delegator that the call to the introspector can be
delegated to. In the test setup simply inject a mock that throws an exception
* create a protected method that delegates to Introspector. In the test case
create a private static TestBeanIntrospector that overrides the method and
throws an exception.
Now both solutions are a bit tricky to implement with the current design,
because of the singleton pattern. For now I think we are good to go with the
82% coverage.
> 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
