directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <>
Subject Re: [jira] Commented: (DIRSERVER-970) Hot Partition Fails With ArrayIndexOutOfBoundsException
Date Fri, 15 Jun 2007 23:11:30 GMT
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
       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 jdbm:jdbm:1.0
         o org.slf4j:nlog4j:1.2.25
         o commons-lang:commons-lang:2.1
         o commons-collections:commons-collections:3.0
         o checkstyle:checkstyle:2.2

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 :


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.


On 6/16/07, Ole Ersoy <> 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.
> >
> >
> >

Emmanuel Lécharny

View raw message