Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 62683 invoked from network); 16 Jun 2002 15:56:35 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Jun 2002 15:56:35 -0000 Received: (qmail 10136 invoked by uid 97); 16 Jun 2002 15:56:30 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 10116 invoked by uid 97); 16 Jun 2002 15:56:29 -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 10104 invoked by uid 98); 16 Jun 2002 15:56:29 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Sun, 16 Jun 2002 08:55:25 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Jakarta Commons Developers List Subject: Re: [BeanUtils][Betwixt][commons] Proposal: Reflection/Introspection/MetaData package In-Reply-To: <1024237183.11296.702.camel@swami> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N See also o.a.tomcat.util.IntrospectionUtils :-) It also have a nice feature - it takes an args[], and using introspection calls the setters, using "-name value" or "-name", based on the method signatures - setName( boolean ) or setName( String/int/whatever ) I personally find it very usefull - with a main() and 2 lines of code you can get a class that works as an Ant task or a bean or CLI. I would also count the axis introspection classes, and probably few others. Costin On 16 Jun 2002, Martin van den Bemt wrote: > Also check this with the ant team, who have a lot of introspection in > there code.. It works on all jdk versions afaik. > See o.a.tools.ant.Introspectionhelper. > > +1 on the idea btw.. > > Mvgr, > Martin > > On Sun, 2002-06-16 at 13:40, Stephen Colebourne wrote: > > Hi, > > Currently, Betwixt and other users of BeanUtils rely on the java.beans class > > Introspector to extract details from a class. Introspector is a very old and > > limited class in todays terms: > > - it doesn't support collections, just simple objects and arrays > > - it doesn't support modern conventions such as addXxx() adds to a the xxx > > list > > - it doesn't support overloading well > > - the bean info technique is difficult to code, poorly understood and > > limiting > > - it's just too plain dumb. > > > > I propose that BeanUtils/Betwixt/commons should replace Introspector with a > > more general purpose reflection/introspection package. Architecturally this > > would sit above reflection, but below Introspection: > > > > Requirements/Goals: > > - handle classes other than beans > > - support extensible metadata (not just for GUI builders) > > - handle normal (today) bean conventions (get/set/add/put methods) > > - handle future conventions that are not yet standard > > - support method overloading > > - be easily used directly from BeanUtils and Betwixt (and probably others) > > - be a complete alternative to using java.lang.reflect > > - return immutable objects > > > > My proposed solution (not coded, fully open to discussion): > > Build a system with similarities to Digester. Rules get called when the > > class is examined determine how to link the methods together. For example > > the FindGetPropertyMethodRule would look at method names starting with get > > etc. The rule then classifies the method as a GET method and stores it into > > a structure something like this: > > > > - MethodSetInfo - holds details about a related set of methods. > > public String getName() > > public List getMethodInfos() > > public MethodInfo getMethodInfo(name) > > public Map getMetaData() > > public MetaData getMetaData(String name) > > > > - ClassInfo - main class that holds the representation of class. Subclass of > > MethodSetInfo > > public List getMethodSetInfos() > > public MethodSetInfo getMethodSetInfo(name) > > public List getMethodSetInfos(methodSetType) > > public MethodSetInfo getMethodSetInfo(methodSetType, name) > > public PropertyInfo getPropertyInfo(name) // convenience > > > > - PropertyInfo - subclass of MethodSetInfo for properties (Lists/Maps etc. > > tbd) > > public Class getPropertyType() > > public MethodInfo getGetMethodInfo() // convenience > > public MethodInfo getSetMethodInfo() // convenience > > public Object getValue() > > public void setValue() > > > > - MethodInfo - categorised info about a method > > public String getName() > > public Method getMethod() > > publc String getCategory() > > public Map getMetaData() > > public MetaData getMetaData(String name) > > public Object invoke(object, args, respectAccessFlags) > > > > Attached to each element is the ability to hold MetaData. This is > > particularly important for Betwixt. It would allow the XMLBeanInfo class to > > be held directly on the representation of the class. And I'm sure other > > projects want MetaData - its supposed to be a long standing request for J2SE > > (I know I need it for the Joda project). > > > > Note that I haven't expanded on the Rule part at the moment. Basically, > > people must be able to write their own rules and add them to the standard > > rules for beans. > > > > As for which project it belongs with...I suggest lang or something new > > (reflect?). I would like to extract it from BeanUtils because its not Bean > > specific. > > > > > > Well, its an idea at the moment. There are some similarities to DynaBeans, > > but I think it goes way further. I already have a partial version of this, > > but its specific to my needs. It needs some rework anyway, so I thought > > about if it could be generic. Opinions?? > > > > Stephen > > > > PS. Three more possibilities for lang: > > Nameable > > MetaData > > Rule > > > > > > > > -- > > To unsubscribe, e-mail: > > For additional commands, e-mail: > > > > > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: