You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Dmitri Plotnikov <dm...@apache.org> on 2002/06/16 16:05:22 UTC
Re: [VOTE] was Re: [BeanUtils][Betwixt][commons][jxpath] Proposal:
Reflection/Introspection/MetaData package
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>
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>