[jboss-jira] [JBoss JIRA] (JBMDR-76) AnnotatedElementMetaDataLoader.searchForRealBridgeMethodSignature should warn rather than fail if it can't find the original method

[James Livingston (JIRA)]

     [ https://issues.jboss.org/browse/JBMDR-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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