Add xalan jars to fix issues with #1114

[atambo]

Jars downloaded from http://xalan.apache.org/xalan-j/downloads.html

@yokolet, @jvshahid, @flavorjones, @bbrowning

Does this look reasonable? I am one of the poor people that need to use the IBM JDK so I think this is the only solution. Running the tests locally gives me 3 failures. It seems like at least 1 of the failures is just a change in an exception message. Should I expect all of the tests to pass on jruby?

[mkristian]

+1
yes, very much. this also can cause funny and hard to debug classloader issues when you turn of classloader.delegate to the parent classloader which you can to on servlet containers and also with jruby-9k (actually jruby-9.0.0.0.pre1 has this a default without a possibility to turn it off,).

since you guys to embed the jars inside the gem any ways it is always possible to bundle a jar with only the few classes from xalan you really use for the XPath stuff.

but we also should make sure xerces and xalan and xml-apis are fitting together. see also my xerces update on: #1251

[atambo]

@mkristian, so your commits in update #1251 will handle updating xerces. Do you have any ideas why embedding xalan causes these test failures?:

https://travis-ci.org/sparklemotion/nokogiri/jobs/44859569

[mkristian]

@atambo my comment above with the classloader referred to https://github.com/sparklemotion/nokogiri/blob/master/ext/java/nokogiri/XmlXpathContext.java#L61
and I thought that are the xalan classes nokogiri uses. now I realised that this PR does not address those com.sun.org.apache.* classes.

I would assume it is due to xml-api that something goes wrong. on the other hand updating nekohtml did fix an encoding bugs and produced 19 failures in the test-suite. so I am not surprised that adding xalan.jar has some regressions.

having said this - the same regression will take place whenenver a project whats to use xalan and just picks the latest xalan and requires it.

I might find some time to look into this xalan update.

[flavorjones]

Hi all,

I'm not a Java guy, so before I merge anything I need to fully understand what's going on here.

Can someone explain clearly, as if I was a Java newbie:

• the underlying issue this is addressing
• what the pros and cons are
• any alternative solutions that were considered

Thanks for helping me understand and thereby better support Nokogiri and your use cases.

[atambo]

The original issue is explained in this comment: #1114 (comment)

This commit adds the jars that contain these internal classes to the gem so that JDK's that don't bundle xalan will still be able to use nokogiri.

One other solution to this issue would be to stop using these internal classes in nokogiri which were introduced in this commit: 2e2b204

[mkristian]

but adding the xalan jar is only the first step, as mentioned here: #1114 (comment)

you also need to use the classes from the xalan jar instead of the com.sun.* ones !!!!

alternatively:
instead of the xalan jar which is about 3MB big you can just pick those handful of classes in pack them into some xalan-nokogiri.jar

but in anycase it is worth to see if all those xerces, xalan and xml-apis fit together.

[atambo]

So I switched all the internal packages over to the ones included in the xalan jars.

[jvshahid]

I was able to repro the failures locally. I'll try to get them fixed so we can merge this pr. Thanks for being patient.

[jvshahid]

I started looking at the failure in test_transform_with_output_style and it looks like the result of assert_no_match(/<td>/, xslt.apply_to(@doc, ['title', 'foo'])) was trivially true because the return value of apply_to was the empty string. tl;dr; the current behavior as well as the previous (i.e. before merging the pr) behavior are incorrect.

[jvshahid]

Fixed the XSLT failure on a branch, will look at the other failures as soon as I can.