commons-user mailing list archives

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

Dmitri,

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
spannier@jacada.com
http://www.jacada.com



> Steve,
>
> Admittedly, the configuration of JXPath introspection is not too flexible
at
> this point.  It blindly relies on the BeanInfo data vended by the
standard
> Introspector, iterating over all "properties" seen by the Introspector.
And
> it does not take much for the Introspector to discover a "property".  If
you
> have something like a getJIType() method, you got yourself a property
called
> "JIType".  In the perfect world not all getFoo() methods would be treated
> the same way.
>
> The only customization the standard Introspector allows is custom
BeanInfo.
> 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.
We
> have been thinking about improving the situation, this is one of the
reasons
> we started the Clazz project [see
> http://jakarta.apache.org/commons/sandbox/clazz/].  Clazz is currently in
> its initial state and JXPath 1.1 is not going to be integrated with it,
but
> 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.
In
> 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
safe
> and with custom NodePointer as the last resort if the BeanInfo option
does
> not work for some reason.
>
> I hope this helps.
>
> - Dmitri
>
> ----- Original Message -----
> From: "Steve Pannier" <Steve_Pannier.CST@jacada.com>
> To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
> 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"
message.*
> >
> > I been thinking about this, and the fact that the value objects inside
our
> > map
> > are wrapped inside a custom class is what I think is causing the
problem.
> > (Our data is organized into a Map-List-Map format, where the value
nodes
> > (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
"this"
> > shows
> > data from within the wrapper class that I wasn't expecting to see.
I've
> > 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
wrapper
> > class are being invoked at the time I encounter the infinite loop
problem.
> >
> > 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
investigate
> > that
> > possibility further.  What if the "loop" exists within the bowels of
our
> > 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
application,
> > at least from looking at output from map.toString(), but yet it works
fine
> > in
> > my simple test case.  That's why at his point I'm pretty sure it has to
do
> > with
> > the way our data is stored inside the map.
> >
> > Any thoughts/suggestions?
> >



Mime
View raw message