commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [BeanUtils][Betwixt][commons] [jxpath] Proposal: Reflection/Introspection/MetaData package
Date Sun, 16 Jun 2002 17:36:21 GMT
[Merged reply]
Thanks for the encouragement!

Replies have mentioned:
 BeanUtils
 Betwixt
 JXpath
 ANT
 Velocity
 Tomcat
 Axis
There's some homework there! But it does show that the reflection API in
Java is proving to be too low level. Perfect for commons ;-)

I agree with the view that rushing into this one will be a bad idea. So some
requirements gathering makes sense to me. This would need to be a community
effort, and written chapters could be the solution. But I also like to have
some code present just to get people talking.

Name: I was going to propose 'reflect' as I prefer names close to what the
thing does for low level components.

Also, thanks for offers of committing on this. Hopefully we can get off to a
good start with lots of input.

It has been suggested that I should just create a new folder in the sandbox
and begin. Er, slight problem with that - I'm not a committer (anywhere on
Apache). Not sure how you want to deal with that?

Stephen

----- Original Message -----
From: "Dmitri Plotnikov" <dmitri@apache.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Sunday, June 16, 2002 6:15 PM
Subject: Re: [BeanUtils][Betwixt][commons] [jxpath] Proposal:
Reflection/Introspection/MetaData package


> 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