Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 65518 invoked from network); 7 Nov 2001 11:06:44 -0000 Received: from unknown (HELO osaka.betaversion.org) (192.18.49.133) by daedalus.apache.org with SMTP; 7 Nov 2001 11:06:44 -0000 Received: (qmail 22853 invoked from network); 7 Nov 2001 11:09:25 -0000 Received: from nagoya.betaversion.org (192.18.49.131) by osaka.betaversion.org with SMTP; 7 Nov 2001 11:09:25 -0000 Received: (qmail 9526 invoked by uid 97); 7 Nov 2001 11:06:54 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 9456 invoked by uid 97); 7 Nov 2001 11:06:51 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 9445 invoked from network); 7 Nov 2001 11:06:50 -0000 Message-ID: From: Rey Francois To: 'Jakarta Commons Developers List' Subject: RE: [beanutils][PATCH] PropertyUtils and indexedProperties Date: Wed, 7 Nov 2001 11:30:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N You can still use your patch in your application. You just have to be aware of the limitation, which I think is substantial though. The advantages I see in the spec of using arrays is that it is a "basic" type allowing type checking, while collections like List are not type safe. Introducing the flexibility to use collections in the spec will of course make it impossible to have type safety, but also it would make life harder for those using non standard collections like the one in Jakarta Commons and JGL. By the way, this issue of type-safety against flexibility also appears for mapped properties. In this case, the non-keyed accessors have to return a type which can only be a Map interface if we want to be the most standard as possible, but of course Map are not type safe. Note that the current implementation is not supporting non-keyed accessors, but it is likely that it will at some point, using the Map interface. Fr. -----Original Message----- From: Tom Klaasen (TeleRelay) [mailto:tom.klaasen@telerelay.com] Sent: 07 November 2001 11:06 To: Jakarta Commons Developers List Subject: RE: [beanutils][PATCH] PropertyUtils and indexedProperties Yes, I read that also, but I also thought that that paragraph didn't say it was exhaustive. Reading it again, I think it implicitly states that though. So forget the patch, you've proven you're right ;-) tomK, who should really buy a JavaBeans book (or read the specs anyway) > -----Original Message----- > From: Rey Francois [mailto:Francois.Rey@capco.com] > Sent: woensdag 7 november 2001 10:38 > To: 'Jakarta Commons Developers List' > Subject: RE: [beanutils][PATCH] PropertyUtils and indexedProperties > > > Well, my understanding of the JavaBean spec is that the only > type allowed > for non-indexed getter/setter of an indexed property is an > array. Reading > the spec 1.01, section 7.2, it does not specify any other type. This > conforms to the JDK 1.3.1 code i've looked at... > Fr. > > -----Original Message----- > From: Tom Klaasen (TeleRelay) [mailto:tom.klaasen@telerelay.com] > Sent: 07 November 2001 10:37 > To: Jakarta Commons Developers List > Subject: RE: [beanutils][PATCH] PropertyUtils and indexedProperties > > > Of course I tried it, but only on Struts (not on a generic javabeans > interpreter like an IDE). And it works for a non indexed > getter based on > List. > > Maybe I got the whole JavaBeans story wrong. However, if what you > describe is the case, then the JavaBeans mechanism seems even less > powerful than I thought. Seems a pity to me. > > Is anybody sure that (s)he understands the JavaBeans spec, and whether > this patch is applicable? > > Thanks, > tomK > > > > > -----Original Message----- > > From: Rey Francois [mailto:Francois.Rey@capco.com] > > Sent: woensdag 7 november 2001 10:22 > > To: 'Jakarta Commons Developers List' > > Subject: RE: [beanutils][PATCH] PropertyUtils and indexedProperties > > > > > > Have you actually tried this code? > > I've only *briefly* looked into the JDK and BeanUtils code, > > so I'm not 100% > > sure of this, but it seems to me that your patch may work > > when your property > > only has non indexed getter/setter based on List, but should > > fail if your > > property also has indexed getter/setter. In the latter case, > > I would expect > > the JDK IndexedPropertyDescriptor class to throw an > > IntrospectionException("type mismatch between indexed and > non-indexed > > methods"). Check the source of > > IndexedPropertyDescriptor.findIndexedPropertyType(). > > > > Again, I'm not 100% sure, I would need to test this but I > > don't have time at > > present... > > > > Fr. > > > > -----Original Message----- > > From: Tom Klaasen (TeleRelay) [mailto:tom.klaasen@telerelay.com] > > Sent: 07 November 2001 09:55 > > To: Jakarta Commons Developers List > > Subject: [beanutils][PATCH] PropertyUtils and indexedProperties > > > > > > Hi all, > > > > I found a glitch in the PropertyUtils: you can only get an > > indexedProperty if its container is an array. But a > java.util.List is > > also indexed. So it would be logical to be able to get an > element of a > > List also as an indexedProperty. > > > > Hence the patch attached. > > > > Hope you enjoy it, > > > > tomK > > ************************************************************** > > ********** > > The information in this email is confidential and is intended solely > > for the addressee(s). > > Access to this email by anyone else is unauthorised. If you are not > > an intended recipient, please notify the sender of this email > > immediately. You should not copy, use or disseminate the > > information contained in the email. > > Any views expressed in this message are those of the individual > > sender, except where the sender specifically states them to be > > the views of Capco. > > > http://www.capco.com > ************************************************************** > ********* > > > -- > To unsubscribe, e-mail: > > For additional commands, e-mail: > > > > -- > To unsubscribe, e-mail: > > For additional commands, e-mail: > > ************************************************************** > ********** > The information in this email is confidential and is intended solely > for the addressee(s). > Access to this email by anyone else is unauthorised. If you are not > an intended recipient, please notify the sender of this email > immediately. You should not copy, use or disseminate the > information contained in the email. > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be > the views of Capco. > http://www.capco.com *********************************************************************** -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: ************************************************************************ The information in this email is confidential and is intended solely for the addressee(s). Access to this email by anyone else is unauthorised. If you are not an intended recipient, please notify the sender of this email immediately. You should not copy, use or disseminate the information contained in the email. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Capco. http://www.capco.com *********************************************************************** -- To unsubscribe, e-mail: For additional commands, e-mail: