ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Klein" <Adam.Kl...@aqr.com>
Subject RE: bug in javabeans setter (ComplexBeanProbe.java)?
Date Thu, 31 Aug 2006 13:31:49 GMT
My class looks like this:

Public class MyClass {
	HashMap<String,String> myHashMap;
	...		     

	MyClass() {
		// Uncomment to fix bad iBATIS behavior:
		// myHashMap = new HashMap<String,String>();
	}

	public void setMyHashMap(HashMap<String, String> h) {
		// create COPY of h
		if (h == null)
            	myHashMap = null;
	      else if (myHashMap == null)
            	myHashMap = new HashMap<String,String>(h);
        	else {
            	myHashMap.clear();
	            myHashMap.putAll(h);
        	}
	}	

	Public HashMap<String, String> getMyHashMap() {
		return myHashMap;
	}
}


Now, if I use the result map below to generate a List of MyClass
objects, if myHashMap is not initialized to a non-null value in the
constructor (see commented-out line above), the value Key1 is not
assigned value1, because what happens is the code creates a new HashMap
object, say X, and before calling X.put(Key1, Value1), the code calls
setMyHashMap(X), and THEN it calls X.put(Key1, value1), but by this time
X no longer refers to the same object as myHashMap.

Hope this makes sense.

Regards,
  Adam



-----Original Message-----
From: Poitras Christian [mailto:Christian.Poitras@ircm.qc.ca] 
Sent: Wednesday, August 30, 2006 2:01 PM
To: user-java@ibatis.apache.org
Subject: RE: bug in javabeans setter (ComplexBeanProbe.java)?

Can you post a copy of your setters?
I'm not sure what you're trying to ask or to do.

Christian

-----Original Message-----
From: Adam Klein [mailto:Adam.Klein@aqr.com] 
Sent: Tuesday, 29 August 2006 16:41
To: user-java@ibatis.apache.org
Subject: bug in javabeans setter (ComplexBeanProbe.java)?

Apologies if this is posted twice, I don't think my first one made it.

I had implemented defensive copying on my javabean setter methods - ie,
so the value of the bean would be set to a COPY of the parameter  -
while the getter would return a direct reference.  Then, when I was
trying to set keys in an (uninitiailized) HashMap object to values like
this:

<resultMap id="myResultMap" class="MyClass">
	 <result property = myDouble 		column="value0" />
       <result property = myHashMap.Key1 	column="value1" />
       <result property = myHashMap.Key2 	column="value2" />
</resultMap>

I got a very strange result: of the values in myHashMap, only the value
of myHashMap.key2 would be set; in general, the first key of an
(uninitialized) HashMap would never be assigned a value. I traced the
reason to the ComplexBeanProbe.java file, in the setObject method: it
called the method setObject(parent, property, child) prior to calling
setProperty(child, property, value), which meant that the parent.child
object no longer referenced the child object by the time the code
attempted to set values on the child object (due specifically to my
defensive copying).  If myHashMap is initialized to an empty HashMap
value on creation of MyClass, there are no problems.

The question is, is this just a symptom of defensive copying, or is this
a bug, where setProperty(child, property, value) should be called first?

Regards,
  Adam
 
 
 
 
 
Disclaimer: This e-mail may contain confidential and/or privileged
information.  If you are not the intended recipient or have received
this e-mail in error, please notify the sender immediately and
destroy/delete this e-mail.  You are hereby notified that any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly prohibited.
 
This communication is for informational purposes only.  It is not
intended as an offer or solicitation for the purchase or sale of any
financial instrument or as an official confirmation of any transaction.
All information contained in this communication is not warranted as to
completeness or accuracy and is subject to change without notice.  Any
comments or statements made in this communication do not necessarily
reflect those of AQR Capital Management, LLC and its affiliates.

Mime
View raw message