[JBoss JIRA] (JBMDR-76) AnnotatedElementMetaDataLoader.searchForRealBridgeMethodSignature should warn rather than fail if it can't find the original method
12:03 a.m.
James Livingston created JBMDR-76:
-------------------------------------
Summary: AnnotatedElementMetaDataLoader.searchForRealBridgeMethodSignature
should warn rather than fail if it can't find the original method
Key: JBMDR-76
URL: https://issues.jboss.org/browse/JBMDR-76
Project: JBoss MetaData Repository
Issue Type: Bug
Reporter: James Livingston
AnnotatedElementMetaDataLoader.searchForRealBridgeMethodSignature() currently throws an
exception if it can't find any potential matches for the bridge method, however it
only logs a trace message if it finds more than one but can't decide between them.
Since returning null is obviously handled acceptably well, it would probably be better to
log a warning and return null. If there are bridge methods added with unexpected naming,
then JBoss will not fail the deployments.
While the Sun/Oracle/OpenJDK javac only sets the bridge flag for methods with the same
name and compatible parameters, the JVM Specification and Java language Specification do
not actually specify any restrictions on how the flag is used, other than the comment that
is it set by the compiler when creating bridge methods. As such some other tools utilise
it in different ways, such as JBoss AOP setting in on the generated methods ending in
"$aop"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:06 a.m.
[
https://issues.jboss.org/browse/JBMDR-76?page=com.atlassian.jira.plugin.s...
]
James Livingston updated JBMDR-76:
----------------------------------
Description:
AnnotatedElementMetaDataLoader.searchForRealBridgeMethodSignature() currently throws an
exception if it can't find any potential matches for the bridge method, however it
only logs a trace message if it finds more than one but can't decide between them.
Since returning null is obviously handled acceptably well, it would probably be better to
log a warning and return null. If there are bridge methods added with unexpected naming,
then JBoss will not fail the deployments.
While the Sun/Oracle/OpenJDK javac only sets the bridge flag for methods with the same
name and compatible parameters, the JVM Specification and Java language Specification do
not actually specify any restrictions on how the flag is used, other than the comment that
is it set by the compiler when creating bridge methods. As such some other tools could
utilise it in different ways, such as JBoss AOP not removing it on the generated methods
ending in "$aop"
was:
AnnotatedElementMetaDataLoader.searchForRealBridgeMethodSignature() currently throws an
exception if it can't find any potential matches for the bridge method, however it
only logs a trace message if it finds more than one but can't decide between them.
Since returning null is obviously handled acceptably well, it would probably be better to
log a warning and return null. If there are bridge methods added with unexpected naming,
then JBoss will not fail the deployments.
While the Sun/Oracle/OpenJDK javac only sets the bridge flag for methods with the same
name and compatible parameters, the JVM Specification and Java language Specification do
not actually specify any restrictions on how the flag is used, other than the comment that
is it set by the compiler when creating bridge methods. As such some other tools utilise
it in different ways, such as JBoss AOP setting in on the generated methods ending in
"$aop"
AnnotatedElementMetaDataLoader.searchForRealBridgeMethodSignature
should warn rather than fail if it can't find the original method
-----------------------------------------------------------------------------------------------------------------------------------
Key: JBMDR-76
URL: https://issues.jboss.org/browse/JBMDR-76
Project: JBoss MetaData Repository
Issue Type: Bug
Reporter: James Livingston
Attachments: JBMDR-76.diff
AnnotatedElementMetaDataLoader.searchForRealBridgeMethodSignature() currently throws an
exception if it can't find any potential matches for the bridge method, however it
only logs a trace message if it finds more than one but can't decide between them.
Since returning null is obviously handled acceptably well, it would probably be better to
log a warning and return null. If there are bridge methods added with unexpected naming,
then JBoss will not fail the deployments.
While the Sun/Oracle/OpenJDK javac only sets the bridge flag for methods with the same
name and compatible parameters, the JVM Specification and Java language Specification do
not actually specify any restrictions on how the flag is used, other than the comment that
is it set by the compiler when creating bridge methods. As such some other tools could
utilise it in different ways, such as JBoss AOP not removing it on the generated methods
ending in "$aop"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:06 a.m.
[
https://issues.jboss.org/browse/JBMDR-76?page=com.atlassian.jira.plugin.s...
]
James Livingston updated JBMDR-76:
----------------------------------
Attachment: JBMDR-76.diff
AnnotatedElementMetaDataLoader.searchForRealBridgeMethodSignature
should warn rather than fail if it can't find the original method
-----------------------------------------------------------------------------------------------------------------------------------
Key: JBMDR-76
URL: https://issues.jboss.org/browse/JBMDR-76
Project: JBoss MetaData Repository
Issue Type: Bug
Reporter: James Livingston
Attachments: JBMDR-76.diff
AnnotatedElementMetaDataLoader.searchForRealBridgeMethodSignature() currently throws an
exception if it can't find any potential matches for the bridge method, however it
only logs a trace message if it finds more than one but can't decide between them.
Since returning null is obviously handled acceptably well, it would probably be better to
log a warning and return null. If there are bridge methods added with unexpected naming,
then JBoss will not fail the deployments.
While the Sun/Oracle/OpenJDK javac only sets the bridge flag for methods with the same
name and compatible parameters, the JVM Specification and Java language Specification do
not actually specify any restrictions on how the flag is used, other than the comment that
is it set by the compiler when creating bridge methods. As such some other tools utilise
it in different ways, such as JBoss AOP setting in on the generated methods ending in
"$aop"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4643
days inactive
4643
days old
2 comments
1 participants
participants (1)
-
James Livingston (JIRA)