Thanks for the help.  We did NOT have the 8.9 jars.  it works fine with those jars. 
 
That's good! 

A few parting questions:

1)  is there a way to determine the version of the jar other than checking the creation date?   
 
java -cp c:\...\saxon8.jar net.sf.saxon.Version
 
(or if you forget that, just do net.sf.saxon.Transform with the -t option).
 
 
2) you said that the jar URI is not valid, is there a valid jar URI?  who made this one up if not?  
 
No, there isn't one that's valid. I'm normally very reluctant to do anything nonconformant to standards, but on this occasion I felt I had no choice, as there really is no workaround. I think Sun is the guilty party, but I don't have any evidence....
 
3) what is the recommended way of specifing the URI of a resource in a jar ? 
 
I think you're doing it the only way that's possible. I just wanted you to be aware of the fact that software that handles URIs correctly will not always handle these deviant URIs!
 
Michael Kay
http://www.saxonica.com/ 

On 7/12/07, Michael Kay <mike@saxonica.com> wrote:
Actually
 
jar:file:/home/readyportal/ReadyPortal/services/Portal/wego.war!/stylesheet/oped_1.xsl
 
is not a valid hierarchic URI according to the internet RFCs, and it's rejected by the java.net.URI class for that reason. However, I made some changes to Saxon in 8.9 to allow such non-URIs to be resolved, by using the older java.net.URL class instead. So I'm not entirely sure why this isn't working, but I feel we're homing in on it.
 
I've just done a test like this:
 
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform "
                version="2.0">
 
  <xsl:include href="play.xsl"
    xml:base="jar:file:c:/saxon-issues/saxon-issue-2007-02-12/saxon-resources8-9.zip!/samples/styles/tour.xsl"/>
  <xsl:template name="main">
    <para>test</para>
  </xsl:template>
</xsl:stylesheet>
 
and it works fine.
 
I'm suspicious about the line numbers in your stack trace. You said you were running Saxon 8.9 but these line numbers match Saxon 8.8. And the change to support the JAR: "URI" scheme was made in 8.9. So my next theory is that you're picking up 8.8 instead of 8.9.
 
Michael Kay


From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of ChadDavis
Sent: 11 July 2007 19:41

To: Mailing list for SAXON XSLT queries
Subject: Re: [saxon] stylesheet compiles with command linebutnotfromapplication

Okay.  I've got the info from standard error.   It seems that the path to my includes is being built from the home directory rather than relative to the primary stylesheet.  The included stylesheet is in the same directory as the primary, and was being found there by my older Xalan processor ( but not the Xalan XSLTC processor?).  

Here's the include's from my stylesheet, just to be thorough.

 <xsl:include href="param.xsl"/>
  <xsl:include href="fields.xsl"/>
  <xsl:include href="toc.xsl "/>
  <xsl:include href="body.xsl"/>

And here's the error info.

INFO  wego.xml.WGXSL: transforming style = jar:file:/home/readyportal/ReadyPortal/services/Portal/wego.war!/stylesheet/oped_1.xsl
Warning: Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor
Error at xsl:include on line 9 of jar:file:/home/readyportal/ReadyPortal/services/Portal/wego.war!/stylesheet/oped_1.xsl:
  XTSE0165: java.io.FileNotFoundException : /home/readyportal/param.xsl (No such file or directory)
INFO  wego.xml.WGXSL: TCE
javax.xml.transform.TransformerConfigurationException: Failed to compile stylesheet. 1 error detected.
        at net.sf.saxon.PreparedStylesheet.prepare (PreparedStylesheet.java:140)
        at net.sf.saxon.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:135)
        at wego.xml.WGXSL.createTemplates(WGXSL.java:375)
        at wego.xml.WGXSL.transform (WGXSL.java:216)


You had asked earlier if the systemId was being set.  It was.  And as i said earlier, it was being passed a jar:file type URI.  You can see this exact URI in the above log.  The first line in the log is where I am logging the URI string being passed to the constructor of a  StreamSource.  The code below is doing this.



  log_.info ( "transforming style = " + style );
    if (templates==null)
      templates = instance ().createTemplates (new StreamSource (style), style);



And here is the method that receives the source and calls the factoryImpl.newTemplates()


 public Templates createTemplates (Source source, String key)
    throws WGException
  {
    if (xsl_factory_==null)
      throw new WGException (0, "TRaX (XSLT) Factory not bound.");

     try
    {
      Templates result = xsl_factory_.newTemplates (source);
      if (key!=null && result!=null)
    WGCacheManager.cacheInsert (result, key, CACHE_TYPE, true);
      return result;
    }
    catch (TransformerConfigurationException tce)
    {   
        log_.info ("TCE",tce );
       
       
            StackTraceElement elements[] = tce.getStackTrace();
            for (int i = 0, n = elements.length; i < n; i++) {      
                log_.info( elements[i].getFileName() + ":"
                              + elements[i].getLineNumber()
                              + ">> "
                              + elements[i].getMethodName() + "()");
            }
       
   
 
      throw new WGException (0, "Could not create templates: " + tce);
    }
  }


On 7/11/07, Michael Kay <mike@saxonica.com> wrote:
Compile-time errors are notified to the ErrorListener. The default ErrorListener writes to System.err. In an application server environment, this is likely to end up in some log file somewhere. You either need to find where this log file is, or you need to customize the ErrorListener to write somewhere else. We're not going to be able to diagnose compile time errors if the only thing we see is the final exception that says "1 error detected".
 
Michael Kay


From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of ChadDavis
Sent: 10 July 2007 19:56

To: Mailing list for SAXON XSLT queries
Subject: Re: [saxon] stylesheet compiles with command line butnotfromapplication

I was trying to get some more information from the stacktrace.  You referred to the actual compile time error message?  I'm not sure what you mean.  I couldn't extract any further information from the TransformerConfigurationException.  When i checked the Saxon source code, I found that it is probably an XPathException, but that exception's stack trace is not passed on when the new TransformerConfig..tion is thrown.  How would I get more information about the compilation error? 


javax.xml.transform.TransformerConfigurationException: Failed to compile stylesheet. 1 error detected.
        at net.sf.saxon.PreparedStylesheet.prepare (PreparedStylesheet.java:140)
        at net.sf.saxon.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:135)


On 7/7/07, Michael Kay < mike@saxonica.com> wrote:
OK, so you've picked up Saxon successfully.
 
Next idea: (I'm really guessing here, because you haven't shown me your Java code, or the XSLT code, or the actual compile time error message) - an xsl:include or xsl:import has failed to resolve, because you didn't supply the base URI of the principal stylesheet module. That is, you didn't call setSystemId() on the Source object supplied to newTemplates().
 
If this idea is also wrong, perhaps it's time to stop guessing and look at some diagnostics.
Michael Kayct


From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of ChadDavis
Sent: 07 July 2007 18:07
To: Mailing list for SAXON XSLT queries
Subject: Re: [saxon] stylesheet compiles with command line but notfromapplication

Thanks for the response.  Yeah, I was away from my info when I posted that email.  Sorry about that. 

Do you mean that maybe its picked up Xalan's XSLT processor instead of Saxon.  I'm don't think that is the case.
I'm pretty sure it Saxon.  Here's the top of the stack trace:

javax.xml.transform.TransformerConfigurationException: Failed to compile stylesheet. 1 error detected.
        at net.sf.saxon.PreparedStylesheet.prepare (PreparedStylesheet.java:140)
        at net.sf.saxon.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:135)

If it would help, I can provide the stylesheets themselves. 


Another bit of information . . . while toying around with confirming which XSTL implementation was being used, I pointed the TrasnformerFactory in several directions to see what would happen.  First of all, previously the application was, successfully, using  org.apache.xalan.processor.TransformerFactoryImpl from the Xalan jar.  I then pointed it to the XSLTC implementation in that same Xalan jar --
org.apache.xalan.xsltc.trax.TransformerFactoryImpl -- interestingly, the Xalan XSLTC implementation throws the same error as the Saxon.  I don't yet know enough to extract anything useful from this fact, but it seems like it could help.





On 7/7/07, Michael Kay <mike@saxonica.com > wrote:
The most likely explanation is that your application has picked up Xalan rather than Saxon. But you've provided so little information, it's really impossible to tell.
 
Michael Kay


From: saxon-help-bounces@lists.sourceforge.net [mailto:saxon-help-bounces@lists.sourceforge.net] On Behalf Of ChadDavis
Sent: 07 July 2007 12:48
To: saxon-help@lists.sourceforge.net
Subject: [saxon] stylesheet compiles with command line but not fromapplication

Hello.  I'm migrating an application to Saxon 8.9 B.  In the application, the stylesheets won't compile.  However, when I compile them from the Saxon command line interface, they compile just fine.  They do give the warning about XSLT1.0 under a 2.0 processor, but it works. 
 
What can be the difference?  Are there some different default configuration values using the command line versus using the application api?  Could it be that the command line is using some other resources, e.g. xml parser, that the application isn't using? 
 
Thanks,
Chad

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
saxon-help mailing list
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
saxon-help mailing list
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
saxon-help mailing list
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
saxon-help mailing list
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help