Saxon

Legacy ID: #4549129 Legacy Poster: Michael Kay (mhkay)

As I'm sure you realise, there's no information here for us to go on. You've clearly done something wrong in building your JAR but there's no way of telling what. Remember that when you run using the -jar option, the classpath is ignored. The -TJ option on the Saxon command line switches on diagnostic trace of the search for extension functions. There's an equivalent option in the API - but it depends which API you are using. It will tell you whether it's failing to find the class, or failing to find the method within the class. Check that the class and method are both public.

Legacy ID: #4549208 Legacy Poster: Andy (hagoss01)

Thanks for the quick reply. As for the classpath being ignored, the custom jar that is using the Saxon API also contains the code that the XSLT should be executing. I can provide more detailed info, but I am not sure what all should be supplied. I do know that the code base has not changed, the same version of Saxon is being used (8.0) and the class and method are both public. The only thing that I expect has changed is the old app was built using java 1.42 and I am running 1.5/1.6 I am using Saxon 8.0, how can I turn on the traces to java calls option? That would be helpful. Thanks again for the prompt response! Andy

Legacy ID: #4549274 Legacy Poster: Michael Kay (mhkay)

Saxon 8.0 is a very old release, the current version is 8.9.0.4. That's unlikely to be relevant to your problem, but it makes it difficult to help you. I've no idea whether the diagnostic API was present in that release, you'll have to search around to see if you can find it. Looking in the source of net.sf.saxon.Transform to see what happens to the -TJ flag should give a clue.

Legacy ID: #4549602 Legacy Poster: Andy (hagoss01)

Oddly enough, the original problem went away. A new problem surfaced where the call to the transform method could not find the file. This frustrated me for quite a while before I rewrote the call to the transform method. Dealing with legacy code and legacy programmers, you never know what to expect. Originally, the call to transform used a StreamResult variable that was just passed a file object. I changed it as follows: private void transform(File src, File xslFile, File dest) throws TransformerException { //Load xslt loadXSL(xslFile); StreamSource instream = new StreamSource(src); try { FileOutputStream temp = new FileOutputStream(dest); StreamResult outstream = new StreamResult(temp); transform.transform(instream, outstream); temp.close(); } catch (TransformerException te) { System.out.println(te.getMessage()); } catch (Exception e) { System.out.println(e.getMessage()); } } by creating the output file as a FileOutputStream, all my problems went away. Now, why did I have a problem in the first place? I have NO idea. this code worked fine before. I can only suspect that it is a difference between 1.42 and 1.5 of the JDK. I just wanted to share my resolution so that anyone else would know.

Legacy ID: #4549857 Legacy Poster: Michael Kay (mhkay)

In older versions of JAXP, the code in the StreamSource and StreamResult classes when given a File as a constructor was quite buggy.