[hibernate-issues] [Hibernate-JIRA] Commented: (BVTCK-11) Wrong usage of context classloader to discover resources in META-INF/services

Hardy Ferentschik (JIRA) noreply at atlassian.com
Tue Oct 12 04:06:00 EDT 2010


    [ http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=38700#action_38700 ] 

Hardy Ferentschik commented on BVTCK-11:
----------------------------------------

Adding response on behalf of challenger:

{quote}
Checking the application classloader might help in some cases but it does not address the problem in our case.
The tck deploys a war file that only contains the tests classes - the war file does not contain any validation provider implementation classes. So the tck tests will use the validation provider provided by the application server. In our case, the context classloader is the same as the application classloader but the classloader is constrained. For example, the classloader allows loading javax.validation.* classes but does not allow loading any container-specific or validation provider specific classes or resources. So the application (the tck test) can use the javax.validation api and do its work but it cannot directly see/load the actual validation provider implementation classes.
There are a few spots in the TCK where the TCK expects to load the validation provider class directly using the application classloader ({{TestUtil.instantiateValidationProviderUnderTest()}}). That only works if the application classloader is unconstrained or if the application itself contains the validation provider implementation.
{quote}

> Wrong usage of context classloader to discover resources in META-INF/services
> -----------------------------------------------------------------------------
>
>                 Key: BVTCK-11
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11
>             Project: Bean Validation TCK
>          Issue Type: Bug
>          Components: TCK Appeal
>    Affects Versions: 1.0.4.GA
>            Reporter: Hardy Ferentschik
>            Assignee: Emmanuel Bernard
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> *Problem Description*:
> The test uses the context classloader to discover all META-INF/services/javax.validation.spi.ValidationProvider resources and checks whether one of the resource files contains the ValidationProvider currently under the test.
> This method of checking for ValidationProvider might not work on all containers. Especially on containers with constrained classloaders (e.g. OSGi). The Bean Validation specification in section 4.4.4.1 talks about this exact problem. That's why the test should be using ValidationProviderResolver API to check for right provider instead of looking for the resource files.
> *Tests affected*: 
> org.hibernate.jsr303.tck.tests.bootstrap.ValidationProviderResolverTest#testServiceFileExists()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the hibernate-issues mailing list