cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: [WEB-INF] MicroStep #1: getRealPath()
Date Fri, 31 Jan 2003 21:45:11 GMT
On 31/1/03 16:38, "Vadim Gritsenko" <vadim.gritsenko@verizon.net> wrote:

> Pier Fumagalli wrote:
> 
>> I see quite extensively throughout the code, the use of "getRealPath"... In
>> my book, this is always true:
>> 
>> new URL("file:" + getRealPath(x)).equals(getResource(x));
>> 
>> Unless I overlooked something. I don't quite remember why it wasn't
>> deprecated in Servlet 2.3, but definitely, to me, it doesn't make much
>> sense.
>> 
>> What if as microstep #1 we deprecated getRealPath() in favor of
>> getResource(), and went around in the entire code-base replacing and fixing
>> stuff?
>> 
>> Then in the getRealPath() call in both CommandlineContext and HttpContext
>> should become something like
>> 
>> public string getRealPath(String path) {
>>    URL url = getResource(path);
>>    if ("file".equals(url.getProtocol()) {
>>        return new File(url.getPath()).absolutePath()
>>    }
>>    return(null);
>> }
>> 
>> And would be deprecated... Is there something I _massively_ overlooked?
> 
> javac works only with files, resource just won't cut it. Some other
> places also need file instead of resource.

Absolutely right. But in details, javac needs a specific kind of resource,
the libraries and classes against which it needs to compile, and given that
now all we do is look in "WEB-INF/classes" and "WEB-INF/lib/*.(jar|zip)",
well, that should be placed somewhere else (we shouldn't rely on getRealPath
for that).

If, by other places, well, if you're talking about something like
DirectoryGenerator and stuff, they should know _exactly_ what they're about
to do, throwing a ResourceNotFoundException if/when needed, as the
DirectoryGenerator does.

If the other places are (like) the filesystem-based cache store, well,
that's another quite big assumption. We need it, as it is, that's for sure,
but IMO, we should as well be able to point out where those specific
requirements are (such as the compilation "classpath" or the cache
directory) and act accordingly.

Having getRealPath in the Context is just too much of a wild assumption that
will fool developers in falling into a mined field where (in my opinion)
they shouldn't be allowed to fall...

Calls to getRealPath are 21 in _all_ our codebase (good) and I don't know
how many times me and Stefano complained about it on the Servlet API expert
group! :-) :-) :-)

> BTW, I recently greped source for WEB-INF and found that there are
> several places wich trying to find file. I propose to move this code
> into one place, say, CocoonServlet and Main, and save context file path
> into Context attribute - thus we can remove these calculations from
> other places.

I'd like to find out what specific assumptions are made on top of the
"WEB-INF" name (totally, 12 in all codebase), try to figure out what is
their specific requirement, and one-by-one see if they can fit into a better
(cleaner?) picture...

Have fun! :-)

    Pier


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message