You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by John Gentilin <ge...@eyecatching.com> on 2002/03/28 02:05:46 UTC

(SQL Extension / NPE issue) Re: Help, waiting on an answer

Scott,

Glad to hear that you are felling better. I was assuming that SQL mods
(besides the storm I started with the inclusion of 3rd party jars) just were
not making it to the top of the list.

The problem at hand.

If the SQL Extension runs into a problem, it records the error and returns
DTM.NULL. This should allow you to test on the return nodeset then
do error handling, in the stylesheet, based on the getError() Document

for example:.
  <xsl:if test="not(sql:connect($db, $cinfo))" >
     <xsl:message>Error Connecting to the Database</xsl:message>
      <xsl:copy-of select="sql:getError($db)/ext-error" />
    </xsl:if>

The worked fine on all the previous versions of Xalan until somewhere around
D12/D14.

The problem is that FilterExprWalker only checks for a null m_Expr in some of
the methods.  I changed it so if m_Expr was null then execute super.method()
since the default behavior of AxisWalker seems to be the correct behavior.

I had changed it originally but never checked it in because I did not get an
solid answer for the question, "Can a Extension function return DTM.NULL
or does it have to return an empty document. Someone commented that the
spec is not clear in this area and since this was a behavioral type change
in an area that I have not spent tons of time in, I was waiting for a response
before proceeding. It seems to me that returning DTM.NULL is a valid return
for an extension function, A) depending on the situation, you may not be able to
construct an empty document, B) In the DOM spec, Element@getElementsByTagName
a return of null is valid if there are no matching elements. and C) the function
FilterExprWalker#isDocOrdred should really test of m_Expr != null before
executing the method. My $.02.


Regards
John G


scott_boag@us.ibm.com wrote:

> Hi John.  I was sick in January and part of February, and so missed *lots*
> of mail.  I'm still not caught up... I don't know if I ever will be.
>
> FilterExprWalker (which changed a lot with my last check-in, BTW) (and now
> FilterExprIteratorSimple#executeFilterExpr) doesn't do any magic with the
> return from it's expression.  So returning null would be a bad idea
> (sorry).  An extension meant to return a null nodeset should return an
> empty DTMIterator or the like.
>
> I guess we could change this, so that null would be an acceptable return
> val.  Do you think it should be changed?
>
> -scott
>
>
>                       John Gentilin
>                       <gentijo@eyecatch        To:       Scott Boag <Sc...@lotus.com>
>                       ing.com>                 cc:
>                                                Subject:  Help, waiting on an answer
>                       02/02/2002 03:46
>                       PM
>
>
>
> Scott,
>
> In the last few weeks there were a few discussions on Iterators
> and empty sets returned as null from extension functions. The only
> thing I got feedback on was the legality of including InstantDB. Looks
> like I created a little scuttle that got the lawyers all excited.
> Anyway,
> I would like to put the finishing touches on the SQL extensions but
> I needed an answer on how empty sets were to be handled. It falls
> into one of two categories. 1) Empty sets can not be returned as a
> null. or 2) null is a valid return, and the Iterator in question needs
> to test for null. I believe you were CC'ed on most conversations
> and I read in the group that you were currently working on the
> iterators so I though I would rattle your cage.
>
> Hope all is going well.
>
> Regards
> JohnG
>
> --
> --------------------------------------
> John Gentilin
> Eye Catching Solutions Inc.
> 18314 Carlwyn Drive
> Castro Valley CA 94546
>
>     Contact Info
> gentijo@eyecatching.com
> Ca Office 1-510-881-4821
> NJ Office 1-732-422-4917

--
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546

    Contact Info
gentijo@eyecatching.com
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917