[
http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11?page=c...
]
Emmanuel Bernard commented on BVTCK-11:
---------------------------------------
That poses problem then because what they do goes against the spirit of the 303 spec.
The service file is a public API so are the ValidationProvider implementation and the
Configuration subinterface. They are used to select a specific provider as well as use
optional provider specific configurations.
I think the restricted classloader should leave these visible even in the case of the
container implementation.
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