Bug 109382

Summary:	Method for setting XSLT engine is difficult, error prone & inconsistent with rest of configuration process
Product:	[Retired] Red Hat Web Application Framework	Reporter:	Daniel Berrangé <berrange>
Component:	other	Assignee:	Dennis Gregorovic <dgregor>
Status:	CLOSED RAWHIDE	QA Contact:	Jon Orris <jorris>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	nightly	CC:	berrange, richardl
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-01-26 21:15:18 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	106481

Description Daniel Berrangé 2003-11-07 11:55:20 UTC

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 15:08:12 UTC

> 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 Berrangé 2003-11-07 15:14:41 UTC

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 Berrangé 2003-11-21 18:11:22 UTC

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 18:19:53 UTC

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 20:14:42 UTC

we'll set sensible defaults to resolve and document

Comment 6 Daniel Berrangé 2004-01-06 19:08:26 UTC

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 21:54:42 UTC

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.