Bug 1001026 - apache-commons-beanutils: BeanUtils.copyProperties() incorrectly copying Boolean variables
Summary: apache-commons-beanutils: BeanUtils.copyProperties() incorrectly copying Bool...
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Build
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: jboss-set
QA Contact: Petr Kremensky
URL:
Whiteboard:
Depends On:
Blocks: 985842
TreeView+ depends on / blocked
 
Reported: 2013-08-26 11:03 UTC by Michael Pasternak
Modified: 2019-08-19 12:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-19 12:49:43 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Michael Pasternak 2013-08-26 11:03:23 UTC
Description of problem:

BeanUtils.copyProperties() [1] sets default of the primitive boolean (false)
in the wrapper Boolean variable,

[1] apache-commons-beanutils-1.8.3-10.redhat_2.ep6.el6:0.noarch,
(btw latest 1.8.3-12 does not solve the issue)


Steps to Reproduce:
1. create class A with Boolean property X (don't set any value in X)
2. BeanUtils.copyProperties(b, a)
3. b.x is false while should be null

Actual results:

false

Expected results:

null

Comment 1 Michael Pasternak 2013-08-26 11:08:37 UTC
my getters looks like:

    public Boolean getX() {
        return this.x;
    }

Comment 3 Michael Pasternak 2013-09-08 12:24:12 UTC
(In reply to Michael Pasternak from comment #0)
> Description of problem:
> 
> BeanUtils.copyProperties() [1] sets default of the primitive boolean (false)
> in the wrapper Boolean variable,
> 

same is true for all wrapper classes, though PropertyUtils provides an alternative
to BeanUtils, mentioned behaviour is incorrect.

Comment 4 Stuart Douglas 2013-09-18 12:45:20 UTC
Why is this listed as affecting the application client, afaik it does not use bean utils at all. 

Is all that is required here a component upgrade, or does this first need to be fixed up upstream?

Comment 5 Michael Pasternak 2013-09-22 06:36:43 UTC
(In reply to Stuart Douglas from comment #4)
> Why is this listed as affecting the application client, afaik it does not
> use bean utils at all. 
> 

rhev components using it.

> Is all that is required here a component upgrade, or does this first need to
> be fixed up upstream?

i guess so, this is a standard process.

Comment 6 Stuart Douglas 2013-10-01 11:43:37 UTC
(In reply to Michael Pasternak from comment #5)
> (In reply to Stuart Douglas from comment #4)
> > Why is this listed as affecting the application client, afaik it does not
> > use bean utils at all. 
> > 
> 
> rhev components using it.

I still don't see how this affects appclient. I have changed the component to build.

> 
> > Is all that is required here a component upgrade, or does this first need to
> > be fixed up upstream?
> 
> i guess so, this is a standard process.

I mean't does this need to be fixed in beanutils upstream? Or is there a newer version of beanutils that fixes the issue already released?


Note You need to log in before you can comment on or make changes to this bug.