I need help from a Xalan DTM/XPath expert...

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

I am working on issue in the SQL Extension code, where we need to 
identify the DTM that
was created by the query then assigned to a variable. When the variable 
is processed
with a xsl:for-each, a different Iterator is wrapped around the DTM  
than when the variable is
processed with an xsl:apply-templates.

Using the method below to locate the DTM from the from the variable.

When the variable is processed with the xsl:apply-templates statement,
The variable doc, is a DTMNodeIterator
 The dtm_iter is an XNodeSet
   In XNodeSet,
     the iter = OneStepIterator
     m_dtmMgr is NULL


When the variable is processed with and xsl:for-each
The variable doc, is a DTMNodeIterator
 The dtm_iter is a XNodeSet
  In XNodeSet,
   the dtmMgr is not null
   the iter = SelfIteratorNoPredicate

When I try to get the root() from the dtmIter, since the dtmMgr is null, 
there is an assertion
specifying that a DTM Manager was not set. I try to catch the Exception 
and find an alternative
path to the DTM but there are no relevant public methods although the 
DTM object I am after is
contained in the local fields m_cdtm.

My assumption is that the problem originates in the XNodeSet constructor 
included below. Where
if the iterator being wrapped is an XNodeSet, the m_dtmMgr is set 
otherwise it is not although
I am not sure where grab the DTM.

Any ideas....

Thanks
John G


 private SQLDocument locateSQLDocument(ExpressionContext exprContext, 
Object doc)
  {
    try
    {
      if (doc instanceof DTMNodeIterator)
      {
        DTMNodeIterator dtmIter = (DTMNodeIterator)doc;
        try
        {
          DTMNodeProxy root = (DTMNodeProxy)dtmIter.getRoot();
          return (SQLDocument) root.getDTM();
        }
        catch (Exception e)
        {
          XNodeSet xNS = (XNodeSet)dtmIter.getDTMIterator();
          DTMIterator iter = (DTMIterator)xNS.getContainedIter();
          DTM dtm = iter.getDTM(xNS.nextNode());
          return (SQLDocument)dtm;
        }
      }

      setError(new Exception("SQL Extension:close - Can Not Identify 
SQLDocument"), exprContext);   
      return null; 
    }
    catch(Exception e)
    {
      setError(e, exprContext);
      return null;
    }
  }

  public XNodeSet(DTMIterator val)
  {
      super();
      if(val instanceof XNodeSet)
      {
        setIter(((XNodeSet)val).m_iter);
        m_dtmMgr = ((XNodeSet)val).m_dtmMgr;
        m_last = ((XNodeSet)val).m_last;
        if(!((XNodeSet)val).hasCache())
            ((XNodeSet)val).setShouldCacheNodes(true);
        m_obj = ((XNodeSet)val).m_obj;
      }
      else
        setIter(val);
  }



---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org

Re: I need help from a Xalan DTM/XPath expert...

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

Joe,

Thank you, let me know if you want me to test any theories...

While this issue is at the top of my Xalan list, I have another concern 
on a related thread.
Extension functions that return a DTM have a problem that is similar to 
caching of the
DTM in a document function. Any ideas why the destroy() function is not 
called on the
variable stack as items are released ??. I would assume that any DTM 
that was assigned
to a variable that goes out of scope should be removed from the source 
tree and the
DTM manager...  ??

Thanks again
John G


Joseph Kesselman wrote:

>
>
>  
>
>>When the variable is processed
>>with a xsl:for-each, a different Iterator is wrapped around the DTM
>>than when the variable is processed with an xsl:apply-templates.
>>    
>>
>
>That isn't entirely unreasonable. I believe match patterns and select
>patterns are compiled separately since there are some subtle differenced
>between them.
>
>It's been too long since I looked at this code, but I'll try to find a few
>cycles to review this. Meanwhile, my gut instinct would be to look at other
>ways of retrieving the information. If DTMIterator.getDTMManager() isn't
>working reliably, you could try the .getDTM().getManager() path, though I'm
>not sure that will work any better.
>
>
>
>______________________________________
>Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
>"The world changed profoundly and unpredictably the day Tim Berners Lee
>got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xalan-dev-help@xml.apache.org
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org

Re: I need help from a Xalan DTM/XPath expert...

[Joseph Kesselman <ke...@us.ibm.com>]

>When the variable is processed
>with a xsl:for-each, a different Iterator is wrapped around the DTM
>than when the variable is processed with an xsl:apply-templates.

That isn't entirely unreasonable. I believe match patterns and select
patterns are compiled separately since there are some subtle differenced
between them.

It's been too long since I looked at this code, but I'll try to find a few
cycles to review this. Meanwhile, my gut instinct would be to look at other
ways of retrieving the information. If DTMIterator.getDTMManager() isn't
working reliably, you could try the .getDTM().getManager() path, though I'm
not sure that will work any better.



______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk


---------------------------------------------------------------------
To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xalan-dev-help@xml.apache.org