Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 26966 invoked from network); 16 Jun 2002 18:52:21 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Jun 2002 18:52:21 -0000 Received: (qmail 409 invoked by uid 97); 16 Jun 2002 18:52:28 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 393 invoked by uid 97); 16 Jun 2002 18:52:28 -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 381 invoked by uid 98); 16 Jun 2002 18:52:27 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) From: Ola Berg To: commons-dev@jakarta.apache.org Reply-To: Ola Berg MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: Tripnet Webmail (IMP/PHP) Sender: ola.berg@arkitema.se Subject: Re: [reflect] Proposal: (WAS [BeanUtils] etc...) Message-Id: Date: Sun, 16 Jun 2002 20:52:20 +0200 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N >The multitude of potential users of this component is >huge, they all have >current solutions and they all have some peculiarities about them. �For this >new component to be successful, we will need to address all of those >requirements, which calls for an abstract, configurable and customizable >architecture. I don\'t agree. Well, of course there are many users that do a lot of stuff in their reflection/introspection packages. But IMO reflect should be a mere utility for easy use of reflection (reducing complexity and awkwardness in java.lang.reflect). Other cool things (like automatic configuration of beans from command line or config files) do belong in other packages (both examples above should go in a Configuration framework?). Those are _users_ of reflection, they don\'t faciliate reflection in themselves. This doesn\'t call for plugable architectures, and if we end up with it I believe that we have over-engineered them and missed a clean separation of concerns. I think of a Reflection class with static methods like Reflection.set( Object bean, String propertyName, Object value); Object o = Reflection.get( Object bean, String propertyName); Reflection.add( Object bean, String propertyName, Object value); Reflection.put( Object bean, String propertyName, Object key, Object value); Reflection.set( Object bean, String propertyName, int index, Object value); Object result = Reflection.call( Object bean, String methodName, Object [] parameterValues); The internals of a Reflection class could very well use a plugable framework for insertion of new handy methods and cached lookup of reflection Method objects (like all getters in a class etc), and some of this functionality should probably be pluggable (for people to insert new bean-like naming conventions, maybe using Predicate on methods). But main functionality exposed as handy methods. /O -------------------- ola.berg@arkitema.se 0733 - 99 99 17 -- To unsubscribe, e-mail: For additional commands, e-mail: