Title: RE: Servlets and relative paths

What I had to do was put the xsl files in the root directory for my webapp where I could make the href the full url (http://localhost/webapp/sections.xsl) This was the only way I could get it to work correctly. Obviously this exposes your stylesheet to anyone who requests that url. I finally gave up on the include since I was only sharing with 2 stylesheets, but I still use it for my dtd, which has the same problem when processed by a stylesheet.

I didn't think that I would get it to work as I wanted since Xalan(library I'm using) doesn't know about tomcat, and I couldn't find anywhere in xalan to set a default path to look for include files/dtd's. Therefore it always assumes the 'working dir' for the application when looking for includes.

The ugly option is that you could make the include path = "../webapps/MyContext/sections.xsl" assuming your context is under webapps. Of course this is inconsistant with other paths in your application(i.e. getResourceAsStream()) and is a pain to maintain if you move your context.

The other ugly option being chucking the includes into the bin directory, but that defeats the purpose of separating contexts.

Charlie

-----Original Message-----
From: Chris McNeilly [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 30, 2001 2:22 PM
To: [EMAIL PROTECTED]
Subject: RE: Servlets and relative paths


No, my problem is that I can use this method to read the xsl file just
fine.  It's the includes inside the xsl file that aren't working.

For example, inside the xsl file (which I read into the servlet using
your pointer from the earlier email) there is the line

<xsl:include href='sections.xsl'/>

and I get an error saying that it cannot find file
tomcat/bin/sections.xsl.  Which, of course, it cannot, since the file is
located in Meta-Inf/.

Chris

> -----Original Message-----
> From: Bo Xu [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 30, 2001 10:45 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Servlets and relative paths
>
>
> Chris McNeilly wrote:
>
> > Thanks Bo.  This is certainly a step in the right direction.
> >
> > I can now include the xml file and xsl file using relative
> paths.  My
> > only problem now is that there are xsl includes inside the
> xsl files and
> > they are still being loaded incorrectly (using the
> tomcat/bin directory
> > as root, not the servlet context).  Any ideas?
> >
> > Thanks,
> >
> > Chris
> >
> > > Chris McNeilly wrote:
> > >
> > >  > I've got a servlet and am trying to open files.  The
> > > problem is that its
> > >  > defaulting to the tomcat/bin directory whenever I attempt
> > > to refer to
> > >  > them.  How can I change this?  Hardcoding the path isn't
> > > such a good
> > >  > idea as my dev environment is different from production.
> > > These are xml
> > >  > and xsl files and they are located on the webroot.
> > >  >
> > >  > Thanks,
> > >  >
> > >  > Chris
> > >
> > > Hi :-)  from several emails in Servlet-List and this List:
> > >
> > > * InputStream is = this.getServletContext().
> > >
> > > getResourceAsStream("/WEB-INF/testApp.properties");
> > >
> > > now testApp.properties is in myapp/WEB-INF/
> > >
> > >
> > > *
> > > - InputStream is =
> > > this.getClass().getResourceAsStream("testApp.properties");
> > > - InputStream is = Thread.currentThread().getContextClassLoader().
> > >
> getResourceAsStream("myservlet.conf");
> > >
> > >    now, (normally),  myservlet.conf/testApp.properties is in
> > > myapp/WEB-INF/classes
> > >
> > >
> > > Bo
> > > May.29, 2001
> > >
> > [...]
>
> Hello Chris :-)  I am not sure, do you want to  read a file in
> TOMCAT_HOME/bin?
> is the following possible?
>
> - put MyUtil.class in TOMCAT_HOME/bin
> - include TOMCAT_HOME/bin/MyUtil.class into CLASSPATH
> - put testApp.properties into TOMCAT_HOME/bin
> - in MyServlet, write the following code:
>   ...
>   MyUtil myobject=new MyUtil();
>   InputStream is =
>   myobject.getClass().getResourceAsStream("testApp.properties");
>   ...
>
> I don't test it,  if it is not right, please correct it, thanks! :-)
>
>
> Bo
> May.30, 2001
>
>
>
>

Reply via email to