commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: [BeanUtils][Betwixt][commons] [jxpath] Proposal: Reflection/Introspection/MetaData package
Date Mon, 17 Jun 2002 00:37:00 GMT
You should take a look on the discussions about DynaBeans.

Although I do not like the current DynaBeans interfaces (too complex)
I implemented something similar and I am an enthusiastic of the basic
idea.

One of the strengths of a DynaBean is that you can use a DynaBean
interface to build a wrapper over many kinds of data. I use my
DynaBean equivalent (IRecord) to implement wrappers for
 - Java Beans;
 - JDBC ResultSets;
 - HttpRequest parameters;
 - XML elements;
 - etc.

I use an introspector for each kind of data, but the Record/DynaBean,
the Converter and a couple of other utility classes are what makes
the introspection bit really useful.


Maybe you were already thinking this way, but I just did not notice
any reference to the DynaBeans in this thread.


Have fun,
Paulo Gaspar


> -----Original Message-----
> From: Dmitri Plotnikov [mailto:dmitri@apache.org]
> Sent: Sunday, June 16, 2002 8:41 PM
> To: Jakarta Commons Developers List
> Subject: Re: [BeanUtils][Betwixt][commons] [jxpath] Proposal:
> Reflection/Introspection/MetaData package
>
>
> I agree completely.  I was not suggesting tying it to beans, just
> elevating
> it over reflection, this is why I proposed "introspection" istead of
> "beans".  But, I am not really opposed to "reflect" either.
>
> - Dmitri
>
>
> ----- Original Message -----
> From: "Stephen Colebourne" <scolebourne@btopenworld.com>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> Sent: Sunday, June 16, 2002 2:26 PM
> Subject: Re: [BeanUtils][Betwixt][commons] [jxpath] Proposal:
> Reflection/Introspection/MetaData package
>
>
> > Actually I explicitly don't want to tie it to beans. Beans is a widely
> used
> > convention, but there are others
> > -  EJBs are not really beans
> > -  the naming convention surname() instead of getSurname() and
> > surname(String) instead of setSurname()
> > - classes that are auto generated from a 3rd party (non Java) source, eg
> > CORBA IDL generated classes.
> >
> > Thus 'reflect'
> >
> > Stephen
> >
> > From: "Dmitri Plotnikov" <dmitri@apache.org>
> > > Calling it "reflect" makes it analogous to java.lang.reflect.  But, I
> > > believe what we are after is something analogous to "java.beans" -
> that's
> > > where the standard Introspector is.
> > >
> > > How about "introspection",  "org.apache.commons.introspection"?
> > >
> > > - Dmitri
> > >
> > > > ----- Original Message -----
> > > > From: "Stephen Colebourne" <scolebourne@btopenworld.com>
> > > > To: "Jakarta Commons Developers List"
> <commons-dev@jakarta.apache.org>
> > > > Sent: Sunday, June 16, 2002 1:36 PM
> > > > Subject: Re: [BeanUtils][Betwixt][commons] [jxpath] Proposal:
> > > > Reflection/Introspection/MetaData package
> > > >
> > > >
> > > > > [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>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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