Issue Running on JBoss EAP 6.1 #54
Comments
|
Hi @alanhay |
|
Hi. I am running on JDK 1.8 |
// FIXME:
// Currently, we have to do this as the user may have an older vesion of xalan on their classpath which would be
// used otherwise.
xformFactory = TransformerFactory.newInstance("com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl", null);It doesn't look good/nice. If anyone wants/needs to change the default factory in certain configuration – it should be done using an external to the library means, f.e. setting the FWIW, I've recently done a major cleanup to the |
|
Just want to report that I run into the same problem and found here. +1 for a fix. Meanwhile I'm trying to figure out a walk around. My environment: openjdk "1.8.0_131" + wildfly 10.1.0 |
|
Just got hit by this on WildFly 10.1 under OpenJDK 8 (131-b11, as shipped from Debian jessie-backports): I'm trying to test the library as a replacement for Flying Saucer for generating PDFs on my web application, but this is the first time I find something throwing an Error (which you can't catch if you're expecting an Exception instead). Looks like something with JBoss/WildFly classloaders is interfering (the class EXISTS on rt.jar!), and it sounds no fun to mess with classloaders at all. |
danfickle
added a commit
that referenced
this issue
Dec 6, 2017
… working on JBoss, Wildfly. Thanks @estevandiedrich
Closed
|
Hopefully this is all fixed. Can anyone test? The user can now configure the TransformerFactory to use with the builder: builder.useTransformerFactoryImplementationClass("...");or to use whatever is available just pass in null: builder.useTransformerFactoryImplementationClass(null); |
|
Sorry for the delay, I was on vacation until this week, and it wasn't until today when I had a chance to test the fixes. So far everything seems to be working fine. Logs are quite verbose now, so I guess it's just matter of tuning the logging services to ignore those (mostly) harmless stackdumps: All I now need is to test, do some benchmarks, and hopefully go to production with this later this year, as iText just EOL'd the 5.x branch... Thanks again! |
This was referenced Mar 27, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have an issue running on JBoss EAP 6.1 which seems to be down to some kind of Xalan / XML parser conflict. I note that the line in question has a //FIXME comment so wonder if you can advise of any workaround. My code is running fine on Jetty.
EAP stacktrace:
which is triggered by the following code:
As TransformerFactory throws an Error rather than an Exception it looks your catch{} block does not execute.
I don't know much about these things but seems to be because JBoss includes specific version of Xalan and Xerces as modules. Drilling down into the modules directory I can find a file named javax.xml.transform.TransformerFactory with the following content:
org.apache.xalan.processor.TransformerFactoryImpl
I have tried excluding these modules via the jboss-deployment-descriptor and bundling a javax.xml.transform.TransformerFactory file with the application but with no success.
The text was updated successfully, but these errors were encountered: