Stephen, What was the resolution on this issue? In case you need more votes, here's mine:
+1 How far along are you? Do you need any help? I am very much iterested in the outcome and could do a bunch of coding/testing for you. JXPath currently has its own introspection mechanism and I am eager to replace it with a generic one. Some unique features of the JXPathIntrospector are: 1. From JXPath's perspective there exist so called "atomic" classes, which are not supposed to be drilled into. Examples include all primitive types as well as String, Number, Date, arguably Class etc. 2. Some classes (or interfaces) are "dynamic" and are handled with the use of so called DynamicPropertyHandlers. Examples of such "dynamic" classes are Map, ServletContext, etc. 4. JXPath has MethodLookup utilities that perform method lookups that allow type conversion and an additional hiddent argument (ExpressionContext). What bothers me about all this is that it is very ad hoc for JXPath's own needs, while conceptually it wants to be a specialization of a generic mechanism like what you are proposing for [clazz]. I have been getting some new requirements from JXPath users. For example the BeanInfo lookup mechanism has been repeatedly critisized - people want to see custom BeanInfo factories instead of or in addition to <beanclass>XBeanInfo classes. I will need to address these requirements sooner or later. Do you think I should continue growing introspection mechanisms inside JXPath for now, or bite the bullet and commit to integration with the [clazz] project? I would personally prefer the latter. What is the timetable for this [clazz]? Thank you, - Dmitri Plotnikov [EMAIL PROTECTED] __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
