-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Processing a self-referencing subResource leads to a series of recursive scans #1424
Comments
…a series of recursive scans
Thanks for this, but setting aside the solution, what would be the expected output? Wouldn't you end up with something like /resource/{*subresource}? |
Hi Ron, In the case of its wadl generation, the wadl initially has an resource entry for this subresource unexpanded. And every time when I make a call a step deeper, this entry gets expanded. I don't think this expanding of the path on demand in this way is nice. So I don't know how swagger should show recursive sub-resources. I'll revert the initial PR for now because I don't think it is right to bookkeep sub-resources per reader anyway. regards, aki |
Yeah, that's a recursive definition, which is generally ok, but is not supported in Swagger (for now), so I don't think we can add support for in the reader. That said, perhaps we should find a nicer way to deal with it than go into an infinite loop. |
Yes. I agree with you. So for fixing the infinite loop, we need to cache the resources seen during the recursive traversal and just stop going deeper. I think we should make a private recursive read method with a resource map. With this approach, we won't stop and come back too early, which could happen when we cache the resources at the reader instance. I'll think about it. Let me know how you think. |
well, we don't support the recrusiveness at all, so no need to expand anything ;) |
…r a recursive reference
Hi Ron, |
Thanks for all the effort, @elakito, it's really great. I'll do my best to review it tomorrow. |
#1424 avoid an endless scan by not scanning resources over a recursive reference
Thanks Ron and Tony, |
The problem is described here.
https://groups.google.com/forum/#!topic/swagger-swaggersocket/v_VTJgMm3PM
I'll attach a PR with a proposed solution which caches classes at the Reader instance.
Alternatively, a slightly more complex solution would be to create a private read method that looks like the current recursively invoked read method but with an extra argument of a map that can be used to detect the self-referencing loop during its recursive calls. The original read method can call this private read method with an empty map object.
Which one to take depends on how the reader is used and how its expected behavior should be.
And I would like to ask for your feedback.
regards, aki
The text was updated successfully, but these errors were encountered: