Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 37420 invoked from network); 5 Dec 2001 19:13:37 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 5 Dec 2001 19:13:37 -0000 Received: (qmail 24952 invoked by uid 97); 5 Dec 2001 19:13:39 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 24936 invoked by uid 97); 5 Dec 2001 19:13:38 -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 24925 invoked from network); 5 Dec 2001 19:13:38 -0000 Date: Wed, 5 Dec 2001 19:14:20 +0000 Subject: Re: Digester yielding IllegalAccessException in CallMethodRule, SetNextRule Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v472) From: robert burrell donkin To: "Jakarta Commons Developers List" Content-Transfer-Encoding: 7bit In-Reply-To: <20011205094713.Q51391-100000@localhost> Message-Id: <49485676-E9B4-11D5-8AFE-003065DC754C@mac.com> X-Mailer: Apple Mail (2.472) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wednesday, December 5, 2001, at 06:02 PM, Craig R. McClanahan wrote: > The key is that the third argument to addSetNext() has to match the > method's signature, because this is what is used to do the reflection > lookup. The object on the top of the stack (a StandardHost in the example > above) need only be assignment-compatible with that signature for this to > work. > > Is this the case you're talking about? no. at the moment, you have to specify the third parameter in order to make the digestion work. this isn't too much of limitation - once you know how to do it, it's just a bit of extra typing. where it becomes a bit more restrictive is when you use a general matching rule (like '*'). for example you might have a naming scheme where all child objects are added by calling addChild on the parent. you can write a single general rule only when either each class has an addChild method that takes a specific interface (xxx.yyy.zzz.Child, say). In this case, you can use something like digester.addSetNext("*", "addChild", "xxx.yyy.zzz.Child); you can also write a single general rule if every object has an exactly matching addChild method. In this case you can use digester.addSetNext("*", "addChild"); if your object model doesn't follow one of these two patterns, then even if each object has a method with the right name with an assignment-compatible parameter then the digestion won't work. i'm not suggesting that this is killing functionality but it'd be nice to have if there was an appropriate method finder available... >> jason came across a similar issue with his automatic mapper but it meant >> that he ended up using indexed properties rather than calling an addXXX >> method for children (since beanutils will find an indexed property but >> not >> a name single parameter method). unfortunately, using indexed properties >> means that writing a digester-powered version is not realistic. >> >> i was wondering whether code to do this kind of single parameter method >> finding would fit as part of propertyutils. >> > > PropertyUtils itself is focused only on finding property getters and > setters. But some general utility classes to make some of the really > strange things with Java reflection easier to use (for example, finding a > "compatible" Method rather than just an exact-match Method) would > certainly fit into the overall "beanutils" package. yes, you're right - PropertyUtils does seem like the wrong place. it does have a number of private utility methods which might be useful, i suppose that these could be moved out or given public access, though. - robert -- To unsubscribe, e-mail: For additional commands, e-mail: