Bug 109382 - Method for setting XSLT engine is difficult, error prone & inconsistent with rest of configuration process
Method for setting XSLT engine is difficult, error prone & inconsistent with...
Status: CLOSED RAWHIDE
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
nightly
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dennis Gregorovic
Jon Orris
:
Depends On:
Blocks: 106481
  Show dependency treegraph
 
Reported: 2003-11-07 06:55 EST by Daniel Berrange
Modified: 2007-04-18 12:59 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-26 16:15:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2003-11-07 06:55:20 EST
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:
Comment 1 Vadim Nasardinov 2003-11-07 10:08:12 EST
> 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.

Comment 2 Daniel Berrange 2003-11-07 10:14:41 EST
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 .
Comment 3 Daniel Berrange 2003-11-21 13:11:22 EST
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
Comment 4 Vadim Nasardinov 2003-11-21 13:19:53 EST
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>
Comment 5 Richard Li 2003-12-09 15:14:42 EST
we'll set sensible defaults to resolve and document
Comment 6 Daniel Berrange 2004-01-06 14:08:26 EST
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.
Comment 7 Dennis Gregorovic 2004-01-14 16:54:42 EST
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.

Note You need to log in before you can comment on or make changes to this bug.