I think it must be a lot of code about this and it can be reused.
> As does Velocity....I think it calls it UberIntrospector or something..... > -- > dIon Gillard, Multitask Consulting > Work: http://www.multitask.com.au > Developers: http://adslgateway.multitask.com.au/developers > > > > > Martin van den Bemt <[EMAIL PROTECTED]> > 06/17/02 12:19 AM > Please respond to "Jakarta Commons Developers List" > > > To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > cc: > Subject: Re: [BeanUtils][Betwixt][commons] Proposal: > Reflection/Introspection/MetaData package > > > 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: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
