[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
RE: [xsl] {java} JNDI lookup for a file - returning a StreamSource to URIResolver and xalan, saxon, jd.xslt, resin
Subject: RE: [xsl] {java} JNDI lookup for a file - returning a StreamSource to URIResolver and xalan, saxon, jd.xslt, resin From: "Robert Koberg" <rob@xxxxxxxxxx> Date: Fri, 29 Aug 2003 05:23:19 -0700 |
Hi, > -----Original Message----- > From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx [mailto:owner-xsl- > list@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Michael Kay > Sent: Friday, August 29, 2003 1:18 AM > > I suspect you aren't doing a setSystemId() on the StreamSource. In > theory it should be possible to supply a Source with no known systemID, > so long as it doesn't contain any xsl:includes or other things that > depend on its base URI. But it tends to be fragile - the general > assumption in XSLT is that the base URI of nodes, in both source > documents and stylesheets, is known. > > I'll go into more detail of the Saxon crash if you tell me which version > you are using. Sorry, I am using the 6.5.3 version. Also I am using version 1.5.3 of jd.xslt. Thanks for any help, -Rob > > Michael Kay > > > -----Original Message----- > > From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx > > [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of > > Robert Koberg > > Sent: 29 August 2003 04:27 > > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx; resin-interest@xxxxxxxxxx > > Subject: [xsl] {java} JNDI lookup for a file - returning a > > StreamSource to URIResolver and xalan, saxon, jd.xslt, resin > > > > > > Hi, > > > > I am seeing inconsistent behavior when getting file based > > resources through JNDI lookups and then returning a > > StreamSource to an URIResolver. When using the same XSLs in a > > non-JNDI based setup all processors work correctly. When > > using JNDI and 'pre-building' the Source, Xalan recognizes > > the Source and performs the transformation without errors -- > > Saxon, jd.xslt and Resin fail. > > > > In my live webapp I am strictly file system based, but I want > > to abstract that so I can plug in different repositories like > > Tamino, LDAP, etc. > > > > I am trying something like the following in a custom URIReolver: > > > > public Source resolve( String href, String base ) > > { > > StreamSource source = null; > > if ( href.startsWith( "xsl_" ) ) { > > source = this.project.openSource( href ); > > System.out.println( href + " = " + source ); > > } > > return source; > > } > > > > The lookup for the primary XSL (the one that does the > > xsl:includes) is resolved correctly in all processors. > > > > The resolver that is set on the TransformerFactory. The > > source variable is being returned to the transformation(?) > > or, definitely, at least the resolver... > > > > (FWIW, I have the latest Xalan in my $JAVA_HOME/libs/endorsed > > directory, Saxon and jd.xslt are in the webapp's lib directory) > > > > For the JNDI provider I am using: > > javax.naming.Context.INITIAL_CONTEXT_FACTORY="com.sun.jndi.fsc > > ontext.RefFSCo > > ntextFactory" > > > > The javax.naming.Context.PROVIDER_URL is set correctly and > > the DirContext is available. > > > > I have tried the following in Caucho's Resin: > > <system-property > > javax.xml.transform.TransformerFactory="com.icl.saxon.Transfor > > merFactoryImpl > > "/> > > <system-property > > javax.xml.transform.TransformerFactory="jd.xml.xslt.trax.Trans > > formerFactoryI > > mpl"/> > > <system-property > > javax.xml.transform.TransformerFactory="org.apache.xalan.proce > > ssor.Transform > > erFactoryImpl"/> > > > > Xalan recognizes the Source and performs the transformation > > without errors. > > > > Saxon, jd.xslt and Resin fail giving the errors below > > ('xsl_global_definitions' is the first 'identifier' that > > comes into the resolver). > > > > Any ideas on what I am doing wrong or how I can fix this? > > > > Thanks, > > -Rob > > > > (the default Resin 2.1.10 implementation fails, but only > > gives a NullPointerException on my servlet filter) > > > > -oO Saxon Oo- > > > > xsl_global_definitions = > > javax.xml.transform.stream.StreamSource@1536eec > > TransformPreviewSiteXmlFilter.navigate:java.lang.NullPointerException > > java.lang.NullPointerException > > at > > com.icl.saxon.style.XSLGeneralIncorporate.getIncludedStyleShee > > t(XSLGeneralIn > > corporate.java:104) > > at > > com.icl.saxon.style.XSLStyleSheet.spliceIncludes(XSLStyleSheet > > .java:421) > > at > > com.icl.saxon.style.XSLStyleSheet.preprocess(XSLStyleSheet.java:346) > > at > > com.icl.saxon.PreparedStyleSheet.setStyleSheetDocument(Prepare > > dStyleSheet.ja > > va:176) > > at > > com.icl.saxon.PreparedStyleSheet.prepare(PreparedStyleSheet.java:133) > > at > > com.icl.saxon.TransformerFactoryImpl.newTemplates(TransformerF > > actoryImpl.jav > > a:127) > > <snip why="going into my code"/> > > ----------------------------------------------------------- > > > > -oO jd.xslt Oo- > > > > xsl_global_definitions = > > javax.xml.transform.stream.StreamSource@8990e4 > > TransformPreviewSiteXmlFilter.navigate:javax.xml.transform.Tra > > nsformerConfig > > urationException: jd.xml.xslt.parser.XsltPar > > seException: '' includes directly or indirectly itself > > (baseUri='' Element=xsl:include (line 15)) > > javax.xml.transform.TransformerConfigurationException: > > jd.xml.xslt.parser.XsltParseException: '' includes directly > > or in directly itself (baseUri='' Element=xsl:include (line 15)) > > at > > jd.xml.xslt.trax.TransformerFactoryImpl.getException(Unknown > > Source) > > at > > jd.xml.xslt.trax.TransformerFactoryImpl.newTemplates(Unknown > > Source) > > at > > jd.xml.xslt.trax.TransformerFactoryImpl.newTemplates(Unknown > > Source) > > <snip why="going into my code"/> > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] {java} JNDI lookup for a , Michael Kay | Thread | RE: [xsl] {java} JNDI lookup for a , Robert Koberg |
[xsl] (EOT) Incrementing a Global v, Rajendra S Rawat | Date | Re: [xsl] Re: Re: Incrementing a Gl, Mukul Gandhi |
Month |