PropertyUtils
Hi everyone, I have some insert and update actions where I copy the data the user entered from the ActionForm to a DTO object which I send as a parameter to my business method. Since I can not conform the validity of the entered data before validation, all the attributes in my ActionForm are of type String. My DTO on the other hand has type safe fields. In my Action class, since I know validation has been done successfully, I start copying the values from type String fields to the type safe fields. Someone once advised me that I don't have to do this manually, and that I can use the PropertyUtils class from the org.apache.commons.beanutils package to do this. I just tried that and it failed. I looked at the documentation and I found several statements that say that type conversion is not supported. So, the properties either have to be both Strings or both Integers for example. Can someone please advise me if constraint is true. Or is there another way to automate this task? Any help is appreciated. Tarek Nabil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PropertyUtils
I could be mistaken, but I think what you want to look at is BeanUtils.copyProperties. Erik tarek.nabil wrote: Hi everyone, I have some insert and update actions where I copy the data the user entered from the ActionForm to a DTO object which I send as a parameter to my business method. Since I can not conform the validity of the entered data before validation, all the attributes in my ActionForm are of type String. My DTO on the other hand has type safe fields. In my Action class, since I know validation has been done successfully, I start copying the values from type String fields to the type safe fields. Someone once advised me that I don't have to do this manually, and that I can use the PropertyUtils class from the org.apache.commons.beanutils package to do this. I just tried that and it failed. I looked at the documentation and I found several statements that say that type conversion is not supported. So, the properties either have to be both Strings or both Integers for example. Can someone please advise me if constraint is true. Or is there another way to automate this task? Any help is appreciated. Tarek Nabil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] PropertyUtils internals (Re: Select Multiple Issues)
At 9:14 PM -0700 1/24/05, Larry Meadors wrote: Nope, actually, it is bean-utils that is at fault here (something all struts developers should be accustomed to saying - IMO, bean-utils is the single weakest component in struts). According to the javabeans specification (http://java.sun.com/products/javabeans/docs/spec.html), indexed properties should look like this: 1) void setter(int index, PropertyType value); // indexed setter 2) PropertyType getter(int index); // indexed getter 3) void setter(PropertyType values[]); // array setter 4) PropertyType[] getter(); // array getter But the last time I looked, bean-utils never used the indexed getter/setter methods (#1 or #2) - in fact, it never even called the array setter (#3). Instead, it got a reference to the array by calling method #4, and set the elements in it directly. I haven't actually looked at this in a running debugger, or with log output, but the code which governs this ultimately is PropertyUtilsbean.setIndexedProperty(...) If you look at the code, you'll see that it uses an IndexedPropertyDescriptor if that's what the Java introspector returns when asked for the write method for the given property. The #4 option is only used when the Introspector returns a PropertyDescriptor which is not also an IndexedPropertyDescriptor. http://cvs.apache.org/viewcvs.cgi/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java?view=markup So, I'm wondering what has you so bothered about beanutils? There was some discussion about a year ago about trying to apply some of the strengths of the cglib project to make beanutils better, but that hasn't seemed to go anywhere (http://cglib.sourceforge.net). My understanding is that cglib is a much higher performing way of doing introspection, but I haven't spent much time looking at it, or how it might fit in with (or replace) beanutils. Joe Larry On Mon, 24 Jan 2005 15:39:44 -0700, Wendy Smoak [EMAIL PROTECTED] wrote: From: Will Stranathan [EMAIL PROTECTED] Well, I understand the way HTTP is working there, it just SEEMS to be that having the additional method (setBar(int, String)) confused BeanUtils or something - because removing those methods (making no other changes) cleared the problem up. Your original code violated the JavaBeans specification-- you're only allowed one pair of get/set methods, and the types have to match. (Boolean properties have slightly different rules.) Any additional methods will, as you found out, confuse the introspection process. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] PropertyUtils internals (Re: Select Multiple Issues)
There are two things about BU that irritate me (and that is the level - irritation, not a show stopper by any stretch of the imagination). 1) If I have an Integer (or any Number subclass) property, and someone keys in joe, BU turns it into 0 by default. That is the last thing I want it to do. Zero is a number, joe is not - BU should not try to make it one, it should be null. 2) The static nature of BU makes it a bit funky to customize. I have not tried to do this myself, but several developers who I know have, and cuss about it. It would be cool to be able to specify property conversions at a more granular level - not at the classloader (i.e., static) level. Larry On Tue, 25 Jan 2005 08:21:27 -0600, Joe Germuska [EMAIL PROTECTED] wrote: At 9:14 PM -0700 1/24/05, Larry Meadors wrote: Nope, actually, it is bean-utils that is at fault here (something all struts developers should be accustomed to saying - IMO, bean-utils is the single weakest component in struts). According to the javabeans specification (http://java.sun.com/products/javabeans/docs/spec.html), indexed properties should look like this: 1) void setter(int index, PropertyType value); // indexed setter 2) PropertyType getter(int index); // indexed getter 3) void setter(PropertyType values[]); // array setter 4) PropertyType[] getter(); // array getter But the last time I looked, bean-utils never used the indexed getter/setter methods (#1 or #2) - in fact, it never even called the array setter (#3). Instead, it got a reference to the array by calling method #4, and set the elements in it directly. I haven't actually looked at this in a running debugger, or with log output, but the code which governs this ultimately is PropertyUtilsbean.setIndexedProperty(...) If you look at the code, you'll see that it uses an IndexedPropertyDescriptor if that's what the Java introspector returns when asked for the write method for the given property. The #4 option is only used when the Introspector returns a PropertyDescriptor which is not also an IndexedPropertyDescriptor. http://cvs.apache.org/viewcvs.cgi/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java?view=markup So, I'm wondering what has you so bothered about beanutils? There was some discussion about a year ago about trying to apply some of the strengths of the cglib project to make beanutils better, but that hasn't seemed to go anywhere (http://cglib.sourceforge.net). My understanding is that cglib is a much higher performing way of doing introspection, but I haven't spent much time looking at it, or how it might fit in with (or replace) beanutils. Joe Larry On Mon, 24 Jan 2005 15:39:44 -0700, Wendy Smoak [EMAIL PROTECTED] wrote: From: Will Stranathan [EMAIL PROTECTED] Well, I understand the way HTTP is working there, it just SEEMS to be that having the additional method (setBar(int, String)) confused BeanUtils or something - because removing those methods (making no other changes) cleared the problem up. Your original code violated the JavaBeans specification-- you're only allowed one pair of get/set methods, and the types have to match. (Boolean properties have slightly different rules.) Any additional methods will, as you found out, confuse the introspection process. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] PropertyUtils internals (Re: Select Multiple Issues)
At 7:58 AM -0700 1/25/05, Larry Meadors wrote: There are two things about BU that irritate me (and that is the level - irritation, not a show stopper by any stretch of the imagination). 1) If I have an Integer (or any Number subclass) property, and someone keys in joe, BU turns it into 0 by default. That is the last thing I want it to do. Zero is a number, joe is not - BU should not try to make it one, it should be null. 2) The static nature of BU makes it a bit funky to customize. I have not tried to do this myself, but several developers who I know have, and cuss about it. It would be cool to be able to specify property conversions at a more granular level - not at the classloader (i.e., static) level. Actually, for quite a while now, the important parts of BeanUtils have been performed by instances: BeanUtilsBean, PropertyUtilsBean, ConvertUtilsBean etc. The static methods just do this against a singleton instance. A lot of legacy code continues to use the static methods, but you're not stuck with it. Given this, (1) is manageable also; you can register an IntegerConverter with a default value of null. I'm not sure what it would do if you registered it against Integer.TYPE, but it should work against Integer.class. Now, Struts is one of the places with legacy code which uses the static methods. If you decide to get into this, your suggestions on how Struts might make it easier for you to configure these things would be welcomed. It might be as simple as creating a chain command which could be used in place of the current PopulateForm step, or pursuing an idea Ted mentioned once about putting a populate method on ActionForm (although I would want to do this in a way which didn't depend directly on HttpServletRequest.) Joe Larry On Tue, 25 Jan 2005 08:21:27 -0600, Joe Germuska [EMAIL PROTECTED] wrote: At 9:14 PM -0700 1/24/05, Larry Meadors wrote: Nope, actually, it is bean-utils that is at fault here (something all struts developers should be accustomed to saying - IMO, bean-utils is the single weakest component in struts). According to the javabeans specification (http://java.sun.com/products/javabeans/docs/spec.html), indexed properties should look like this: 1) void setter(int index, PropertyType value); // indexed setter 2) PropertyType getter(int index); // indexed getter 3) void setter(PropertyType values[]); // array setter 4) PropertyType[] getter(); // array getter But the last time I looked, bean-utils never used the indexed getter/setter methods (#1 or #2) - in fact, it never even called the array setter (#3). Instead, it got a reference to the array by calling method #4, and set the elements in it directly. I haven't actually looked at this in a running debugger, or with log output, but the code which governs this ultimately is PropertyUtilsbean.setIndexedProperty(...) If you look at the code, you'll see that it uses an IndexedPropertyDescriptor if that's what the Java introspector returns when asked for the write method for the given property. The #4 option is only used when the Introspector returns a PropertyDescriptor which is not also an IndexedPropertyDescriptor. http://cvs.apache.org/viewcvs.cgi/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/PropertyUtilsBean.java?view=markup So, I'm wondering what has you so bothered about beanutils? There was some discussion about a year ago about trying to apply some of the strengths of the cglib project to make beanutils better, but that hasn't seemed to go anywhere (http://cglib.sourceforge.net). My understanding is that cglib is a much higher performing way of doing introspection, but I haven't spent much time looking at it, or how it might fit in with (or replace) beanutils. Joe Larry On Mon, 24 Jan 2005 15:39:44 -0700, Wendy Smoak [EMAIL PROTECTED] wrote: From: Will Stranathan [EMAIL PROTECTED] Well, I understand the way HTTP is working there, it just SEEMS to be that having the additional method (setBar(int, String)) confused BeanUtils or something - because removing those methods (making no other changes) cleared the problem up. Your original code violated the JavaBeans specification-- you're only allowed one pair of get/set methods, and the types have to match. (Boolean properties have slightly different rules.) Any additional methods will, as you found out, confuse the introspection process. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
Re: [OT] PropertyUtils internals (Re: Select Multiple Issues)
From: Joe Germuska [EMAIL PROTECTED] I haven't actually looked at this in a running debugger, or with log output, but the code which governs this ultimately is PropertyUtilsbean.setIndexedProperty(...) I found what I think is an open bug about the original issue that was raised-- BeanUtils being unable to set a property when both setProp(int, String) and setProp( String[]). (Actually the bug is about the 'get' side of the problem, but I'm betting it's the same issue.) http://issues.apache.org/bugzilla/show_bug.cgi?id=28358 I added the beginnings of a test case to demonstrate the problem with setting an indexed property when the bean has both setProp(String[]) and setProp(int, String) methods. It fails with the same 'argument type mismatch' that Will Stranathan was getting. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] PropertyUtils internals (Re: Select Multiple Issues)
Yeah, I wonder about that bug: we've recently been moving some application servers from Solaris to Linux, and I think this is a JVM level issue. Just before we started, someone had posted about this to the Struts users' list (although I can't seem to find it in the archives right now.) Basically, it seemed that the introspection behaved differently on Linux than on some other OS. Odd as it seems, we experienced the same problem moving from Solaris to Linux, even using the same version of the Hotspot JVM. It seemed to go back to a property which was actually a List and not an array, and I assumed it had to do with some subtle variation in the interpretation of the javabeans naming conventions. This may or may not be exactly the same thing as in Bug 28358, but it was peculiar. In this case, we were able to simply move a few things around, but it was disconcerting to think that we might be bitten by issues like this in migrating 100% pure java. Joe At 9:05 AM -0700 1/25/05, Wendy Smoak wrote: From: Joe Germuska [EMAIL PROTECTED] I haven't actually looked at this in a running debugger, or with log output, but the code which governs this ultimately is PropertyUtilsbean.setIndexedProperty(...) I found what I think is an open bug about the original issue that was raised-- BeanUtils being unable to set a property when both setProp(int, String) and setProp( String[]). (Actually the bug is about the 'get' side of the problem, but I'm betting it's the same issue.) http://issues.apache.org/bugzilla/show_bug.cgi?id=28358 I added the beginnings of a test case to demonstrate the problem with setting an indexed property when the bean has both setProp(String[]) and setProp(int, String) methods. It fails with the same 'argument type mismatch' that Will Stranathan was getting. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
