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

[Emmanuel Bernard (JIRA)]

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

Emmanuel Bernard commented on BVTCK-11:
---------------------------------------

Here is the formal answer pushed.

Yes the spec has explicitly been made vague enough to support weirdo environments like OSGi.
Yes the test as it is written makes use of the context classloader which is not mandated to work by the (spec) book.
No the solution they propose does not work because this would test something else. We are explicitly trying to make sure the BV provider has defined a META-INF/services/javax.validation.spi.ValidationProvider with a valid implementation name in there.

What we propose is the following change to the test and TCK:
 - provide a TCK SPI that can optionally be implemented by the container and whose class name is passed as a property to the TCK when run
 - this SPI would have a no-arg constructor and implement one method getClassPathClassLoader() It should return a classloader whose visibility allow access to the META-INF/services/javax.validation.spi.ValidationProvider
 - the test at fault would use this SPI and use the provided classloader to verify the presence of the file

The alternative is to make the assertion as non-testable in an in-container environment.

> 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
>
> *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