commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Pannier" <>
Subject Re: [JXPath] Infinite loop in iterator.hasNext()
Date Fri, 21 Feb 2003 17:27:21 GMT


Just FYI:

I tried the custom BeanInfo method, and it seems to work.
And fortunately, we only had one key class to create a
BeanInfo for (at least, it's the only one we know about at
the present time).  In our case, the BeanInfo returns empty
property descriptor and method descriptor arrays, so that
JXPath will do no introspection on this class.  Since we
don't require these classes to be bean-compliant, this
seems to have no other side effects for us.

Thanks again for your help.

Steve Pannier
Jacada, Inc.
(763) 201-0002 Ext. 219

> Steve,
> Admittedly, the configuration of JXPath introspection is not too flexible
> this point.  It blindly relies on the BeanInfo data vended by the
> Introspector, iterating over all "properties" seen by the Introspector.
> it does not take much for the Introspector to discover a "property".  If
> have something like a getJIType() method, you got yourself a property
> "JIType".  In the perfect world not all getFoo() methods would be treated
> the same way.
> The only customization the standard Introspector allows is custom
> Unfortunately, you'll have to customize each class' BeanInfo individually
> and that may be a lot of work if you have a lot of classes to customize.
> have been thinking about improving the situation, this is one of the
> we started the Clazz project [see
>].  Clazz is currently in
> its initial state and JXPath 1.1 is not going to be integrated with it,
> I hope a later release will be.
> At this point a custom BeanInfo for each class that has an introspection
> problem is the preferred, simple, standard, though not too flexible a
> solution - just follow the JavaBeans specification.  Make sure the custom
> BeanInfo only declares the properties that are supposed to be declared.
> your case that does not include "JIType".
> There is also a more powerful, though more involved solution that uses
> custom NodePointerFactory and NodePointer.  I would not encourage this
> solution too much, because NodePointer is a part of internal APIs and so
> cannot be relied on too heavily for the long term.
> To summarize, I would go with a custom BeanInfo if you want to play it
> and with custom NodePointer as the last resort if the BeanInfo option
> not work for some reason.
> I hope this helps.
> - Dmitri
> ----- Original Message -----
> From: "Steve Pannier" <>
> To: "Jakarta Commons Users List" <>
> Sent: Wednesday, February 19, 2003 4:08 PM
> Subject: Re: [JXPath] Infinite loop in iterator.hasNext()
> >
> > Dmitri,
> >
> > I implemented your hack, and I do indeed get the "infinite loop"
> >
> > I been thinking about this, and the fact that the value objects inside
> > map
> > are wrapped inside a custom class is what I think is causing the
> > (Our data is organized into a Map-List-Map format, where the value
> > (i.e. leaf nodes)  are wrapped in a custom object inside a List.)  When
> the
> > above "infinite loop" message appears in my logfile, the value of
> > shows
> > data from within the wrapper class that I wasn't expecting to see.
> > done a
> > little digging, and I suspect the problem I'm seeing is due to JXPath's
> use
> > of
> > reflection.  I've put some debug statements in
> > ValueUtils.getAccessibleValue()
> > and ValueUtils.getValue(), and it looks like methods in our custom
> > class are being invoked at the time I encounter the infinite loop
> >
> > Now, at this point it's still entirely possible there is a "loop"
> condition
> > within
> > our map somewhere.  But I wanted to run this by you before I
> > that
> > possibility further.  What if the "loop" exists within the bowels of
> > wrapper
> > classes.  Is there a way I can prevent JXPath from using reflection to
> > interrogate these objects?  Why does JXPath do this?
> >
> > BTW: I've had no  luck trying to get my test case to recreate this
> problem.
> > I've duplicated the same map that causes the problem in our
> > at least from looking at output from map.toString(), but yet it works
> > in
> > my simple test case.  That's why at his point I'm pretty sure it has to
> > with
> > the way our data is stored inside the map.
> >
> > Any thoughts/suggestions?
> >

View raw message