-
Notifications
You must be signed in to change notification settings - Fork 57
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
Add Exception Type Parsing #1031
base: master
Are you sure you want to change the base?
Add Exception Type Parsing #1031
Conversation
@@ -62,6 +67,11 @@ public SignatureVisitor visitParameterType() { | |||
return this; | |||
} | |||
|
|||
@Override | |||
public SignatureVisitor visitExceptionType() { | |||
return this; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't exceptionTypes
be updated somewhere, perhaps here? Otherwise - how it gets populated?
Edit: I've removed locally this method and collection+getter and the test is fine with such change. Do we need exceptionTypes
in this class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @pzygielo. This code doesn't do anything right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will review - I was simply cherry-picking from our fork (I didn't make the original change)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an inherited method from the SignatureVisitor
class from ASM: SignatureVisitor#L153.
There is an identical implementation of it over in the SignatureVisitorImpl
class here in HK2: SignatureVisitorImpl#L88.
So I assume the original intent was to simply mirror the behaviour of the SignatureVisitorImpl
class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be to follow established pattern, right.
What would be the role of exceptionTypes
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would need to spend some time digging into it with a debugger - it's a bit abstract for my eyes to dry-run through.
The interface method from MethodModel
(and presumably MethodModelImpl
) gets used over in Payara for MicroProfile OpenAPI processing here and here.
Within HK2 itself the important changes within this PR seem to be working on the MethodModel
within the ModelClassVisitor
(here). This code is preceded by reading the method signature (which is where this MethodSignatureVisitorImpl
class comes into play), during which at least one code path seems to "visit" the exception type (which is where I start getting lost without a debugger).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Pandrex247, list exceptionTypes
at L39 always stay empty because it never updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
list
exceptionTypes
at L39 always stay empty because it never updated.
Probably we don't know. getExceptionTypes
returns original, mutable list so this MIGHT be updated anywhere, out of control of the class.
I understand getParameters
does the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand
getParameters
does the same.
But parameters
collection is filled in the visitParameterType()
method at L63 of the MethodSignatureVisitorImpl
class.
Actual exception types processing occurs in the ModelClassVisitor
class beginnin with L284.
mutable list so this MIGHT be updated anywhere, out of control of the class.
In this case even out of control HK2.
This comment was marked as resolved.
This comment was marked as resolved.
Exception types are now parsed from MethodModels. Signed-off-by: Matthew Gill <[email protected]>
da3e1c6
to
3c058fe
Compare
Ports an old addition we've had in our Payara patched-src fork for a while.
Exception types are now parsed from MethodModels.
This is used within Payara to help with MicroProfile OpenAPI support.