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" <[EMAIL PROTECTED]> > 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" <[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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
