Red Hat Bugzilla – Bug 109382
Method for setting XSLT engine is difficult, error prone & inconsistent with rest of configuration process
Last modified: 2007-04-18 12:59:14 EDT
Description of problem: The mechanism for configuring which XSLT transformer to use has taken a huge step backwards in ease of use. In previous CCM deployments we could simply set xslEngine="resin" (Or 'saxon', 'xsltc', 'xalan', 'jd.xslt') in the config.vars file used to generate enterprise.init Now the only way to change this is to set shell environment variables to reference the full java class names corresponding to the XSL engine (ie you can even remember the class name in the first place), before running the 'ccm start'. This must be fixed such that it is consistent with the rest of the configuration process & easy to use: ie, it should be as simple as: ccm set waf.templating.xsl_engine=resin (Or saxon, xsltc, etc....) The 'waf.templating.xsl_engine' should not have a default value, so if an advanced user wants to directly set the javax.xml.transform.TransformerFactory property directly they can do so (but that is very much a niche use case) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
> The 'waf.templating.xsl_engine' should not have a default value Sounds like a bad idea. Can we support both short names and full class names? So, for example, if waf.templating.xsl_engine=foo.bar.Baz then we check if "foo.bar.Baz" is a known supported short name for a known supported XSLT processor. If it is, we get the class name mapped to this shortcut. If if it is not a supported shortcut, then we check if it is a classname, and if so, does it implement the TransformerFactory interface? If it does, we are all set. If it doesn't, display an error message.
The idea of also allowing a 'shortname' as an alias for a full class name sounds like a very useful extension to the ClassParameter convertor. Likewise verifying that it implements a given interface .
See also comments on bug 109957 >Parenthetically speaking, changing the transformer is a pain in the >butt. Had to figure out the following variable needs to be exported: >JAVA_TRANSFORMER_FACTORY=org.apache.xalan.processor.TransformerFactoryImpl
Documented in $ p4 print \ //documentation/core/dev/install-guide/prod-install-prep.sgml#18 | head -n 284 | tail -n 10 <para>Tomcat 4.1.<replaceable>x</replaceable> uses the AElfred non-validating parser instead of the Xerces parser. AElfred will not work, and Xerces is used instead. The XML and XSL parsers are controlled by the Tomcat startup script, and can be modified by setting the <varname>DOCUMENT_BUILDER_FACTORY</varname>, <varname>SAX_PARSER_FACTORY</varname>, and <varname>JAVA_TRANSFORMER_FACTORY</varname> environment variables. </para>
we'll set sensible defaults to resolve and document
The current solution of environment variables has been causing no end of pain for PS developers on Rickshaw, so I've fixed this in the London codebase at p4 39136 & 39138.
integrated @39377. Note that classes may need to be added to the classpath manually in order to set the new parameters to certain values. Example: 04:50:27 dgregor@galileo ccm$ ccm set waf.xml.xsl_transformer=resin *** Error *** Parameter waf.xml.xsl_transformer has the following errors: No such class: com.caucho.xsl.Xsl 04:50:36 dgregor@galileo ccm$ env CLASSPATH=/opt/resin/2.1.4/lib/resin.jar ccm set waf.xml.xsl_transformer=resin 04:50:58 dgregor@galileo ccm$ Dan and I discussed deferring the classname check until later. However, after a bit of hacking around, I couldn't figure out how to do this. So, I left the behavior as it is.