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
(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):
Steps to Reproduce:
> 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,
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:
$ p4 print \
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
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.
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
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.