fix - correct typeFullName for member with generic type, issue 105

[khemrajrathore]

No description provided.

[fabsx00]

See comment

[khemrajrathore]

@fabsx00 Have raised a new commit which persists the generic information in typeFullName

[DavidBakerEffendi]

I haven't had much time to look into this, but also check this thread: #2655

[fabsx00]

Can you elaborate? What is the effect of this change now that typeFullName stays the same, or does it not?

[khemrajrathore]

@DavidBakerEffendi Thanks for the thread, I went over it. To frame my understanding, two points which are related to this PR.
1st - Creating a data structure which handles the generics, for which you have proposed a few approaches
2nd - There is an argument here which talks about not adding generics in typeFullName.

Regarding 2nd point, earlier this PR was made based on a similar understanding of not including generics in typeFullName, but as per a comment by @fabsx00, I have modified the PR to include the generics in typeFullName as well.

Open to further discussion

[khemrajrathore]

Can you elaborate? What is the effect of this change now that typeFullName stays the same, or does it not?

Yes, In earlier version of this PR the typeFullName for

import org.apache.kafka.clients.consumer.Consumer;
private Consumer<String, Integer> consumer;

was org.apache.kafka.clients.consumer.Consumer

now with further change as per your comment it is
org.apache.kafka.clients.consumer.Consumer<String,Integer>

The reason for the PR was the <unresolvedNamespace>.poll methodFullName for the call node poll, wanted to have a resolved namespace for the member consumer and the callNode poll

[fabsx00]

Observed some fluke with a jssrc test here, but this one doesn't touch jssrc, so, that seems unrelated.