Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Message-ID: <20030221214332.70045.qmail@web11708.mail.yahoo.com>
Date: Fri, 21 Feb 2003 13:43:32 -0800 (PST)
From: Dmitri Plotnikov <dplotnik@yahoo.com>
Reply-To: dmitri@apache.org
Subject: Re: [JXPath] Infinite loop in iterator.hasNext()
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
In-Reply-To: <OF2FEC5DA5.9D0B2625-ON86256CD4.005E6559@jacada.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Steve,

Thank you for the update.

I am thinking I should probably include a section in the documentation
on infinite loops and how to fight them.

- Dmitri

--- Steve Pannier <Steve_Pannier.CST@jacada.com> wrote:
> 
> 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?
> > >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/