You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/06/16 13:40:56 UTC
[BeanUtils][Betwixt][commons] Proposal: Reflection/Introspection/MetaData package
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>
Re: [BeanUtils][Betwixt][commons] [jxpath] Proposal:
Reflection/Introspection/MetaData package
Posted by Dmitri Plotnikov <dm...@apache.org>.
There is one issue I have with the use of DynaBeans as wrappers - you've got
to allocate one of those for each object you are wrapping. Of course, Sun
folks may be telling us that object allocation is now as cheap as integer
division (I made this one up), but we all know that every time we allocate
another wrapper, we are wasting precious cycles.
This is why in JXPath I have a _delegate_ rather than a wrapper. Instead of
wrapper.getValue("foo")
JXPath has
handler.getValue(target, "foo")
Handlers are allocated statically and reused.
At the same time, I see tremendous value in DynaBean as pseudo-objects that
are created based on a specification (think XML). In this case they indeed
add lots of flexibility.
That's just my opinion, I could be wrong.
- Dmitri
----- Original Message -----
From: "Paulo Gaspar" <pa...@krankikom.de>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, June 16, 2002 8:37 PM
Subject: RE: [BeanUtils][Betwixt][commons] [jxpath] Proposal:
Reflection/Introspection/MetaData package
> 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" <sc...@btopenworld.com>
> > To: "Jakarta Commons Developers List" <co...@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" <dm...@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" <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>
>
>
> --
> 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: [BeanUtils][Betwixt][commons] [jxpath] Proposal: Reflection/Introspection/MetaData package
Posted by Paulo Gaspar <pa...@krankikom.de>.
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" <sc...@btopenworld.com>
> To: "Jakarta Commons Developers List" <co...@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" <dm...@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" <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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [BeanUtils][Betwixt][commons] [jxpath] Proposal:
Reflection/Introspection/MetaData package
Posted by Dmitri Plotnikov <dm...@apache.org>.
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" <sc...@btopenworld.com>
To: "Jakarta Commons Developers List" <co...@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" <dm...@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" <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: [BeanUtils][Betwixt][commons] [jxpath] Proposal: Reflection/Introspection/MetaData package
Posted by Stephen Colebourne <sc...@btopenworld.com>.
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" <dm...@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" <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: [BeanUtils][Betwixt][commons] [jxpath] Proposal:
Reflection/Introspection/MetaData package
Posted by Dmitri Plotnikov <dm...@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" <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>
[VOTE] new commiter Stephen Colebourne was [BeanUtils][Betwixt][commons] [jxpath] Proposal: Reflection/Introspection/MetaData package
Posted by Juozas Baliuka <ba...@centras.lt>.
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: [BeanUtils][Betwixt][commons] [jxpath] Proposal:
Reflection/Introspection/MetaData package
Posted by Dmitri Plotnikov <dm...@apache.org>.
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>
Re: [BeanUtils][Betwixt][commons] [jxpath] Proposal: Reflection/Introspection/MetaData package
Posted by Stephen Colebourne <sc...@btopenworld.com>.
[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>
Re: [BeanUtils][Betwixt][commons] [jxpath] Proposal:
Reflection/Introspection/MetaData package
Posted by co...@covalent.net.
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: <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>
Re: [BeanUtils][Betwixt][commons] [jxpath] Proposal:
Reflection/Introspection/MetaData package
Posted by Dmitri Plotnikov <dm...@apache.org>.
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>
Re: [BeanUtils][Betwixt][commons] Proposal: Reflection/Introspection/MetaData
package
Posted by co...@covalent.net.
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>
Re: [BeanUtils][Betwixt][commons] Proposal:
Reflection/Introspection/MetaData package
Posted by Martin van den Bemt <ml...@mvdb.net>.
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>
Re: [VOTE] Release vote for JXPath 1.0
Posted by Juozas Baliuka <ba...@centras.lt>.
+1
> I'd like to call for a release vote on JXPath 1.0 . It has been stable
for
> a while, and there are no outstanding bugs against it. All the goals we
had
> initially stated for this release have been met.
>
> The release candidate build is
>
>
http://jakarta.apache.org/builds/jakarta-commons/release/commons-jxpath/v1.0
>
> +1 (this is my vote)
>
> Thank you,
>
> Dmitri
>
>
> --
> 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] Release vote for JXPath 1.0
Posted by Dmitri Plotnikov <dm...@apache.org>.
I have addressed these two requirements. The ONLY changes are in the src.gz
and .zip: the directory name and the default target.
I will assume that this does not require a re-vote, I'll just wait for
another vote (crossing my fingers) and go ahead with the announcement.
Thanks,
- Dmitri
----- Original Message -----
From: "Jeff Turner" <je...@socialchange.net.au>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, June 16, 2002 10:00 PM
Subject: Re: [VOTE] Release vote for JXPath 1.0
> Only-glanced-at-the-code +1
>
> Two comments:
>
> - I'd prefer the directory name to be 'commons-jxpath-<version>-src'
> instead of just 'commons-jxpath'. Eg, when I checked it out, it
> conflicted with files from the previous beta.
> - How about changing the default target to 'jar', instead of 'compile'?
>
>
> --Jeff
>
> On Sun, Jun 16, 2002 at 10:19:44AM -0400, Dmitri Plotnikov wrote:
> > I'd like to call for a release vote on JXPath 1.0 . It has been stable
for
> > a while, and there are no outstanding bugs against it. All the goals we
had
> > initially stated for this release have been met.
> >
> > The release candidate build is
> >
> >
http://jakarta.apache.org/builds/jakarta-commons/release/commons-jxpath/v1.0
> >
> > +1 (this is my vote)
> >
> > Thank you,
> >
> > Dmitri
> >
>
> --
> 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] Release vote for JXPath 1.0
Posted by Jeff Turner <je...@socialchange.net.au>.
Only-glanced-at-the-code +1
Two comments:
- I'd prefer the directory name to be 'commons-jxpath-<version>-src'
instead of just 'commons-jxpath'. Eg, when I checked it out, it
conflicted with files from the previous beta.
- How about changing the default target to 'jar', instead of 'compile'?
--Jeff
On Sun, Jun 16, 2002 at 10:19:44AM -0400, Dmitri Plotnikov wrote:
> I'd like to call for a release vote on JXPath 1.0 . It has been stable for
> a while, and there are no outstanding bugs against it. All the goals we had
> initially stated for this release have been met.
>
> The release candidate build is
>
> http://jakarta.apache.org/builds/jakarta-commons/release/commons-jxpath/v1.0
>
> +1 (this is my vote)
>
> Thank you,
>
> Dmitri
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Release vote for JXPath 1.0
Posted by Ivelin Ivanov <iv...@apache.org>.
+1
(if it counts)
Dmitri Plotnikov wrote:
> I'd like to call for a release vote on JXPath 1.0 . It has been stable for
> a while, and there are no outstanding bugs against it. All the goals we had
> initially stated for this release have been met.
>
> The release candidate build is
>
> http://jakarta.apache.org/builds/jakarta-commons/release/commons-jxpath/v1.0
>
> +1 (this is my vote)
>
> Thank you,
>
> Dmitri
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
-= Ivelin =-
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Release vote for JXPath 1.0
Posted by Martin van den Bemt <ml...@mvdb.net>.
On Sun, 2002-06-16 at 17:06, Dmitri Plotnikov wrote:
> The problem is with the count. The tests have internal structure - sorry,
> that might be bad idea, at least misleading.
>
> The actual number of tests hiding behind the 8 you counted is about 350, you
> need to count each XPath that is being tested, because they are designed to
> provide very good coverage of the overall codebase.
I try to use a more direct approach testing classes and not indirect,
where possible. It helps debugging in the long term and catching
possible errors, which doesn't necessarily have to break the testcases.
As an example for your code base :
The QName.java equals method.
I would make a testcase for that object containing at least the
equalsmethod, so you know all the tests are failing, because your equals
is broken.
>
> I hope that addresses your concern.
>
That's why I said that i am not -1'ing the release, since everyone has a
different approach on using tests, which isn't necessarily a bad thing..
Mvgr,
Martin
BTW the code is looking good ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Release vote for JXPath 1.0
Posted by Dmitri Plotnikov <dm...@apache.org>.
The problem is with the count. The tests have internal structure - sorry,
that might be bad idea, at least misleading.
The actual number of tests hiding behind the 8 you counted is about 350, you
need to count each XPath that is being tested, because they are designed to
provide very good coverage of the overall codebase.
I hope that addresses your concern.
- Dmitri
----- Original Message -----
From: "Martin van den Bemt" <ml...@mvdb.net>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, June 16, 2002 10:35 AM
Subject: Re: [VOTE] Release vote for JXPath 1.0
> I will not -1 it, but hear me out ;)
> I don't know jxpath (seen it around though), but just took a look at the
> sourcecode.
> It has about 8 testcases and that is a huge difference with the actual
> number of classes in the jxpath package.
> How can you asure that in the next release current behaviour is not
> breaking bacward compatibility, except for the fact that you can say "I
> seen it work" ? And of course the current release can have many bugs,
> which can only be revealed in testcases (not saying it is, don't get me
> wrong..)
>
> Mvgr,
> Martin
>
> On Sun, 2002-06-16 at 16:19, Dmitri Plotnikov wrote:
> > I'd like to call for a release vote on JXPath 1.0 . It has been stable
for
> > a while, and there are no outstanding bugs against it. All the goals we
had
> > initially stated for this release have been met.
> >
> > The release candidate build is
> >
> >
http://jakarta.apache.org/builds/jakarta-commons/release/commons-jxpath/v1.0
> >
> > +1 (this is my vote)
> >
> > Thank you,
> >
> > Dmitri
> >
> >
> > --
> > 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] Release vote for JXPath 1.0
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
It must not be problems for bacward compatibility in 1.0 release.
It is good to have more test cases, but it JXPath is some kind of frontend
implementation and 8 testcases is not so bad for this kind of code.
> pff hope you understand my english ;((.. Hope it is all clear what I
> meant though ..
>
> Mvgr,
> Martin
>
> On Sun, 2002-06-16 at 16:35, Martin van den Bemt wrote:
> > I will not -1 it, but hear me out ;)
> > I don't know jxpath (seen it around though), but just took a look at the
> > sourcecode.
> > It has about 8 testcases and that is a huge difference with the actual
> > number of classes in the jxpath package.
> > How can you asure that in the next release current behaviour is not
> > breaking bacward compatibility, except for the fact that you can say "I
> > seen it work" ? And of course the current release can have many bugs,
> > which can only be revealed in testcases (not saying it is, don't get me
> > wrong..)
> >
> > Mvgr,
> > Martin
> >
>
>
>
> --
> 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] Release vote for JXPath 1.0
Posted by Martin van den Bemt <ml...@mvdb.net>.
pff hope you understand my english ;((.. Hope it is all clear what I
meant though ..
Mvgr,
Martin
On Sun, 2002-06-16 at 16:35, Martin van den Bemt wrote:
> I will not -1 it, but hear me out ;)
> I don't know jxpath (seen it around though), but just took a look at the
> sourcecode.
> It has about 8 testcases and that is a huge difference with the actual
> number of classes in the jxpath package.
> How can you asure that in the next release current behaviour is not
> breaking bacward compatibility, except for the fact that you can say "I
> seen it work" ? And of course the current release can have many bugs,
> which can only be revealed in testcases (not saying it is, don't get me
> wrong..)
>
> Mvgr,
> Martin
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Release vote for JXPath 1.0
Posted by Martin van den Bemt <ml...@mvdb.net>.
I will not -1 it, but hear me out ;)
I don't know jxpath (seen it around though), but just took a look at the
sourcecode.
It has about 8 testcases and that is a huge difference with the actual
number of classes in the jxpath package.
How can you asure that in the next release current behaviour is not
breaking bacward compatibility, except for the fact that you can say "I
seen it work" ? And of course the current release can have many bugs,
which can only be revealed in testcases (not saying it is, don't get me
wrong..)
Mvgr,
Martin
On Sun, 2002-06-16 at 16:19, Dmitri Plotnikov wrote:
> I'd like to call for a release vote on JXPath 1.0 . It has been stable for
> a while, and there are no outstanding bugs against it. All the goals we had
> initially stated for this release have been met.
>
> The release candidate build is
>
> http://jakarta.apache.org/builds/jakarta-commons/release/commons-jxpath/v1.0
>
> +1 (this is my vote)
>
> Thank you,
>
> Dmitri
>
>
> --
> 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] Release vote for JXPath 1.0
Posted by co...@covalent.net.
+1 ( as non-commiter ).
I've looked at the code and seen it used, it is really cool. I wish
I had more time...
Costin
On Sun, 16 Jun 2002, Dmitri Plotnikov wrote:
> I'd like to call for a release vote on JXPath 1.0 . It has been stable for
> a while, and there are no outstanding bugs against it. All the goals we had
> initially stated for this release have been met.
>
> The release candidate build is
>
> http://jakarta.apache.org/builds/jakarta-commons/release/commons-jxpath/v1.0
>
> +1 (this is my vote)
>
> Thank you,
>
> Dmitri
>
>
> --
> 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>
[VOTE] Release vote for JXPath 1.0
Posted by Dmitri Plotnikov <dm...@apache.org>.
I'd like to call for a release vote on JXPath 1.0 . It has been stable for
a while, and there are no outstanding bugs against it. All the goals we had
initially stated for this release have been met.
The release candidate build is
http://jakarta.apache.org/builds/jakarta-commons/release/commons-jxpath/v1.0
+1 (this is my vote)
Thank you,
Dmitri
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] was Re: [BeanUtils][Betwixt][commons][jxpath] Proposal: Reflection/Introspection/MetaData package
Posted by bob mcwhirter <bo...@werken.com>.
I don't know exactly how/if it fits in, but Ant does a fair bit
of introspection also. So far, I haven't been able to use beanutils
(I may be using it wrong) to do what Ant does.
Seems like most of the introspectors out there, given a name "fileset"
will look for something like "addFileset(...)", where ant's introspector
can actually find "addFileSet(...)" since it first looks at the methods
and then toLowerCase()'s the root. Likewise, when doing lookups.
Basically, from the methods, it can determine the properties, as opposed
to being given a property, and then looking up a matching method. Where
BeanUtils will sometimes fail (not find the method with the interCaps),
Ant's introspector will sometimes work (find the method with the interCaps).
-bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] was Re: [BeanUtils][Betwixt][commons][jxpath] Proposal:
Reflection/Introspection/MetaData package
Posted by Dmitri Plotnikov <dm...@apache.org>.
I took the liberty of adding jxpath to the list, because it also has an
introspection mechanism. IMO, it has way too much of it and breaking it out
would make tremendous sense.
When I was working on a product the current version of which is available
from Object Venture, http://www.objectventure.com, I intoduced an idea in
that product that was similar to yours. We called this a "Feature". A
Feature (like "Attribute") was equipped with a bunch of rules that allowed
it to recognize its piece parts: get, set methods and all the other stuff.
That software was working with the source code parse tree, so it could see
more than introspection would. The beauty of the generalization was that we
could describes as Features not only attributes, but also things like
business methods, finders on EJBs etc.
+1 (vote of support, you don't need an actual vote to put something in
sandbox)
I'd like to be a contributor if you need help.
- Dmitri
----- Original Message -----
From: "Juozas Baliuka" <ba...@centras.lt>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Sunday, June 16, 2002 9:06 AM
Subject: [VOTE] was Re: [BeanUtils][Betwixt][commons] Proposal:
Reflection/Introspection/MetaData package
> Hi,
> It is good idea. I think it is no need discuss a lot. Just paste this to
> PROPOSAL file
> and start a new project in sandbox( or find some existing about the same).
> +1 if it needs vote.
>
>
> > 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>
[VOTE] was Re: [BeanUtils][Betwixt][commons] Proposal: Reflection/Introspection/MetaData package
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
It is good idea. I think it is no need discuss a lot. Just paste this to
PROPOSAL file
and start a new project in sandbox( or find some existing about the same).
+1 if it needs vote.
> 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>
Re: [BeanUtils][Betwixt][commons] Proposal: Reflection/Introspection/MetaData package
Posted by Juozas Baliuka <ba...@centras.lt>.
I think ideas you proposed in BCEL list can be moved to this proposal too.
> 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>