commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <dplot...@yahoo.com>
Subject Re: [JXPath] Lenient getValue() in JXPathContextReferenceImpl
Date Fri, 24 Jan 2003 16:34:04 GMT
Bjorn,

I apologize for being so stubborn on this issue. It's just that I have
a strong belief that exceptions are there to indicate abnormal
situations: errors, bugs and other nasty stuff that needs to be caught,
processed, reported etc.  OJB seems to be a special case where
exceptions are thrown systemically to indicate the absense of data.  It
is an unusual design, but we cannot change it.  So, let's deal with it,
but deal with it as a special case.  We should try to catch the
exception as closely to the place it is thrown as we can, identify and
ignore it. I don't think this can be accomplished with the current
design of JXPath, but that's what we _can_ change.  Here's a plan:

1. As a temporary solution you either use your patch or catch the
exceptions outside JXPath.  I would hesistate to incorporate the patch
in JXPath proper, because once it is there it will become a backward
compatibility issue.

2. We release JXPath 1.1 as is in the next month or so.

3. We promote Clazz from the sandbox into commons proper.

4. We integrate JXPath with clazz, deprecating XMLBeanInfo and all of
that "proprietary" stuff and make it JXPath 1.2.

5. We build a custom ReflectClazz for OJB, which will be incredibly
easy: the design of Clazz focuses on just this type of customization.
We make the custom ReflectClazz deal with the exceptions and return
null wherever appropriate.  Problem solved.

Does this sound like a good plan?

- Dmitri



--- Bjorn Bength <bjorn.bength@curalia.se> wrote:
> Hi again, Dmitri,
> 
> I tried the nightly build from tonight (20030124) with the exact same
> 
> behaviour as before.
> I append an extract of the log output at the end of this message,
> the xpath expression in this case should be "nod/address/coaddress"
> where the bean (nod) in question is in a map in the context.
> In this case nod _has_ a property called address and its get-method 
> getAddress(), but that method (or, really, OJBs access methods) 
> inherently throws an (Runtime) exception when it can't materialize
> the 
> object coz it points to a null in the database.
> this nod instance thus have no address and cannot have a coaddress 
> although all access methods are there.
> 
> 
> I have some notes about your statements below:
> a)  To me, if there is a lenient mode, it should quench _all_
> errors and exception, but should of course log it properly.
> Not just the case where the xpath expression in itself is erreanous.
> I should be able to trust the
> 
> b)  Maybe the lenient mode should be multilevel, one 'quench it all'
> and
> one as you describe it. OR at least describe the actual handling 
> properly in the documentation so that you know you cant trust it.
> 
> c)  We have a clear use of a superlenient mode, for example in a form
> on 
> a web page that we can't allow to break just because an object doesnt
> 
> have an address, and we dont care for what reason it doesnt can't
> look 
> it up. Maybe we're unique?
> 
> 
> Keep up the good work, Dmitri.
> and thanks for your time on this.
> 
> 
> /Björn
> 
> 
> 
> 
> Dmitri Plotnikov wrote:
>  > Bjorn,
>  >
>  > I don't really want to have a catch-all in getValue, even in the
>  > lenient mode.
>  >
>  > When we allowed exceptions during XPath evaluation, the purpose
> was not
>  > to conceal all problems, but to ignore <i>irrelevant</i> problems.
>  >
>  > Here's my logic:
>  >
>  > 1. When you call getValue("/foo/bar"), the implication is: "I know
> the
>  > exact path and I want the value that's sitting at the tip of that
> path.
>  > If the value is null or some parts of the path are missing, that's
> ok,
>  > that's why I switched to the lenient mode. However, if an
> exception is
>  > thrown while evaluating the path, something went wrong. I should
> have a
>  > way of tracing the problem in order to fix it.  This is why I want
> a
>  > descriptive exception thrown."
>  >
>  > 2. When you call iterate("foo//bar"), the implication is: "I am
> not
>  > sure there is anything for foo//bar, but I want to perform the
> search
>  > for it and get all matches.  As I search for it I will be calling
> many
>  > methods that have nothing to do with either foo or bar. I don't
> care if
>  > during the search some of those methods, e.g. getBadProperty() or
>  > getMadAndExplode() throw exceptions, because those properties are
>  > irrelevant for my search."
>  >
>  > This is why in the current cut of JXPath, getValue() throws an
>  > exception, while iterate() does not.
>  >
>  > Does this logic make sense?
>  >
>  > - Dmitri
>  >
> 
> 
> 
> 
> 
> 
> 
> The stacktrace.
> 
> 13391 DEBUG [HttpProcessor[9999][4]] db.NodmodulobjektOpImpl - Query 
> from class se.multicom.prisma.ojb.db.NodmodulobjektImpl where
> org.apache.
> ojb.broker.query.Criteria@45f468
> 13454 DEBUG [HttpProcessor[9999][4]] db.NodmodulobjektOpImpl -
> returning: []
> [DEFAULT] WARN: OJB broker could not materialize 
> se.multicom.prisma.ojb.db.AddressImpl{0}
> [org.apache.ojb.broker.accesslayer.IndirectionHandler] ERROR: Method 
> invoking failed for method *getCoaddress* on object null
> null
> java.lang.NullPointerException
>          at 
> org.apache.ojb.broker.accesslayer.IndirectionHandler.invoke(Unknown
> Source)
>          at $Proxy0.getCoaddress(Unknown Source)
>          at java.lang.reflect.Method.invoke(Native Method)
>          at 
>
org.apache.commons.jxpath.util.ValueUtils.getValue(ValueUtils.java:351)
>          at 
>
org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.getBaseValue(BeanPropertyPointer.java:151)
>          at 
>
org.apache.commons.jxpath.ri.model.beans.BeanPropertyPointer.getImmediateNode(BeanPropertyPointer.java:177)
>          at 
>
org.apache.commons.jxpath.ri.model.beans.PropertyPointer.getImmediateValuePointer(PropertyPointer.java:171)
>          at 
>
org.apache.commons.jxpath.ri.model.NodePointer.getValuePointer(NodePointer.java:259)
>          at 
>
org.apache.commons.jxpath.ri.JXPathContextReferenceImpl.getValue(JXPathContextReferenceImpl.java:249)
>          at 
>
org.apache.commons.jxpath.ri.JXPathCompiledExpression.getValue(JXPathCompiledExpression.java:101)
>          at 
>
org.apache.cocoon.www.prisma_site.tup.nod.nod_show_xsp.generate(/home/bjorn/tomcat/work/Standalone/localhost/cocoon/cocoon-files/or
> g/apache/cocoon/www/prisma_site/tup/nod/nod_show_xsp.java:1135)
>          at 
>
org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:263)
>          at 
>
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:520)
>          at 
>
org.apache.cocoon.components.pipeline.impl.CachingProcessingPipeline.processXMLPipeline(CachingProcessingPipeline.java:194)
>          at 
>
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:495)
>          at 
>
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:666)
>          at 
>
org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:368)
>          at 
>
org.apache.cocoon.environment.AbstractEnvironment.toSAX(AbstractEnvironment.java:454)
>          at 
>
org.apache.cocoon.environment.wrapper.EnvironmentWrapper.toSAX(EnvironmentWrapper.java:319)
>          at 
>
org.apache.cocoon.sitemap.ContentAggregator.generate(ContentAggregator.java:155)
>          at 
>
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:520)
>          at 
>
org.apache.cocoon.components.pipeline.impl.CachingProcessingPipeline.processXMLPipeline(CachingProcessingPipeline.java:194)
>          at 
>
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:495)
>          at 
>
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:142)
>          at 
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:83)
>          at 
>
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:160)
>          at 
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:107)
>          at 
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:157)
>          at 
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:107)
>          at 
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:152)
>          at 
>
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:327)
>          at 
>
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:309)
>          at 
>
org.apache.cocoon.environment.ForwardRedirector.cocoonRedirect(ForwardRedirector.java:201)
>          at 
>
org.apache.cocoon.environment.ForwardRedirector.redirect(ForwardRedirector.java:113)
>          at 
>
org.apache.cocoon.components.flow.AbstractInterpreter.forwardTo(AbstractInterpreter.java:214)
>          at 
>
org.apache.cocoon.components.flow.javascript.JSCocoon.jsFunction_forwardTo(JSCocoon.java:153)
>          at inv3.invoke()
>          at 
>
org.mozilla.javascript.FunctionObject.doInvoke(FunctionObject.java:523)
>          at 
> org.mozilla.javascript.FunctionObject.call(FunctionObject.java:438)
>          at 
> org.mozilla.javascript.ScriptRuntime.call(ScriptRuntime.java:1244)
>          at 
>
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:1561)
>          at 
>
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:647)
>          at 
>
org.mozilla.javascript.continuations.ContinuationInterpreter.interpret(ContinuationInterpreter.java:595)
>          at 
>
org.mozilla.javascript.continuations.InterpretedFunctionImpl.call(InterpretedFunctionImpl.java:121)
>          at 
>
org.apache.cocoon.components.flow.javascript.JavaScriptInterpreter.handleContinuation(JavaScriptInterpreter.java:261)
> 
=== message truncated ===


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Mime
View raw message