You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Juozas Baliuka <ba...@centras.lt> on 2002/06/17 20:20:03 UTC
[ADMIN] Who can create account for Stephen ? was [VOTE] new commiter Stephen Colebourne
I see +5 for new commiter and nobody said -1,
Do we need to wait more votes ?
----- Original Message -----
From: "Bemt, Martin van den" <Ma...@2cure.com>
To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
Sent: Monday, June 17, 2002 11:29 AM
Subject: RE: [VOTE] new commiter Stephen Colebourne was
[BeanUtils][Betwixt][commons] [jxpath] Proposal:
Reflection/Introspection/MetaData package
> +1
>
> Mvgr,
> Martin
>
> -----Oorspronkelijk bericht-----
> Van: Juozas Baliuka [mailto:baliuka@centras.lt]
> Verzonden: Sunday, June 16, 2002 8:10 PM
> Aan: Jakarta Commons Developers List
> Onderwerp: [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: [ADMIN] Who can create account for Stephen ? was [VOTE] new
commiter Stephen Colebourne
Posted by Jason van Zyl <jv...@zenplex.com>.
On Mon, 2002-06-17 at 14:20, Juozas Baliuka wrote:
>
> I see +5 for new commiter and nobody said -1,
> Do we need to wait more votes ?
If Stephen sends me what he wants for login I'll get the account
created. I can take care of CVS access once that is done.
> ----- Original Message -----
> From: "Bemt, Martin van den" <Ma...@2cure.com>
> To: "'Jakarta Commons Developers List'" <co...@jakarta.apache.org>
> Sent: Monday, June 17, 2002 11:29 AM
> Subject: RE: [VOTE] new commiter Stephen Colebourne was
> [BeanUtils][Betwixt][commons] [jxpath] Proposal:
> Reflection/Introspection/MetaData package
>
>
> > +1
> >
> > Mvgr,
> > Martin
> >
> > -----Oorspronkelijk bericht-----
> > Van: Juozas Baliuka [mailto:baliuka@centras.lt]
> > Verzonden: Sunday, June 16, 2002 8:10 PM
> > Aan: Jakarta Commons Developers List
> > Onderwerp: [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>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>