Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

xsl transform nullpointer exception #494

Closed
francescoagati opened this Issue · 4 comments

3 participants

@francescoagati

# nokogiri (1.5.0 java)
# jruby 1.6.3
# macosx 10.5 java

require 'rubygems'
require 'nokogiri'


transform_xsl=Proc.new do
  puts xslt.transform(doc)
end

def get_xml(xml)
  Nokogiri::XML(xml)
end

def get_xsl(xsl)
  Nokogiri::XSLT(xsl)
end

xml=%{
  <a>
    <b>
      <c>123</c>
    </b>
  </a>
}

xsl=%{

  <xsl:stylesheet version="1.0"
                  xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

    <xsl:output encoding="UTF-8" indent="yes" method="xml" />

    <xsl:template match="/">
      <xsl:value-of select="/a" />
    </xsl:template>
  </xsl:stylesheet>


}


puts get_xsl(xsl).transform(get_xml(xml))

give this error

XsltStylesheet.java:167:in transform': java.lang.NullPointerException
from XsltStylesheet$i$0$2$transform.gen:65535:in
call'
from JavaMethod.java:630:in call'
from DynamicMethod.java:207:in
call'
from CachingCallSite.java:312:in cacheAndCall'
from CachingCallSite.java:169:in
call'
from untitled 11.rb:41:in __file__'
from untitled 11.rb:-1:in
load'
from Ruby.java:671:in runScript'
from Ruby.java:575:in
runNormally'
from Ruby.java:424:in runFromMain'
from Main.java:278:in
doRunFromMain'
from Main.java:198:in internalRun'
from Main.java:164:in
run'
from Main.java:148:in run'
from Main.java:128:in
main'

@yokolet
Owner

Thanks for reporting. This might be the same cause as issue#491. I'll have a look.

@sglee77

Patch in #491 solved one NullPointerException (NPE) problem. But, I am still getting NPE for the code above. I debugged the source and found out that result.getNode().getFirstChild() starting on line 176 in XsltStylesheet.java returned null:

if ("html".equals(result.getNode().getFirstChild().getNodeName())) {
  HtmlDocument htmlDocument = (HtmlDocument) getNokogiriClass(runtime, "Nokogiri::HTML::Document").allocate();
  htmlDocument.setNode(context, (Document) result.getNode());
  return htmlDocument;
} else {
  XmlDocument xmlDocument = (XmlDocument) NokogiriService.XML_DOCUMENT_ALLOCATOR.allocate(runtime, getNokogiriClass(runtime, "Nokogiri::XML::Document"));
  xmlDocument.setNode(context, (Document) result.getNode());
  return xmlDocument;
}

The reason it returned null is because we made the assumption that the xsl we constructed will be a well-formed document, i.e. html, so that we can use the code starting on line 176 to determine what kind of document we will be constructing.

@sglee77 sglee77 referenced this issue from a commit in sglee77/nokogiri
@sglee77 sglee77 Added test for issue #494 b6c88e5
@yokolet
Owner

I tried to fix this, but could make pure Java version work exactly same as libxml version.

My suggestion was pushed in rev. 17de464.

For some reason ('m not sure), DOM based transformation doesn't work. So, I added Stream based one. It is almost same as string based transformation, so the result is a string as well. However, Nokogiri API requires Nokogiri::XML::Document type to transform method. So, I added method to create a Document type object from the string, Here's another problem comes in. The result string doesn't have a parse-able structure for Apache Xerces. Xerces parser doesn't work exactly the same as libxml does.

To rescue this sort of case, I added the result string to the Document's "errors" instance variable. If you try below:

result =  get_xsl(xsl).transform(get_xml(xml))
p result.errors

You can see the transformed string with some error messages.

Do you think this is agreeable?

@sglee77

Cool. My test case doesn't blow up anymore.

Honestly, I am not sure about the use case of having a stylesheet without any form of document (xml or html) for transformation. Basically, the end result is both DOM based and Stream based transformation failed. Java parser just does not support non-document parsing. Maybe we should document the error somewhere in the Wiki just in case someone came across this scenario and google for the result. I think your solution is as good as it can get since we have to rely on the underlying Java parser. I will leave it up to you if my test case should be incorporated with the rest of the test cases. Thanks for the hard work!

@jvshahid jvshahid closed this in 68e1e98
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.