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 [EMAIL PROTECTED], 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" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> > > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > > 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: <[EMAIL PROTECTED]> > > > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > > > Sent: Sunday, June 16, 2002 11:55 AM > > > Subject: Re: [BeanUtils][Betwixt][commons] Proposal: > > > Reflection/Introspection/MetaData package > > > > > > > > > > See also o.a.tomcat.util.IntrospectionUtils :-) > > > > > > > > It also have a nice feature - it takes an args[], and using > > introspection > > > > calls the setters, using "-name value" or "-name", based on the method > > > > signatures - setName( boolean ) or setName( String/int/whatever ) > > > > I personally find it very usefull - with a main() and 2 lines of code > > > > you can get a class that works as an Ant task or a bean or CLI. > > > > > > > > I would also count the axis introspection classes, and probably few > > > > others. > > > > > > > > Costin > > > > > > > > > > > > On 16 Jun 2002, Martin van den Bemt wrote: > > > > > > > > > Also check this with the ant team, who have a lot of introspection > in > > > > > there code.. It works on all jdk versions afaik. > > > > > See o.a.tools.ant.Introspectionhelper. > > > > > > > > > > +1 on the idea btw.. > > > > > > > > > > Mvgr, > > > > > Martin > > > > > > > > > > On Sun, 2002-06-16 at 13:40, Stephen Colebourne wrote: > > > > > > Hi, > > > > > > Currently, Betwixt and other users of BeanUtils rely on the > > java.beans > > > class > > > > > > Introspector to extract details from a class. Introspector is a > very > > > old and > > > > > > limited class in todays terms: > > > > > > - it doesn't support collections, just simple objects and arrays > > > > > > - it doesn't support modern conventions such as addXxx() adds to a > > the > > > xxx > > > > > > list > > > > > > - it doesn't support overloading well > > > > > > - the bean info technique is difficult to code, poorly understood > > and > > > > > > limiting > > > > > > - it's just too plain dumb. > > > > > > > > > > > > I propose that BeanUtils/Betwixt/commons should replace > Introspector > > > with a > > > > > > more general purpose reflection/introspection package. > > Architecturally > > > this > > > > > > would sit above reflection, but below Introspection: > > > > > > > > > > > > Requirements/Goals: > > > > > > - handle classes other than beans > > > > > > - support extensible metadata (not just for GUI builders) > > > > > > - handle normal (today) bean conventions (get/set/add/put methods) > > > > > > - handle future conventions that are not yet standard > > > > > > - support method overloading > > > > > > - be easily used directly from BeanUtils and Betwixt (and probably > > > others) > > > > > > - be a complete alternative to using java.lang.reflect > > > > > > - return immutable objects > > > > > > > > > > > > My proposed solution (not coded, fully open to discussion): > > > > > > Build a system with similarities to Digester. Rules get called > when > > > the > > > > > > class is examined determine how to link the methods together. For > > > example > > > > > > the FindGetPropertyMethodRule would look at method names starting > > with > > > get > > > > > > etc. The rule then classifies the method as a GET method and > stores > > it > > > into > > > > > > a structure something like this: > > > > > > > > > > > > - MethodSetInfo - holds details about a related set of methods. > > > > > > public String getName() > > > > > > public List getMethodInfos() > > > > > > public MethodInfo getMethodInfo(name) > > > > > > public Map getMetaData() > > > > > > public MetaData getMetaData(String name) > > > > > > > > > > > > - ClassInfo - main class that holds the representation of class. > > > Subclass of > > > > > > MethodSetInfo > > > > > > public List getMethodSetInfos() > > > > > > public MethodSetInfo getMethodSetInfo(name) > > > > > > public List getMethodSetInfos(methodSetType) > > > > > > public MethodSetInfo getMethodSetInfo(methodSetType, name) > > > > > > public PropertyInfo getPropertyInfo(name) // convenience > > > > > > > > > > > > - PropertyInfo - subclass of MethodSetInfo for properties > > (Lists/Maps > > > etc. > > > > > > tbd) > > > > > > public Class getPropertyType() > > > > > > public MethodInfo getGetMethodInfo() // convenience > > > > > > public MethodInfo getSetMethodInfo() // convenience > > > > > > public Object getValue() > > > > > > public void setValue() > > > > > > > > > > > > - MethodInfo - categorised info about a method > > > > > > public String getName() > > > > > > public Method getMethod() > > > > > > publc String getCategory() > > > > > > public Map getMetaData() > > > > > > public MetaData getMetaData(String name) > > > > > > public Object invoke(object, args, respectAccessFlags) > > > > > > > > > > > > Attached to each element is the ability to hold MetaData. This is > > > > > > particularly important for Betwixt. It would allow the XMLBeanInfo > > > class to > > > > > > be held directly on the representation of the class. And I'm sure > > > other > > > > > > projects want MetaData - its supposed to be a long standing > request > > > for J2SE > > > > > > (I know I need it for the Joda project). > > > > > > > > > > > > Note that I haven't expanded on the Rule part at the moment. > > > Basically, > > > > > > people must be able to write their own rules and add them to the > > > standard > > > > > > rules for beans. > > > > > > > > > > > > As for which project it belongs with...I suggest lang or something > > new > > > > > > (reflect?). I would like to extract it from BeanUtils because its > > not > > > Bean > > > > > > specific. > > > > > > > > > > > > > > > > > > Well, its an idea at the moment. There are some similarities to > > > DynaBeans, > > > > > > but I think it goes way further. I already have a partial version > of > > > this, > > > > > > but its specific to my needs. It needs some rework anyway, so I > > > thought > > > > > > about if it could be generic. Opinions?? > > > > > > > > > > > > Stephen > > > > > > > > > > > > PS. Three more possibilities for lang: > > > > > > Nameable > > > > > > MetaData > > > > > > Rule > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > -- > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
