RE: bug in javabeans setter (ComplexBeanProbe.java)?
Poitras Christian <Christian.Poitras <at> ircm.qc.ca>
2006-09-01 14:09:42 GMT
This is a good question.
I didn't notice that your HashMap was intialized with the original
HashMap from iBatis when calling new.
I guess your right about it, but it is valid to call 13 at the end (for
simple getter/setter).
Then to correct the problem, the setObject method should be like this.
(1) if (name.indexOf('.') > -1) {
StringTokenizer parser = new StringTokenizer(name, ".");
(2) String property = parser.nextToken();
(3) Object child = object;
(4) while (parser.hasMoreTokens()) {
(5) Class type = getPropertyTypeForSetter(child, property);
(6) Object parent = child;
(7) child = getProperty(parent, property);
(8) if (child == null) {
(9) if (value == null) {
return; // don't instantiate child path if value is null
} else {
try {
(10) child = type.newInstance();
if (!parser.hasMoreTokens()) {
(13) setProperty(child, property, value);
}
(11) setObject(parent, property, child);
} catch (Exception e) {
...
}
}
}
property = parser.nextToken();
}
} else {
setProperty(object, name, value);
}
I can't say this will work for sure, but it is a workaround to test.
If your not dependent on null testing, you could also change the getter
to initialize an empty HashMap. You can also change null testing with
isEmpty(). This is more convenient since it cannot raise unwanted
NullPointerException.
I know iBatis does not handle these types of getter/setter very easilly.
iBatis believes that your gettes/setters are returning/setting the
property without doing any validation or copying or anything else...
Hope this will help.
Christian
-----Original Message-----
From: Adam Klein [mailto:Adam.Klein <at> aqr.com]
Sent: Thursday, 31 August 2006 14:34
To: user-java <at> ibatis.apache.org
Subject: RE: bug in javabeans setter (ComplexBeanProbe.java)?
I don't think solves it. Check out the setObject(...) function in
ComplexBeanProbe.java, listed below, followed by my analysis.
public void setObject(Object object, String name, Object value) {
(1) if (name.indexOf('.') > -1) {
StringTokenizer parser = new StringTokenizer(name, ".");
(2) String property = parser.nextToken();
(3) Object child = object;
(4) while (parser.hasMoreTokens()) {
(5) Class type = getPropertyTypeForSetter(child, property);
(6) Object parent = child;
(7) child = getProperty(parent, property);
(8) if (child == null) {
(9) if (value == null) {
return; // don't instantiate child path if value is null
} else {
try {
(10) child = type.newInstance();
(11) setObject(parent, property, child);
} catch (Exception e) {
...
}
}
}
property = parser.nextToken();
}
(13) setProperty(child, property, value);
} else {
setProperty(object, name, value);
}
}
Here is what happens. Ibatis calls:
setObject(myClass, "myHashMap.key1", "value1")
with myClass = new MyClass(), myHashMap == null, and then:
1. true condition, "myHashMap.key1" has "." in it
2. property = "myHashMap"
3. child = myClass
4. true condition, parser has more tokens 5. type =
"java.util.HashMap"
6. parent = myClass
7. child = myHashMap
8. true condition, child (myHashMap) IS null 9. false condition, value
== "value1", not null 10. child = new HashMap() 11. setObject(parent,
property, child), ie, myClass.myHashMap =
COPY(child)
12. ...
13. setProperty(child, property, value), ie, child.key1 = "value1"
Note that child != myHashMap at step 13 due to the setter's deep
copying. Shouldn't it call setProperty(child, property, value) BEFORE
step 11?
Best,
Adam
-----Original Message-----
From: Poitras Christian [mailto:Christian.Poitras <at> ircm.qc.ca]
Sent: Thursday, August 31, 2006 1:58 PM
To: user-java <at> ibatis.apache.org
Subject: RE: bug in javabeans setter (ComplexBeanProbe.java)?
Ok. I have an answer for this type of problem.
For your resultMap, iBatis will generate objects by calling the
following.
MyClass myClass = new MyClass(); <- iBatis calls instantiate but the
result is the same.
myClass.setMyDouble(value0);
myClass.setMyHashMap(new HashMap()); <- I think this is done.
myClass.getMyHashMap().setKey1(value1);
myClass.getMyHashMap().setKey2(value2);
To get pass your problem, you should change the setter with this.
public void setMyHashMap(HashMap<String, String> h) {
if (myHashMap == null) {
myHashMap = new HashMap<String,String>(h);
}
// create COPY of h
if (h == null)
myHashMap = null;
else {
myHashMap.clear();
myHashMap.putAll(h);
}
}
-----Original Message-----
From: Adam Klein [mailto:Adam.Klein <at> aqr.com]
Sent: Thursday, 31 August 2006 09:32
To: user-java <at> ibatis.apache.org
Subject: RE: bug in javabeans setter (ComplexBeanProbe.java)?
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 <at> ircm.qc.ca]
Sent: Wednesday, August 30, 2006 2:01 PM
To: user-java <at> 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 <at> aqr.com]
Sent: Tuesday, 29 August 2006 16:41
To: user-java <at> 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.
RSS Feed