Il giorno 30/apr/04, alle 02:11, Joerg Heinicke ha scritto:
Without claiming to read Ugo's mind I think that's exactly the point.
Too many ..s means that there are more directories to walk up then
it is possible. /../ is only the most simple sample. /foo/../../ is
another one. And
Ugo Cei dijo:
Re: code reuse. I'm quite eager too reuse code, usually, but I'm -1 on
adding another JAR (and another dependency) only for 30 lines of code.
There are other places where we can take advantage of this jar.
Best Regards,
Antonio Gallardo
Antonio Gallardo wrote:
There are other places where we can take advantage of this jar.
If so, please go on and change them to make use of the library, but
remember that current users of our code may rely on some undocumented
behaviour (like, for instance, never returning null from
Nathaniel Alfred wrote:
The 30 lines are already in an available JAR, only normalize() is
currently private there:
http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/sourceresolve/src/jav
a/org/apache/excalibur/source/SourceUtil.java?rev=1.5view=auto
Hmmm, interesting ... nowadays you can find an
Il giorno 29/apr/04, alle 02:48, Joerg Heinicke ha scritto:
After Cheche's bug report I had a look at NetUtils. Though Ugo fixed
it with a quick fix, it does not really solve the problem as a test
with the updated NetUtilsTestCase and the NetUtils before my latest
commit can easily show.
Ugo Cei wrote:
Il giorno 29/apr/04, alle 02:48, Joerg Heinicke ha scritto:
After Cheche's bug report I had a look at NetUtils. Though Ugo fixed
it with a quick fix, it does not really solve the problem as a test
with the updated NetUtilsTestCase and the NetUtils before my latest
commit can
Joerg Heinicke wrote:
After Cheche's bug report I had a look at NetUtils. Though Ugo fixed it
with a quick fix, it does not really solve the problem as a test with
the updated NetUtilsTestCase and the NetUtils before my latest commit
can easily show.
My problem is that there are many problems
On Thu, 2004-04-29 at 14:44, Stefano Mazzocchi wrote:
Joerg Heinicke wrote:
After Cheche's bug report I had a look at NetUtils. Though Ugo fixed it
with a quick fix, it does not really solve the problem as a test with
the updated NetUtilsTestCase and the NetUtils before my latest commit
Bruno Dumon wrote:
My advice: in the 2.1 series, leave that code as is, especially as we're
close to a release. It's too easy to brake it.
The current code does not pass all the tests. Since we have a testcase,
I suggest (and volunteer for) doing the simplest thing that could
possibly work and
Joerg Heinicke wrote:
3. while the Tokenizer correctly works on /../ the
NetUtils.normalize() method has a problem with it:
What is the correct output for /../? I'd say /, but the testcase
expects /../.
Ugo
Ugo Cei u.cei at cbim.it writes:
3. while the Tokenizer correctly works on /../ the
NetUtils.normalize() method has a problem with it:
What is the correct output for /../? I'd say /, but the testcase
expects /../.
Good question. I did not thought much about it when adding it as
Ugo Cei wrote:
Joerg Heinicke wrote:
3. while the Tokenizer correctly works on /../ the
NetUtils.normalize() method has a problem with it:
What is the correct output for /../? I'd say /, but the testcase
expects /../.
I would consider /../ an error.
What does new File(/../foo) do?
I've just committed a new version that:
- passes all tests
- uses only JDK core classes
- has less lines of code than the previous one
Hope you all like it.
Ugo
On 29.04.2004 22:12, Ugo Cei wrote:
I've just committed a new version that:
- passes all tests
- uses only JDK core classes
- has less lines of code than the previous one
Hope you all like it.
Very good, but ... first the good news:
The build fails now if a test fails.
And there is a new
Joerg Heinicke dijo:
On 29.04.2004 22:12, Ugo Cei wrote:
I've just committed a new version that:
- passes all tests
- uses only JDK core classes
- has less lines of code than the previous one
Hope you all like it.
Very good, but ... first the good news:
The build fails now if a
Antonio Gallardo dijo:
Joerg Heinicke dijo:
On 29.04.2004 22:12, Ugo Cei wrote:
I've just committed a new version that:
- passes all tests
- uses only JDK core classes
- has less lines of code than the previous one
Hope you all like it.
Very good, but ... first the good news:
The
Il giorno 29/apr/04, alle 23:36, Joerg Heinicke ha scritto:
The mentioned class java.net.URI#normalize() in JDK 1.4 behaves
different for two cases:
foo/bar1/bar2/bar3/../../.. results in foo/ instead of foo and
that's absolutely correct.
/../ results in /../ instead of / and I don't know ...
Il giorno 29/apr/04, alle 23:53, Antonio Gallardo ha scritto:
Yep. I found it :-D
http://jakarta.apache.org/commons/io/apidocs/org/apache/commons/io/
FilenameUtils.html#normalize(java.lang.String)
This meethod returns null if there are too many ..s, which strikes me
as rather bizarre.
Ugo
On 29.04.2004 23:36, Joerg Heinicke wrote:
/../ results in /../ instead of / and I don't know ...
http://www.ietf.org/rfc/rfc2396.txt
5.2. Resolving Relative References to Absolute Form
6) a) All but the last segment of the base URI's path component is
copied to the buffer. In other
Ugo Cei dijo:
Il giorno 29/apr/04, alle 23:53, Antonio Gallardo ha scritto:
Yep. I found it :-D
http://jakarta.apache.org/commons/io/apidocs/org/apache/commons/io/
FilenameUtils.html#normalize(java.lang.String)
This method returns null if there are too many ..s, which strikes me
as rather
On 30.04.2004 01:19, Antonio Gallardo wrote:
Yep. I found it :-D
http://jakarta.apache.org/commons/io/apidocs/org/apache/commons/io/
FilenameUtils.html#normalize(java.lang.String)
This method returns null if there are too many ..s, which strikes me
as rather bizarre.
Can you explain more about
Joerg Heinicke dijo:
On 30.04.2004 01:19, Antonio Gallardo wrote:
Yep. I found it :-D
http://jakarta.apache.org/commons/io/apidocs/org/apache/commons/io/
FilenameUtils.html#normalize(java.lang.String)
This method returns null if there are too many ..s, which strikes me
as rather bizarre.
After Cheche's bug report I had a look at NetUtils. Though Ugo fixed it
with a quick fix, it does not really solve the problem as a test with
the updated NetUtilsTestCase and the NetUtils before my latest commit
can easily show.
My problem is that there are many problems in different places in
23 matches
Mail list logo
