[jira] [Commented] (GERONIMO-6692) OpenAPI SchemaProcessor causes a StackOverflowException when processing schema for a class field that reference's it's own class
[
https://issues.apache.org/jira/browse/GERONIMO-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761727#comment-16761727
]
Romain Manni-Bucau commented on GERONIMO-6692:
--
Hi [~jmeen], i just deployed a snapshot, will wait some days for a release but
we can plan it in a few. Don't hesitate to create a thread on our mailing list
to see if others have some pending changes.
> OpenAPI SchemaProcessor causes a StackOverflowException when processing
> schema for a class field that reference's it's own class
>
>
> Key: GERONIMO-6692
> URL: https://issues.apache.org/jira/browse/GERONIMO-6692
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: OpenAPI_1.0.5
>Reporter: James Meen
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: OpenAPI_1.0.6
>
>
> A webapp being scanned by SchemaProcessor class of the Geronimo OpenAPI
> extension has a field that references the class it is a part of, for
> example...
> {code:java}
> public class aClass
> {
> ...
> public List getAList() { ... }
> ...
> }
> {code}
> There is no check in OpenAPI SchemaProcessor for this and it eventually
> causes a StackOverflowException.
> I doubt this issue is limited to List and will probably also happen if the
> field type is singular of the same parent class.
> The front-end exception the user sees is completely unrelated to the real
> exception. This causes a great amount of debugging time stepping through to
> determine the root cause for a relatively large application.
> Propose to somehow either support this when mapping to an OpenAPI model.
> Also, failing the possibility of a solution as above, this case should be
> detected by the schema processor and handled accordingly either skipping the
> field and/or raising a suitable warning/exception in a way that the user
> knows what/why it is failing or excluded (ultimately to save the user having
> to debug through the schema processing). A stackoverflow should not happen.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GERONIMO-6692) OpenAPI SchemaProcessor causes a StackOverflowException when processing schema for a class field that reference's it's own class
[
https://issues.apache.org/jira/browse/GERONIMO-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16761654#comment-16761654
]
James Meen commented on GERONIMO-6692:
--
Hi [~romain.manni-bucau], would there be any chance of a SNAPSHOT or release
with this fix in it?
> OpenAPI SchemaProcessor causes a StackOverflowException when processing
> schema for a class field that reference's it's own class
>
>
> Key: GERONIMO-6692
> URL: https://issues.apache.org/jira/browse/GERONIMO-6692
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: OpenAPI_1.0.5
>Reporter: James Meen
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: OpenAPI_1.0.6
>
>
> A webapp being scanned by SchemaProcessor class of the Geronimo OpenAPI
> extension has a field that references the class it is a part of, for
> example...
> {code:java}
> public class aClass
> {
> ...
> public List getAList() { ... }
> ...
> }
> {code}
> There is no check in OpenAPI SchemaProcessor for this and it eventually
> causes a StackOverflowException.
> I doubt this issue is limited to List and will probably also happen if the
> field type is singular of the same parent class.
> The front-end exception the user sees is completely unrelated to the real
> exception. This causes a great amount of debugging time stepping through to
> determine the root cause for a relatively large application.
> Propose to somehow either support this when mapping to an OpenAPI model.
> Also, failing the possibility of a solution as above, this case should be
> detected by the schema processor and handled accordingly either skipping the
> field and/or raising a suitable warning/exception in a way that the user
> knows what/why it is failing or excluded (ultimately to save the user having
> to debug through the schema processing). A stackoverflow should not happen.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GERONIMO-6692) OpenAPI SchemaProcessor causes a StackOverflowException when processing schema for a class field that reference's it's own class
[
https://issues.apache.org/jira/browse/GERONIMO-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760859#comment-16760859
]
James Meen commented on GERONIMO-6692:
--
Awesome, that appears to have resolved the issue as I am no longer seeing any
exceptions. Much appreciated... thanks!
> OpenAPI SchemaProcessor causes a StackOverflowException when processing
> schema for a class field that reference's it's own class
>
>
> Key: GERONIMO-6692
> URL: https://issues.apache.org/jira/browse/GERONIMO-6692
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: OpenAPI_1.0.5
>Reporter: James Meen
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: OpenAPI_1.0.6
>
>
> A webapp being scanned by SchemaProcessor class of the Geronimo OpenAPI
> extension has a field that references the class it is a part of, for
> example...
> {code:java}
> public class aClass
> {
> ...
> public List getAList() { ... }
> ...
> }
> {code}
> There is no check in OpenAPI SchemaProcessor for this and it eventually
> causes a StackOverflowException.
> I doubt this issue is limited to List and will probably also happen if the
> field type is singular of the same parent class.
> The front-end exception the user sees is completely unrelated to the real
> exception. This causes a great amount of debugging time stepping through to
> determine the root cause for a relatively large application.
> Propose to somehow either support this when mapping to an OpenAPI model.
> Also, failing the possibility of a solution as above, this case should be
> detected by the schema processor and handled accordingly either skipping the
> field and/or raising a suitable warning/exception in a way that the user
> knows what/why it is failing or excluded (ultimately to save the user having
> to debug through the schema processing). A stackoverflow should not happen.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GERONIMO-6692) OpenAPI SchemaProcessor causes a StackOverflowException when processing schema for a class field that reference's it's own class
[
https://issues.apache.org/jira/browse/GERONIMO-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760812#comment-16760812
]
Romain Manni-Bucau commented on GERONIMO-6692:
--
[~jmeen] should be fine now since we lazily initialize the components model
> OpenAPI SchemaProcessor causes a StackOverflowException when processing
> schema for a class field that reference's it's own class
>
>
> Key: GERONIMO-6692
> URL: https://issues.apache.org/jira/browse/GERONIMO-6692
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: OpenAPI_1.0.5
>Reporter: James Meen
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: OpenAPI_1.0.6
>
>
> A webapp being scanned by SchemaProcessor class of the Geronimo OpenAPI
> extension has a field that references the class it is a part of, for
> example...
> {code:java}
> public class aClass
> {
> ...
> public List getAList() { ... }
> ...
> }
> {code}
> There is no check in OpenAPI SchemaProcessor for this and it eventually
> causes a StackOverflowException.
> I doubt this issue is limited to List and will probably also happen if the
> field type is singular of the same parent class.
> The front-end exception the user sees is completely unrelated to the real
> exception. This causes a great amount of debugging time stepping through to
> determine the root cause for a relatively large application.
> Propose to somehow either support this when mapping to an OpenAPI model.
> Also, failing the possibility of a solution as above, this case should be
> detected by the schema processor and handled accordingly either skipping the
> field and/or raising a suitable warning/exception in a way that the user
> knows what/why it is failing or excluded (ultimately to save the user having
> to debug through the schema processing). A stackoverflow should not happen.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GERONIMO-6692) OpenAPI SchemaProcessor causes a StackOverflowException when processing schema for a class field that reference's it's own class
[
https://issues.apache.org/jira/browse/GERONIMO-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760721#comment-16760721
]
James Meen commented on GERONIMO-6692:
--
I've tested locally and still finding an exception.
I believe it's because in the test case, you specifically and unconditionally
call
{code:java}
final Components components = new ComponentsImpl();
{code}
before mapSchemaFromClass.
But in the case I'm seeing, the components parameter is null.
If I set your test case with a null components parameters, then it fails with a
NPE.
In AnnotationProcessor.java, it looks like api.setComponents is only ever being
set if there is a SecurityScheme annotation.
e.g...
{code:java}
Stream.of(annotatedType.getAnnotationsByType(SecurityScheme.class))
.forEach(s -> {
if (api.getComponents() == null) {
api.setComponents(new ComponentsImpl());
}
api.getComponents().addSecurityScheme(s.securitySchemeName(),
mapSecurityScheme(s));
});
{code}
Thanks
> OpenAPI SchemaProcessor causes a StackOverflowException when processing
> schema for a class field that reference's it's own class
>
>
> Key: GERONIMO-6692
> URL: https://issues.apache.org/jira/browse/GERONIMO-6692
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: OpenAPI_1.0.5
>Reporter: James Meen
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: OpenAPI_1.0.6
>
>
> A webapp being scanned by SchemaProcessor class of the Geronimo OpenAPI
> extension has a field that references the class it is a part of, for
> example...
> {code:java}
> public class aClass
> {
> ...
> public List getAList() { ... }
> ...
> }
> {code}
> There is no check in OpenAPI SchemaProcessor for this and it eventually
> causes a StackOverflowException.
> I doubt this issue is limited to List and will probably also happen if the
> field type is singular of the same parent class.
> The front-end exception the user sees is completely unrelated to the real
> exception. This causes a great amount of debugging time stepping through to
> determine the root cause for a relatively large application.
> Propose to somehow either support this when mapping to an OpenAPI model.
> Also, failing the possibility of a solution as above, this case should be
> detected by the schema processor and handled accordingly either skipping the
> field and/or raising a suitable warning/exception in a way that the user
> knows what/why it is failing or excluded (ultimately to save the user having
> to debug through the schema processing). A stackoverflow should not happen.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GERONIMO-6692) OpenAPI SchemaProcessor causes a StackOverflowException when processing schema for a class field that reference's it's own class
[
https://issues.apache.org/jira/browse/GERONIMO-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760615#comment-16760615
]
Romain Manni-Bucau commented on GERONIMO-6692:
--
[~jmeen] thanks a lot for the review and testing, I pushed another fix about it
using components references, can you give it a try please?
> OpenAPI SchemaProcessor causes a StackOverflowException when processing
> schema for a class field that reference's it's own class
>
>
> Key: GERONIMO-6692
> URL: https://issues.apache.org/jira/browse/GERONIMO-6692
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: OpenAPI_1.0.5
>Reporter: James Meen
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: OpenAPI_1.0.6
>
>
> A webapp being scanned by SchemaProcessor class of the Geronimo OpenAPI
> extension has a field that references the class it is a part of, for
> example...
> {code:java}
> public class aClass
> {
> ...
> public List getAList() { ... }
> ...
> }
> {code}
> There is no check in OpenAPI SchemaProcessor for this and it eventually
> causes a StackOverflowException.
> I doubt this issue is limited to List and will probably also happen if the
> field type is singular of the same parent class.
> The front-end exception the user sees is completely unrelated to the real
> exception. This causes a great amount of debugging time stepping through to
> determine the root cause for a relatively large application.
> Propose to somehow either support this when mapping to an OpenAPI model.
> Also, failing the possibility of a solution as above, this case should be
> detected by the schema processor and handled accordingly either skipping the
> field and/or raising a suitable warning/exception in a way that the user
> knows what/why it is failing or excluded (ultimately to save the user having
> to debug through the schema processing). A stackoverflow should not happen.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GERONIMO-6692) OpenAPI SchemaProcessor causes a StackOverflowException when processing schema for a class field that reference's it's own class
[
https://issues.apache.org/jira/browse/GERONIMO-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16760358#comment-16760358
]
James Meen commented on GERONIMO-6692:
--
Hi Romain, it took me a ages staring at it, testing, trying to reproduce the
same issue but with your new cyclic test case... eventually I reproduced it.
I will now add a PR showing you the specific test case that still causes the
stack overflow.
The two things that I found important factors to produce it...
# "private SomeClass child;" must appear after "private List
children;" in SomeClass.
# Use of a RelatedClass is important.
Thanks
> OpenAPI SchemaProcessor causes a StackOverflowException when processing
> schema for a class field that reference's it's own class
>
>
> Key: GERONIMO-6692
> URL: https://issues.apache.org/jira/browse/GERONIMO-6692
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: OpenAPI_1.0.5
>Reporter: James Meen
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: OpenAPI_1.0.6
>
>
> A webapp being scanned by SchemaProcessor class of the Geronimo OpenAPI
> extension has a field that references the class it is a part of, for
> example...
> {code:java}
> public class aClass
> {
> ...
> public List getAList() { ... }
> ...
> }
> {code}
> There is no check in OpenAPI SchemaProcessor for this and it eventually
> causes a StackOverflowException.
> I doubt this issue is limited to List and will probably also happen if the
> field type is singular of the same parent class.
> The front-end exception the user sees is completely unrelated to the real
> exception. This causes a great amount of debugging time stepping through to
> determine the root cause for a relatively large application.
> Propose to somehow either support this when mapping to an OpenAPI model.
> Also, failing the possibility of a solution as above, this case should be
> detected by the schema processor and handled accordingly either skipping the
> field and/or raising a suitable warning/exception in a way that the user
> knows what/why it is failing or excluded (ultimately to save the user having
> to debug through the schema processing). A stackoverflow should not happen.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
