geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Meen (JIRA)" <j...@apache.org>
Subject [jira] [Reopened] (GERONIMO-6692) OpenAPI SchemaProcessor causes a StackOverflowException when processing schema for a class field that reference's it's own class
Date Mon, 04 Feb 2019 15:29:00 GMT

     [ https://issues.apache.org/jira/browse/GERONIMO-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

James Meen reopened GERONIMO-6692:
----------------------------------

Thank you for such a fast response.

I have tested locally and still finding the same problem.  After stepping through, the fix
approach looks good but the specific problem I see now is that the newSchema is not being
put into the cache on SchemaProcessor Line 57 (never executed for this field) because it
is not passing the conditions.  So when the check for existingSchema is done in the cache
at line 96/97, it is never in the cache - so the same stack overflow occurs.

I believe this something to do with it being a generics based type i.e. List<Class>.

If it helps, the "model" value comes through as this at line 56...

model ParameterizedTypeImpl (id=1051) 
 actualTypeArguments Type[1] (id=1052) 
 ownerType null 
 rawType Class<T> (java.util.List) (id=1054) 
 annotationData Class$AnnotationData (id=1055) 
 annotationType null 
 cachedConstructor null 
 classLoader null 
 classRedefinedCount 0 
 classValueMap null 
 componentType null 
 enumConstantDirectory null 
 enumConstants null 
 genericInfo ClassRepository (id=1056) 
 module Module (id=823) 
 name "java.util.List" (id=1057) 
 newInstanceCallerCache null 
 packageName "java.util" (id=1058) 
 reflectionData SoftReference<T> (id=1059)

 

java.util.List<com.project.service.rest.datamodels.AClass>
[class com.project.service.rest.datamodels.AClass]
null
interface java.util.List
java.lang.Class$AnnotationData@5fb07655
null
null
null
0
null
null
null
null
sun.reflect.generics.repository.ClassRepository@1404e6f5
module java.base
java.util.List
null
java.util
java.lang.ref.SoftReference@275d72fc

> 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<aClass> 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)

Mime
View raw message