I had to create a class at work for handling some files. I started with
an input stream. What I needed, though, required caching and being able
to check whether the file was still valid. In this case I soon realized
that I would have to reinvent the Excalibur Source interface since I had
to cache the Validity (or something like it) along with the information
about the file. In the end it made far more sense to just use the
Source interface. I ended up extending the Excalibur Source
implementations or creating my own though, as my Validity checking
didn't match any of the existing implementations exactly.
The point is, if you are planning on caching your files and checking
whether they are valid or not just using java.net, etc. isn't going to
be sufficient.
Ralph
Grzegorz Kossakowski wrote:
Carsten Ziegeler pisze:
I agree that our Environment abstraction was awkward - it introduced
abstraction that never was a
real abstraction and mostly duplicated existing, quite nice servlet API.
At least now I fail to see coherent, nice to use standard Java API that
Excalibur's Source and
SourceFactory duplicates. As for now I can only see obstacles like:
new URL("blabla/foo");
will fail with java.net.MalformedURLException: no protocol: blabla/foo
so one must use:
new URL(baseURL, "blabla/foo");
Who will judge if given path is relative and requires baseURL instance? How one
will get this
baseURL instance?
Guys, it's non-sense...
