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

[WFLY-13647] Annotation processing error sun.reflect.annotation.TypeNotPresentExceptionProxy does not indicate issue #13399

Merged
merged 2 commits into from Jul 24, 2020

Conversation

gaol
Copy link
Contributor

@gaol gaol commented Jul 7, 2020

Issue: https://issues.redhat.com/browse/WFLY-13647

There is a bug with Class.getAnnotation() call in JDK < 11 [1] which throws ArrayStoreException when the annotation refers to some classes not found in current class path. The ArrayStoreException confuses user why it failed because the root cause is missing.

This PR tries to catch the exception and give more readable feedback in this case.

[1] https://bugs.openjdk.java.net/browse/JDK-7183985

@wildfly-ci wildfly-ci added the deps-ok Dependencies have been checked, and there are no significant changes label Jul 7, 2020
@bstansberry
Copy link
Contributor

@chengfang or @tadamski or @fl4via please review.

} catch (ArrayStoreException e) {
// https://bugs.openjdk.java.net/browse/JDK-7183985
// Class.findAnnotation() has a bug under JDK < 11 which throws ArrayStoreException
throw EjbLogger.ROOT_LOGGER.missingClassInAnnotation(annotation.getSimpleName(), iface.getName());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suspect we don't need exception handling here. When @Remote @Local is used in a business interface, they do not take any arguments. The no-arg annotation is to indicate that the annotated business interface is a local or remote business interface. For ex,

@Remote 
public interface Calculator {...}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be good if users do it in correct way(like they should package classes referred by the annotation). :)
but what happens if users referred some classes in the business interfaces' Remote annotation by mistake? is it still a valid deployment?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If @Remote or @Local on business interface has param, then it's an application's error, though the spec does not say what should happen in this case. WildFly just ignores the param, which happens after the annotation processing. So to tolerate this type of user errors, it's okay to keep this checking.

@bstansberry bstansberry added the ready-for-merge Only for use by those with merge permissions! label Jul 20, 2020
@bstansberry bstansberry mentioned this pull request Jul 20, 2020
@bstansberry
Copy link
Contributor

@chengfang This needs a conflict resolved.

@chengfang
Copy link
Contributor

@gaol can you update your local repo and increment the log id in EjbLogger @Message(id = 520 to 521, since 520 is already taken?

The failure in Windows JDK11 seem unrelated intermittent failure. I just created WFLY-13682 (JBossWSStringReplaceTestCase.incorrectValueOfModifyWsdlAddressOpeningElement failed intermittently on Windows) to track it separately.

gaol added 2 commits July 21, 2020 11:27
…otPresentExceptionProxy does not indicate issue

- Fix case of missing classes referenced by HandlesTypes in ServletContainerInitializer

Signed-off-by: Lin Gao <lgao@redhat.com>
…otPresentExceptionProxy does not indicate issue

- Fix case of missing classes referenced by Remote or Local in session bean

Signed-off-by: Lin Gao <lgao@redhat.com>
@gaol
Copy link
Contributor Author

gaol commented Jul 21, 2020

@chengfang Thanks for the instructions, I just updated the PR to fix the conflicts. :)

@chengfang
Copy link
Contributor

Linux JDK8 and Linux JDK11 jobs failed on July 20, 2020, with 12 failures in MixedDomainDeployment700TestCase. I think they are unrelated failures and can be ignored for this PR. I've just reopened the following JIRA to track it separately:

WFLY-12649
Deal with mixed-domain failures in the OpenJ9 jobs

jamezp added a commit to jamezp/wildfly that referenced this pull request Jul 24, 2020
[WFLY-13647] Annotation processing error sun.reflect.annotation.TypeNotPresentExceptionProxy does not indicate issue
@jamezp jamezp merged commit 1044ec2 into wildfly:master Jul 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deps-ok Dependencies have been checked, and there are no significant changes ready-for-merge Only for use by those with merge permissions!
Projects
None yet
5 participants