Bug 1001026

Summary:	apache-commons-beanutils: BeanUtils.copyProperties() incorrectly copying Boolean variables
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Michael Pasternak <mpastern>
Component:	Build	Assignee:	jboss-set
Status:	CLOSED EOL	QA Contact:	Petr Kremensky <pkremens>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	jmartisk, myarboro, oramraz
Target Milestone:	---	Keywords:	TestBlocker
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-08-19 12:49:43 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	985842

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?