Bug 110587 - "Download XSL Files" doesn't work under PatternStylesheetResolver
"Download XSL Files" doesn't work under PatternStylesheetResolver
Product: Red Hat Web Application Framework
Classification: Retired
Component: other (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Berrange
Jon Orris
Depends On:
  Show dependency treegraph
Reported: 2003-11-21 11:03 EST by Vadim Nasardinov
Modified: 2007-08-01 14:48 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-01 14:48:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Vadim Nasardinov 2003-11-21 11:03:36 EST
I am at //core-platform/dev/...@38194 and my server is configured as

|$ ccm get waf.debug
|$ ccm get waf.templating.stylesheet_resolver

Setting "waf.debug" to "true" results in a "Debug Options" panel being
added to each displayed bebop page, with the following clickable

    View document XML
    Download XSL files
    Display transformation

That's all good. Clicking on "Download XSL files" is supposed to
trigger a download of a .jar file containing the XSL stylesheets used
for the currently viewed page.  What I get instead is the following

java.util.zip.ZipException: ZIP file must have at least one entry
        at java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:288)
        at com.arsdigita.bebop.page.PageTransformer.servePage(PageTransformer.java:310)
        at com.arsdigita.bebop.page.PageTransformer.servePage(PageTransformer.java:152)

I added a couple of logging statements to PageTransformer.java:

|$ cd /var/vadim/p4checkout/core-platform/dev/src/com/arsdigita/bebop/page/
|$ nl -ba PageTransformer.java | head -n 310 | tail -n 11
|   300              s_log.info("Collecting files into a jar.");
|   301              final Iterator files = template.getDependents().iterator();
|   302              while (files.hasNext()) {
|   303                  URL file = (URL)files.next();
|   304                  s_log.info("file=" + file + "; proto=" + file.getProtocol());
|   305                  if (file.getProtocol().equals("file")) {
|   306                      jos.putNextEntry(new JarEntry(file.getPath()));
|   307                  }
|   308              }
|   309              s_log.info("Done collecting files into a jar.");
|   310              jos.finish();

The output looks like so:

page.PageTransformer - Collecting files into a jar.
page.PageTransformer - file=http://el-vadimo.home:9000/resource/ROOT/__ccm__/apps/acs-subsite/xsl/index.xsl; proto=http
... 35 similar lines elided for brevity ...
page.PageTransformer - file=http://el-vadimo.home:9000/resource/ROOT/packages/ui/xsl/debug-panel.xsl; proto=http
page.PageTransformer - Done collecting files into a jar.

The jar ends up being empty, because none of the referenced URLs are

See also bug 109171.
Comment 1 Daniel Berrange 2003-11-21 11:14:06 EST
There are in fact two bugs here. The first, as per Vadim's comment is
that it only processes file:// URLs, the second is that it doesn't
actually add the files themselves to the ZIP - it merely creates the
headers. This was fixed in London 5.2 Core: 

 Change 30838 by dan@dan-aplaws on 2003/05/12 08:46:39

   So it turns out adding a JarEntry doesn't actually add the
   sodding file to the JAR, it just creates the MANIFEST entry.

This shouldn't be applied directly however, since it uses
java.io.File. When fixing it we need to use java.net.URL#openStream to
read the bytes. The only (small) complication is generating the paths
for the XSL files, but basically the way style sheet resolution works
we ought to be able to simply strip off 'http://el-vadimo:9000/' from
the HTTP urls & '/' from the file URLs to generate relative paths.

On a related note, while fixing this, it is probably a good idea to
move the code that generates the ZIP file out of the presentation
manager & into a c.a.templating.XSLTemplate#toZIP() method or similar. 
Comment 2 Randy Graebner 2003-11-21 11:21:32 EST
>On a related note, while fixing this, it is probably a good idea to
>move the code that generates the ZIP file out of the presentation
>manager & into a c.a.templating.XSLTemplate#toZIP() method or similar. 

Just as an FYI, there are some zip utilities in
com.arsdigita.util.Files.  They only deal with Files but it may make
sense to consolidate as much as possible.  

Comment 3 Daniel Berrange 2004-01-28 12:07:01 EST
This is now resolved  in p4 39829
Comment 4 David Lawrence 2006-07-17 23:38:35 EDT
QA_READY has been deprecated in favor of ON_QA. Please use ON_QA in the future.
Moving to ON_QA.

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