Skip to content
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

InvocationContextTest likely incomplete #405

Open
struberg opened this issue Jan 25, 2023 · 6 comments
Open

InvocationContextTest likely incomplete #405

struberg opened this issue Jan 25, 2023 · 6 comments

Comments

@struberg
Copy link

struberg commented Jan 25, 2023

Hi!

It seems that the Test got totally changed. It now tests something very different than before, but without updating the spec section!
In commit 021f446 a lot of similar changes got made:

 -    @Interceptors({ Interceptor8.class, Interceptor9.class })
 +    @SimpleBinding

But this changes the mechanism from using javax.interceptor.Interceptors to CDI style Interceptors. This is something very different!

@manovotn
Copy link
Contributor

Hello

The assertions in the test haven't changed since 2017, the supporting classes indeed did change.
Can you please point me to the section of interceptor specification which would explain why the test is now invalid or asserting something unexpected?

@struberg
Copy link
Author

struberg commented Jan 25, 2023

This test used to check the CDI support for javax.interceptor.Interceptors. Not it tests support for the @InterceptorBinding mechanism. Thats's just something very different, don't you agree? Of course, we should ideally test both!

@manovotn
Copy link
Contributor

This test used to check the CDI support for javax.interceptor.Interceptors

Did it really? If you take a look at the @SpecAssertion values on the test in question and cross-reference it with TCK audit file, you will see that these tests in fact perform assertions on InvocationContext object. I couldn't find anything in the test that would be specific to usage or functionality of javax.interceptor.Interceptors versus bindings.
So no, I do not agree - both variants of the test IMO test the same functionality.

@struberg
Copy link
Author

Applying interceptor via @InterceptorBinding is something different than via @jakarta.interceptor.Interceptors. It's a different mechanism. You ASSUME that both behave the same internally. But how can you guarantee that if you removed the test for the later mechanism?

@manovotn
Copy link
Contributor

You ASSUME that both behave the same internally.

That's not true, I simply stated that the test is asserting InvocationContext, not functionality or behavior of either @InterceptorBinding or @jakarta.interceptor.Interceptors - there are different tests for those.
And as far as I can tell from the specification, you are allowed to use InvocationContext regardless of what interceptor "style" you chose.

Therefore, my initial question stands:

Can you please point me to the section of interceptor specification which would explain why the test is now invalid or asserting something unexpected?

@struberg
Copy link
Author

struberg commented Jan 25, 2023

You are right, it's not invalid or asserting something unexpected. But we only test one out of 2 different routes. We imo should test both.

edit I changed the title of the ticket to better reflect my request. Indeed it's not 'broken' but more 'incomplete'

@struberg struberg changed the title InvocationContextTest likely broken InvocationContextTest likely incomplete Jan 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants