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