eCube The XSLT Profiler.

Troubleshooting




Loading of library

When starting catchXSL! it is not necessary that you specifiy the path where the shared library for time measurement is to be found. The tool tries to find this out by itself. But it may still occur that in your environment this doesn't work. You'll see an according message then. In that case you have to do the following things:
For Linux and SunOS users on intel platforms:
You have to set the environment variable LD_LIBRARY_PATH to the following before starting the profiler. For Linux:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PROFILER_HOME/bin/linux_x86

SunOS:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PROFILER_HOME/bin/sunos_x86


For Windows users:
Copy the the file $PROFILER_HOME/lib/windows_x86/libgettimeofday.dll under <windir>/system32.


TOP



The resulting HTML file looks poor

The generated HTML file with your profile results needs to have access to the CSS file result.css which is to be found in $PROFILER_HOME. Make sure that you've copied result.css to the same directory where your generated result HTML is to be found.



TOP




Does not run at all

If catchXSL! does not run at all, we can just give you the awesome hint of checking your classpath again and also check what jar-files you have in your JDK's lib- and ext-directories.

But if it looks as if catchXSL! comes up but seems to have some problems when transforming your files (you probably get something like a ProcessingException or TransformerException), it is always a good idea to try to transform your files with the desired processor without catchXSL!. Look at the guides delivered with Saxon and Xalan and try to call them with your input files and with the same classpath settings as you try to run catchXSL!.

Maybe your files still cannot be transformed at all, then of course catchXSL! cannot profile them either.



TOP




Memory problems

Ambitiuos tests have shown that catchXSL! may run into an OutOfMemoryException when profiling exhaustive transformations. Well, as we collect a lot of infos this can happen. One good advice is to close unused projects when running the gui version. Of course you can start the Java VM with the options -Xms and -Xmx with the values high enough. But keep in mind that the data size of the delivered profiling results (either as HTML or XML) is still huge. Maybe it's a good idea to shorten the input-xml-file. catchXSL! is tool to inspect xsl-instructions and not the data amount of your input-files.

TOP