RE: {java} JNDI lookup for a file - returning a StreamSource to URIResol

Hi,

> -----Original Message-----
> From: owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com 
> [mailto:owner-xsl-
> list(_at_)lists(_dot_)mulberrytech(_dot_)com] 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(_at_)lists(_dot_)mulberrytech(_dot_)com
> > [mailto:owner-xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com] On Behalf Of
> > Robert Koberg
> > Sent: 29 August 2003 04:27
> > To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com; 
> > resin-interest(_at_)caucho(_dot_)com
> > 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(_dot_)xml(_dot_)transform(_dot_)stream(_dot_)StreamSource(_at_)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(_dot_)xml(_dot_)transform(_dot_)stream(_dot_)StreamSource(_at_)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