commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: [BeanUtils][Betwixt][commons] [jxpath] Proposal: Reflection/Introspection/MetaData package
Date Mon, 17 Jun 2002 05:29:41 GMT
Don't forget 'simple API'. Most of those tools are warappers around 
reflection APIs - to make it simpler to use. 

If the new stuff becomes too complex ( and the getMethodInfo() seems
not only redundant with the 'real' reflection API, but as complex ) -
there's no benefit. 

It is ok to have some complexity in the impl., but it is essential
to not over-design the architecture. 

Costin

On Sun, 16 Jun 2002, Dmitri Plotnikov wrote:

> 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 believe that before we can propose an architecture, we need to collect the
> requirements. How about we start off by pulling together all of them into
> one set of documents?   I will gladly contribute the "Introspection in
> JXPath" chapter.
> 
> BTW, we'll need a name for this new thing.  How about Jin?
> 
> - Dmitri
> 
> 
> ----- Original Message -----
> From: <costinm@covalent.net>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Sunday, June 16, 2002 11:55 AM
> Subject: Re: [BeanUtils][Betwixt][commons] Proposal:
> Reflection/Introspection/MetaData package
> 
> 
> > 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:
> <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>
> >
> >
> 
> 
> --
> 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