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.5&view=auto
Hmmm, interesting ... nowadays you can find an
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
NetUtils.nor
>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.
>
> Ugo
The 30 lines are already in an available JAR, only normalize() is
currently private there:
http://cvs.apache.org/viewcvs.cgi/avalon-excali
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
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 FilenameUti
On 30.04.2004 02:04, Antonio Gallardo wrote:
This method returns null if there are too many ".."s, which strikes me
as rather bizarre.
Can you explain more about that?
/../ --> null
That's what Ugo called 'bizarre'.
That is not the point. Even me, can clearly understand that. 8-|
I di
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
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
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
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
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
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
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 .
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 buil
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 tar
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
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?
Ugo Cei 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
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
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 pa
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 co
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 i
Le 29 avr. 04, à 11:52, Upayavira a écrit :
...Doesn't it replace, for example /cocoon/src/java/../webapp with
/cocoon/src/webapp? i.e. removing .. from paths?
FWIW, I have attached the results of
find src -type f -name *.java | xargs -n200 grep 'NetUtils.*normalize'
-Bertrand
results of
find
Il giorno 29/apr/04, alle 11:52, Upayavira ha scritto:
Frankly, I don't even know what NetUtils.normalize is supposed to do,
so I cannot be of any help here.
Doesn't it replace, for example /cocoon/src/java/../webapp with
/cocoon/src/webapp? i.e. removing .. from paths?
Ah, I see. It would have
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 eas
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.
Frankl
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
27 matches
Mail list logo