commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <dmi...@apache.org>
Subject Re: [BeanUtils][Betwixt][commons] [jxpath] Proposal: Reflection/Introspection/MetaData package
Date Mon, 17 Jun 2002 01:24:15 GMT
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" <paulo.gaspar@krankikom.de>
To: "Jakarta Commons Developers List" <commons-dev@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" <scolebourne@btopenworld.com>
> > To: "Jakarta Commons Developers List" <commons-dev@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" <dmitri@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" <scolebourne@btopenworld.com>
> > > > > To: "Jakarta Commons Developers List"
> > <commons-dev@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" <dmitri@apache.org>
> > > > > > To: "Jakarta Commons Developers List"
> > <commons-dev@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: <costinm@covalent.net>
> > > > > > > To: "Jakarta Commons Developers List"
> > > <commons-dev@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:
> > > > > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > > > > > > For additional commands, e-mail:
> > > > > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > To unsubscribe, e-mail:
> > > > > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > > > > > For additional commands, e-mail:
> > > > > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > To unsubscribe, e-mail:
> > > > > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > > > > For additional commands, e-mail:
> > > > > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > To unsubscribe, e-mail:
> > > > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > > > For additional commands, e-mail:
> > > > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > To unsubscribe, e-mail:
> > > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > > For additional commands, e-mail:
> > > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <mailto:commons-dev-help@jakarta.apache.org>
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <mailto:commons-dev-help@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:commons-dev-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message