Infinite recurssion while resolving implemented interfaces of inner classes

Hi Konstantin,

I can't find (or figure out) the source code required to reproduce the bug. The best would be to have a minimal sample source code + some QDox API calls to make it apparent.

I could of course modify line 213 in JavaClass and add the dollar, but I'd really prefer to have a failing testcase to illustrate why this modification is needed.

Could you provide a (failing) test case that looks something like the following?

public void testJiraQdox40() {
String sourceCode = ""
+ "package foo;\n"
+ "public class WrappedInternalContextAdapter implements InternalContextAdapter

";
JavaDocBuilder builder = new JavaDocBuilder();
builder.addSource(new StringReader(sourceCode));
JavaClass aClass =
builder.getClassByName("foo.WrappedInternalContextAdapter ");
// Perhaps this is what causes the infinite recursion? That's ok. A failing test gives us a clue...
assertNotNull(aClass);
}

It's really simple to write (failing) unit tests for QDox. Try it out See QDox' JavaDocBuilderTest for inspiration.

Cheers,
Aslak

diff to test case to demonstrate this bug.

there is no assert, because this infinite recursion produces segv...

With "$" + everything works fine.

I'm unable to reproduce the claimed infinite recursion with this testcase. I ran your supplied test against QDox' CVS HEAD, and it passes.

Some questions:

1) What do you mean by "this infinite recursion produces segv..."?

2) Am I correct if I'm assuming that you are getting a java.lang.StackOverflowError?

3) Can you verify that your test fails against CVS HEAD? (I can't make it fail).

4) Can you attach a stack trace here?

I did a clean checkout , and it failed.

1) What do you mean by "this infinite recursion produces segv..."?

It goes into infinite recursion. I'm able to see it through my logging statements.

2) Am I correct if I'm assuming that you are getting a java.lang.StackOverflowError?

From maven side I get segv ( on linux ) - your mileage may vary...
But real cause should be stack overflow...

4) Can you attach a stack trace here?
unfortunately no... Thereis also no error report from junit - it's just empty...

Maybe we are out of synch due to some snapshot dependecies you compiled yourself?

Anyway, in resolveType() when you check inner classes, you shall take into account unqualified name of inner class ( which starts from last $ ) , and not just endsWith() - or you will resolve
InternalVelocityContext as foo.bar.baz.Blurge$WrappedInternalVelocityContext - which is not desired behaviour...

I'm ataching real world example which bite my ass off...

real world example

I'm still unable to make the test fail. Both with the patch and the attached source code. Anyway, I have applied the code change, as it still makes all tests pass. (And it seems correct).

Well this also could be some weird transient error. If class was resolved beforehand, it does not happen.

But you commented out a line you added...