[
http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11?page=c...
]
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira