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

[Hardy Ferentschik (JIRA)]

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

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

We cannot use the ValidationProviderResolver API for this assertion.
According to _tck-audit.xml_ 4.4.4.1 c this test tries to assert:
{quote} 
Bean Validation providers must supply a
service provider configuration file by creating a text file javax.validation.spi.ValidationProvider and placing
it in the META-INF/services directory of one of its jar files.
{quote} 
This cannot be asserted using the ValidationProviderResolver API.
 
Whether the use of the context class loader is acceptable is debatable. The spec also says:
{quote} 
The default ValidationProviderResolver implementation will locate all the Bean Validation providers by their
provider configuration files visible in the classpath. The default ValidationProviderResolver implementation is
recommended and custom ValidationProviderResolver implementations should be rarely used. A typical use of
a custom resolution is resolving providers in a classloader constrained container like OSGi or in a tool environment
{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
>
> *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