Fresh Build -> Re: (SQL Extension / NPE issue) Re: Help, waiting on an answer

[John Gentilin <ge...@eyecatching.com>]

Ok, the original error is fixed with the latest build but
an NPE is still thrown. This happens on the close method
call in the XConnection object. So the call to connect and
query function as designed but when the call to close
happens, the extension function call occurs correctly but
fails as soon as it returns.

Sample XSL

<xsl:template match="/">
    <xsl:variable name="db" select="sql:new()"/>
    <xsl:variable name="streaming" select="sql:disableStreamingMode($db)"/>
    <!-- Connect to the database with minimal error detection -->
  <xsl:if test="not(sql:connect($db, $driver, $datasource))" >
     <xsl:message>Error Connecting to the Database</xsl:message>
      <xsl:copy-of select="sql:getError($db)/ext-error" />
    </xsl:if>

    <xsl:variable name="table" select='sql:query($db, $query)'/>
    <xsl:if test="not($table)" >
          <xsl:message>Error in Query</xsl:message>
          <xsl:copy-of select="sql:getError($db)/ext-error" />
    </xsl:if>
    <xsl:message>DISPLAYING Column HEADERS</xsl:message>
      <xsl:for-each select="$table/sql/metadata/column-header">
          <xsl:value-of select="@column-label"/>
      </xsl:for-each>
      <xsl:if test="$table" >
          <xsl:apply-templates select="$table/sql/row-set/row"/>
       </xsl:if>

    <!-- THIS FUNCTION FAILS UPON RETURNING -->
    <xsl:message>Closeing Connection</xsl:message>
    <xsl:value-of select="sql:close($db)"/>
</xsl:template>


The Exception is initated in ExtensionHandlerJava#callFunction where
the code
        if (MethodResolver.DYNAMIC == resolveType)          // First argument was
object type
 >>         return m.invoke(targetObject, convertedArgs[0]);
        else                                  // First arg was not object.  See if
we need the implied object.

is executed.

The execption is really thrown on the return of callFunction, in
ExtensionTable#extFunction
      if (null != extNS)
      {
        try
        {
>>>          result = extNS.callFunction(funcName, argVec, methodKey,
                                      exprContext);
        }
        catch (javax.xml.transform.TransformerException e)
        {
          throw e;
        }
        catch (Exception e)
        {
          throw new javax.xml.transform.TransformerException(e);
        }
      }


I thought the problem may be occuring because #close does not take
expressionCOntext as
the first parameter. I changed it but it did not resolve the problem.

The problem will occur with any of the SQL test programs below is a stack trace.

javax.xml.transform.TransformerException: java.lang.NullPointerException
 at
org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1089)
 at
org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1066)
 at org.apache.xalan.xslt.Process.main(Process.java:915)
---------
java.lang.NullPointerException
 at
org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1175)

 at
org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:634)
 at
org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1088)
 at
org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1066)
 at org.apache.xalan.xslt.Process.main(Process.java:915)


John Gentilin wrote:

> > > 3) Create a set of exception classes.
> >
> > Extensions should have an architected error reporting mechanism, which
> > might include warnings and non-fatal errors. But if someone isses a fatal
> > error or  throws an exception, I'd suggest that we should _not_ attempt to
> > proceed past it.
>
> If a base exception class is created and if the extension throws  either the
> base
> class or a derived class, then processing may or may not continue (defined as
> an
> attribute of the exception) . If a completely different exception is thrown
> then processing
> definitely stops. What you are defining here is the structure returned when an
> extension
> wants to report an error.  As people build extensions, recoverable error
> handling will
> be required and it would be nice if a common error handling mechanism was
> defined.
> This allows a single template to be defined that would report at least the
> basic error
> information.
>
> What I was working with before was:
>
> apply-templates select=$var/ext-error would trigger error handling
> then in the template, the xpath statement /ext-error/message would
> provide the basic message no matter what extension function was
> called.
>
> The old way, only one of the apply-template calls would succeed.
>
> <xsl:variable name="table" select='sql:query($db, $query)'/>
> <xsl:apply-templates select="$table/sql/metadata/column-header">
> <xsl:apply-templates select="$table/ext-error">
>
> The new way
>
> <xsl:variable name="table" select='sql:query($db, $query)'/>
> <xsl:if test="not($table)" >
>    <xsl:message>Error in Query</xsl:message>
>    <xsl:copy-of select="sql:getError($db)/ext-error" />
> </xsl:if>
> <xsl:apply-templates select="$table/sql/metadata/column-header">
>
> The problem I ran into was that the second apply-tempalte call was
> doubling my transformation time in a stylesheet that consisted of
> primarily SQL calls. So then I moved to the null document and using
> the xsl:if statement.

--
--------------------------------------
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