You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Juozas Baliuka <ba...@centras.lt> on 2002/06/16 20:09:31 UTC
[VOTE] new commiter Stephen Colebourne was [BeanUtils][Betwixt][commons] [jxpath] Proposal: Reflection/Introspection/MetaData package
I want to nominate Stephen Colebourne as commiter on commons and sandbox,
He is one of the most active contributors with the great ideas and we know
his code.
I think we need to give him chance to do more for commons project.
We will need him in new project for reflection/introspection, proposal you
can find on this list( [BeanUtils][Betwixt][commons] [jxpath] Proposal:
Reflection/Introspection/MetaData package)
+1
> Steven,
>
> First, if you have not yet, read
http://jakarta.apache.org/site/roles.html.
>
> Second, write a "hello, world" message to commons-dev@jakarta.apache.org,
so
> that people know what your credentials are. If you aready have, re-post
it,
> because people tend to forget. If you have contributed to any open source
> projects, don't forget to mention that. Say in that message that you
would
> like to become a committer on this new project. Since the project is going
> to the sandbox first, I don't think anybody will have an objection. Then
> somebody will recommend you as a contributor. Then people will vote.
Done.
>
> - Dmitri
>
>
>
> ----- Original Message -----
> From: "Stephen Colebourne" <sc...@btopenworld.com>
> To: "Jakarta Commons Developers List" <co...@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" <dm...@apache.org>
> > To: "Jakarta Commons Developers List" <co...@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: <co...@covalent.net>
> > > To: "Jakarta Commons Developers List" <co...@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:
> > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] new commiter Stephen Colebourne was
[BeanUtils][Betwixt][commons] [jxpath] Proposal:
Reflection/Introspection/MetaData package
Posted by Dmitri Plotnikov <dm...@apache.org>.
I believe the project will greatly benefit from Stephen's direct
participation.
+1
- Dmitri
----- Original Message -----
From: "Stephen Colebourne" <sc...@btopenworld.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, June 16, 2002 2:33 PM
Subject: Re: [VOTE] new commiter Stephen Colebourne was
[BeanUtils][Betwixt][commons] [jxpath] Proposal:
Reflection/Introspection/MetaData package
> Thanks for the nomination. To comply with Dimitris suggestion, here are my
> credentials:
> 8 years commercial coding experience
> Java coding almost exclusively since late version JDK1.0
> Started Open Source work December 2001 by creating www.joda.org, mission
to
> redefine beans and dates
> Active verbal contributer to Apache commons
> Active contributer to commons collections (PredicateUtils, plus others in
> discussion)
> ;-)
>
> ----- Original Message -----
> From: "Juozas Baliuka" <ba...@centras.lt>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Sunday, June 16, 2002 7:09 PM
> Subject: [VOTE] new commiter Stephen Colebourne was
> [BeanUtils][Betwixt][commons] [jxpath] Proposal:
> Reflection/Introspection/MetaData package
>
>
> >
> > I want to nominate Stephen Colebourne as commiter on commons and
sandbox,
> > He is one of the most active contributors with the great ideas and we
know
> > his code.
> > I think we need to give him chance to do more for commons project.
> > We will need him in new project for reflection/introspection, proposal
you
> > can find on this list( [BeanUtils][Betwixt][commons] [jxpath] Proposal:
> > Reflection/Introspection/MetaData package)
> > +1
> >
> >
> > > Steven,
> > >
> > > First, if you have not yet, read
> > http://jakarta.apache.org/site/roles.html.
> > >
> > > Second, write a "hello, world" message to
> commons-dev@jakarta.apache.org,
> > so
> > > that people know what your credentials are. If you aready have,
re-post
> > it,
> > > because people tend to forget. If you have contributed to any open
> source
> > > projects, don't forget to mention that. Say in that message that you
> > would
> > > like to become a committer on this new project. Since the project is
> going
> > > to the sandbox first, I don't think anybody will have an objection.
> Then
> > > somebody will recommend you as a contributor. Then people will vote.
> > Done.
> > >
> > > - Dmitri
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Stephen Colebourne" <sc...@btopenworld.com>
> > > To: "Jakarta Commons Developers List" <co...@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" <dm...@apache.org>
> > > > To: "Jakarta Commons Developers List"
<co...@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: <co...@covalent.net>
> > > > > To: "Jakarta Commons Developers List"
> <co...@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:
> > > > > <ma...@jakarta.apache.org>
> > > > > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] new commiter Stephen Colebourne was [BeanUtils][Betwixt][commons] [jxpath] Proposal: Reflection/Introspection/MetaData package
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Thanks for the nomination. To comply with Dimitris suggestion, here are my
credentials:
8 years commercial coding experience
Java coding almost exclusively since late version JDK1.0
Started Open Source work December 2001 by creating www.joda.org, mission to
redefine beans and dates
Active verbal contributer to Apache commons
Active contributer to commons collections (PredicateUtils, plus others in
discussion)
;-)
----- Original Message -----
From: "Juozas Baliuka" <ba...@centras.lt>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, June 16, 2002 7:09 PM
Subject: [VOTE] new commiter Stephen Colebourne was
[BeanUtils][Betwixt][commons] [jxpath] Proposal:
Reflection/Introspection/MetaData package
>
> I want to nominate Stephen Colebourne as commiter on commons and sandbox,
> He is one of the most active contributors with the great ideas and we know
> his code.
> I think we need to give him chance to do more for commons project.
> We will need him in new project for reflection/introspection, proposal you
> can find on this list( [BeanUtils][Betwixt][commons] [jxpath] Proposal:
> Reflection/Introspection/MetaData package)
> +1
>
>
> > Steven,
> >
> > First, if you have not yet, read
> http://jakarta.apache.org/site/roles.html.
> >
> > Second, write a "hello, world" message to
commons-dev@jakarta.apache.org,
> so
> > that people know what your credentials are. If you aready have, re-post
> it,
> > because people tend to forget. If you have contributed to any open
source
> > projects, don't forget to mention that. Say in that message that you
> would
> > like to become a committer on this new project. Since the project is
going
> > to the sandbox first, I don't think anybody will have an objection.
Then
> > somebody will recommend you as a contributor. Then people will vote.
> Done.
> >
> > - Dmitri
> >
> >
> >
> > ----- Original Message -----
> > From: "Stephen Colebourne" <sc...@btopenworld.com>
> > To: "Jakarta Commons Developers List" <co...@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" <dm...@apache.org>
> > > To: "Jakarta Commons Developers List" <co...@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: <co...@covalent.net>
> > > > To: "Jakarta Commons Developers List"
<co...@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:
> > > > <ma...@jakarta.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] new commiter Stephen Colebourne was [BeanUtils][Betwixt][commons] [jxpath] Proposal: Reflection/Introspection/MetaData package
Posted by James Strachan <ja...@yahoo.co.uk>.
+1
James
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
> +1
>
> On Sun, 16 Jun 2002, Juozas Baliuka wrote:
>
> >
> > I want to nominate Stephen Colebourne as commiter on commons and
sandbox,
> > He is one of the most active contributors with the great ideas and we
know
> > his code.
> > I think we need to give him chance to do more for commons project.
> > We will need him in new project for reflection/introspection, proposal
you
> > can find on this list( [BeanUtils][Betwixt][commons] [jxpath] Proposal:
> > Reflection/Introspection/MetaData package)
> > +1
> >
> >
> > > Steven,
> > >
> > > First, if you have not yet, read
> > http://jakarta.apache.org/site/roles.html.
> > >
> > > Second, write a "hello, world" message to
commons-dev@jakarta.apache.org,
> > so
> > > that people know what your credentials are. If you aready have,
re-post
> > it,
> > > because people tend to forget. If you have contributed to any open
source
> > > projects, don't forget to mention that. Say in that message that you
> > would
> > > like to become a committer on this new project. Since the project is
going
> > > to the sandbox first, I don't think anybody will have an objection.
Then
> > > somebody will recommend you as a contributor. Then people will vote.
> > Done.
> > >
> > > - Dmitri
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Stephen Colebourne" <sc...@btopenworld.com>
> > > To: "Jakarta Commons Developers List" <co...@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" <dm...@apache.org>
> > > > To: "Jakarta Commons Developers List"
<co...@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: <co...@covalent.net>
> > > > > To: "Jakarta Commons Developers List"
<co...@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:
> > > > > <ma...@jakarta.apache.org>
> > > > > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] new commiter Stephen Colebourne was [BeanUtils][Betwixt][commons]
[jxpath] Proposal: Reflection/Introspection/MetaData package
Posted by Henri Yandell <ba...@generationjava.com>.
+1
On Sun, 16 Jun 2002, Juozas Baliuka wrote:
>
> I want to nominate Stephen Colebourne as commiter on commons and sandbox,
> He is one of the most active contributors with the great ideas and we know
> his code.
> I think we need to give him chance to do more for commons project.
> We will need him in new project for reflection/introspection, proposal you
> can find on this list( [BeanUtils][Betwixt][commons] [jxpath] Proposal:
> Reflection/Introspection/MetaData package)
> +1
>
>
> > Steven,
> >
> > First, if you have not yet, read
> http://jakarta.apache.org/site/roles.html.
> >
> > Second, write a "hello, world" message to commons-dev@jakarta.apache.org,
> so
> > that people know what your credentials are. If you aready have, re-post
> it,
> > because people tend to forget. If you have contributed to any open source
> > projects, don't forget to mention that. Say in that message that you
> would
> > like to become a committer on this new project. Since the project is going
> > to the sandbox first, I don't think anybody will have an objection. Then
> > somebody will recommend you as a contributor. Then people will vote.
> Done.
> >
> > - Dmitri
> >
> >
> >
> > ----- Original Message -----
> > From: "Stephen Colebourne" <sc...@btopenworld.com>
> > To: "Jakarta Commons Developers List" <co...@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" <dm...@apache.org>
> > > To: "Jakarta Commons Developers List" <co...@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: <co...@covalent.net>
> > > > To: "Jakarta Commons Developers List" <co...@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:
> > > > <ma...@jakarta.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>