You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bval.apache.org by "Matt Benson (JIRA)" <ji...@apache.org> on 2016/10/20 21:22:58 UTC

[jira] [Commented] (BVAL-108) PrivilegedActions.getClassLoader(Class clazz) prefers thread context classloader over passed in type's classloader

    [ https://issues.apache.org/jira/browse/BVAL-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15593055#comment-15593055 ] 

Matt Benson commented on BVAL-108:
----------------------------------

The surrounding code has changed quite a bit since this was filed, but the issue likely still exists. What would be most helpful is a runnable example of a failure in an OSGI environment, if by chance the reporter is still tuned in.

> PrivilegedActions.getClassLoader(Class clazz) prefers thread context classloader over passed in type's classloader
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: BVAL-108
>                 URL: https://issues.apache.org/jira/browse/BVAL-108
>             Project: BVal
>          Issue Type: Bug
>            Reporter: Ryan Heinen
>         Attachments: BVAL-108.patch
>
>
> The getClassLoader(Class clazz) method in PrivilegedActions.java will prefer the thread context class loader over the class loader available from the passed in type.
> This is unexpected when looking at the method, and appears to be a bug. Similar to BVAL-89 this fails in an OSGi environment. AnnotationProxyBuilder.createAnnotation uses this method to load annotations from types to be validated, and should be using the classloader of the requested type, or it will be unable to find them.
> This means that BVAL-89 is still an issue. Although that fix changed the createAnnotation method so it calls PrivilegedActions.getClassLoader, the getClassLoader is still returning the wrong class loader.
> The attached patch reverses the order of class loader retrieval in that method. If it is unable to get the class loader from the provided type, it will fall back to the thread context class loader rather than the other way around.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)