commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@multitask.com.au
Subject Re: [BeanUtils][Betwixt][commons] Proposal: Reflection/Introspection/MetaData package
Date Sun, 16 Jun 2002 15:06:39 GMT
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 <mllist@mvdb.net>
06/17/02 12:19 AM
Please respond to "Jakarta Commons Developers List"

 
        To:     Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
        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:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>





--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message