[
http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11?page=c...
]
Jarek Gawor commented on BVTCK-11:
----------------------------------
The service file might be a public API but that does not mean that the application should
be able to see it or load the provider implementation directly (at least not in the case
where the application wants to use the default provider). The application uses the
Validation API to obtain the default provider. It is responsibility of the Validation API
to discover and return the provider. So the Validation API should be able to see the
service files but the application should not have to.
I think it would be wrong for the specification to require or imply that the default
provider must be loadable from the application classloader. And if the specification does
not require it, the TCK should not be testing for it.
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....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira