Doh! OK - I should have checked that one more time. I assumed that since I had a problem with the 1.5.0 version before, and then when I checked out the trunk, rebuilt my repository, and ran the test again, and it ran fine, that the thing was OK. It turns out I had a 1.5.0 checkout in my workspace, and that's the one I built, thinking that it was the trunk. Then I looked again, and saw "Trunk with dependencies". Double Doh! So that fixed my initial problem but left this one.
I like the Swallow in a room analogy :-).
OK - I owe a night on the house.
Cheers,
- Ole
Emmanuel Lecharny wrote:
I did spent the two minutes to go through the steps you gave. Here is
what I get
1) I have lost 2 minutes, which is not really a pb.
2) Obviously, you are totally lost in your problem, trying to find a
problem somewhere where there are not, simply because you are like a
swallow in a room, bumping your head in all the walls trying
desesperatly to find an exit
3) Simply take a break. When you can't find out the solution, but have
a workaround, step back, breeze, have a smoke/drink/sleep/pot, and
come back with a fresh brain
4) There is no problem. You simply are using an _old_ version of the
jars, not the trunk. Your pom.xml is FU. I already told you that, but
you were stuck in your idea that something should be wrong with the
code. (bad attitude ...)
Here is what I get when I run mvn eclipse:eclipse on your project :
[INFO] Wrote Eclipse project for "archetype.instance.testing" to
/home/elecharny/apacheds/archetype.instance.testing.
[INFO]
Sources for some artifacts are not available.
Please run the same goal with the -DdownloadSources=true
parameter in order to check remote repositories for sources.
List of artifacts without a source archive:
o xerces:xercesImpl:2.0.2
o junit:junit:3.8.1
o antlr:antlr:2.7.6
o org.apache.directory.server:apacheds-jdbm-store:1.5.0
o org.apache.directory.shared:shared-ldap-constants:0.9.6
o jdbm:jdbm:1.0
o org.slf4j:nlog4j:1.2.25
o org.apache.directory.server:apacheds-schema-extras:1.5.0
o commons-lang:commons-lang:2.1
o org.apache.directory.server:apacheds-schema-bootstrap:1.5.0
o org.apache.directory.server:apacheds-schema-registries:1.5.0
o commons-collections:commons-collections:3.0
o org.apache.directory.shared:shared-ldap:0.9.6
o org.apache.directory.server:apacheds-core-shared:1.5.0
o checkstyle:checkstyle:2.2
o org.apache.directory.server:apacheds-btree-base:1.5.0
o org.apache.directory.server:apacheds-bootstrap-partition:1.5.0
o org.apache.directory.server:apacheds-bootstrap-extract:1.5.0
o org.apache.directory.server:apacheds-constants:1.5.0
o org.apache.directory.server:apacheds-utils:1.5.0
o org.apache.directory.server:apacheds-core:1.5.0
o org.apache.directory.shared:shared-asn1:0.9.6
Obviously, 1.5.0 != 1.5.1-SNAPSHOT and 0.9.6 != 0.9.7-SNAPSHOT
try that in your pom.xml, it should be better :
<dependency>
<groupId>org.apache.directory.server</groupId>
<artifactId>apacheds-core</artifactId>
<version>1.5.1-SNAPSHOT</version>
</dependency>
Ok, no harm. I just wanted you to realize that you _must_ analyze the
reasons, not the symptoms. Symptoms does not generate the problem.
They just exhibit it.
Emmanuel
On 6/16/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:
Emmanuel,
Here's the thing. I just did a fresh checkout from the trunk. If the
logging file is there, the exception is non existent. That means the
patch works right? If the logging file is removed or renamed, then
the exception happens. I think the only way to verify this is to go
through the steps I gave. Could you please just do the steps I gave
you? It will only take two two minutes. I promise.
I would do the patchy thingy, but that's a learning curve for me. It
will take me at least 20 minutes to figure out patchy stuff. Yes it's
one of those things I need to learn, but the process I gave you only
takes two minutes. I win :-) I'll tell you what. If you run through
the steps, and the exception does not occur, I owe you a night of
beers in Chicago or Paris, or some convention city, whichever
comes first :-)
Cheers,
- Ole
Emmanuel Lecharny wrote:
> Ole Ersoy a écrit :
>
>>
>>
>> Emmanuel Lecharny wrote:
>>
>>> Ole Ersoy a écrit :
>>>
>>>> Emmanuel,
>>>>
>>>>
>>>> Suppose I was using an old jar. Why does my test pass then?
>>>
>>>
>>> I told you three times that the bug happens ONLY if you run the test
>>> with a log4j in DEBUG mode, otherwise the toString() method is
>>> _never_ called. This is why your test pass when you don't use the
>>> logging file.
>>
>>
>> I think this is what you are missing.
>>
========================================================================
>> This is why your test pass when you don't use the logging file.
>>
========================================================================
>>
>> I am using the logging file. It's only if the logging file is renamed
>> or removed that the exception happens.
>
> Oh, ok. I inverted the context. Nevertheless, this toString() method is
> only called when in DEBUG mode. So this is not something you are likely
> to have, unless you are in DEBUG mode.
>
>> I gave the verification process. We've spent way more time discussing
>> this than it would have taken you to just run through the verification
>> steps. If you tell me that renaming the logging file should cause
>> this exception, then I'll close the issue.
>
> I'm not telling that shooting the messenger (here, the logging file)
> will help at all. I just say that - and if you look carefully at the
> code I posted - this is definitively *not* a code in the trunk, as it
> has been fixed.
>
> Look at the line 320, and simply tell me if this can throw the
exception
> or not. If the response is :"yes, this is strange, it should not but I
> get the excpetion", then you have *another* problem elsewhere.
That's it.
>
> Do me a favor : patch the code of this method, add a try { ... }
catch (
> ArrayOutOfBoundException e) { e.printStackTrace(); } in it, and if the
> stacktrace is produced, I own you a beer, ok ?
>
> Thanks.
> Emmanuel.
>
> PS : Chris fixed the bug 3 months ago. I applied the patch. Twice.
>
>
>
