RE: [PATCH] JspReader: using getResourceAsStream() instead of get RealPath()

[Petr Jiricka <pe...@netbeans.com>]

Does this mean that ServletContextFacade.getResourceAsStream() is broken on
Windows ? If that's the case, then I would say getResourceAsStream() should
be fixed, since ServletContextFacade is the implementation of
javax.servlet.ServletContext.

My preference would be to use resources rather than Fles everywhere (the
only place where you would use File would be to find out whether the JSP is
outdated in JspCompiler), even if it would mean that you must pass a
non-null JspCompilationContext to JspReader's constructor. Command line
compilation would be changed to convert file names to resources before
compilation. Anyhow, I think that the docBase parameter to the command line
compilation should be mandatory (or it should be documented how the default
docBase is acquired).

Also, sorry for forgetting to change File.separator to '/' in my patch.

Finally, can I ask what is the reason why you stopped supporting an
arbitrary URL as a docBase in Tomcat ?

Thanks
Petr

> -----Original Message-----
> From: rubys@us.ibm.com [mailto:rubys@us.ibm.com]
> Sent: Thursday, March 23, 2000 4:18 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: [PATCH] JspReader: using getResourceAsStream() instead of
> getRealPath()
> 
> 
> 
> 
> >until we hear from Sam why it was changed back to getR.P().
> 
> The problem was originally reported by Ramesh.  If this 
> change gets backed
> out the change, try double clicking on startup.bat in Windows 
> and then try
> any JSP.  You will find that 
> build\tomcat\bin\webapps\examples\jsp (note
> the "bin") in the entry.
> 
> If somebody can figure out a patch to getResourceAsStream which will
> respect the value of TOMCAT_HOME, then I have no problem with 
> changing it
> back.  Fixing getRealPath was easy...it clearly was dealing 
> with a file.
> 
> - Sam Ruby
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 

Re: [PATCH] JspReader: using getResourceAsStream() instead of getRealPath()

[Costin Manolache <co...@eng.sun.com>]

> My preference would be to use resources rather than Fles everywhere (the
> only place where you would use File would be to find out whether the JSP is
> outdated in JspCompiler), even if it would mean that you must pass a
> non-null JspCompilationContext to JspReader's constructor. Command line
> compilation would be changed to convert file names to resources before
> compilation. Anyhow, I think that the docBase parameter to the command line
> compilation should be mandatory (or it should be documented how the default
> docBase is acquired).

It's one point of view - but you must understand that other people might have
different requirements. In this particular case probably getResource is ok,
but don't generalize.

GetResource and URL can't replace File and RealPath. You don't have:

- access to various file information - lastModified, canWrite ( usefull if your

servlet generates static files - like a page builder)

- speed - you add an extra layer, more string operations and garbage collection

- random access - that's important if you have a zip file or a GIF and you want

to extract the size

> Finally, can I ask what is the reason why you stopped supporting an
> arbitrary URL as a docBase in Tomcat ?

- made everything complex ( a lot of ifs() and hard to read code )
- made it slower ( a lot of String manipulation)
- can't work in any production site that uses Apache, IIS or NES as web server
( since all web servers are using files, can't server from URLs)
- speed - if it's not a file but an http URL - you'll just double the response
time.
- speed - if it's a jar you need to do many file system accesses
- might confuse people into thinking it's a good idea to do that - and it's not

- confusing for people developing tomcat - we want to get decent performance,
it's not possible if at every step you need to use URLs and do complex tests
- 99% of people are using normal web servers, based on file systems.

Costin