[
http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11?page=c...
]
Hardy Ferentschik commented on BVTCK-11:
----------------------------------------
I am wondering whether adding the new SPI contract is really necessary. The problem is
really that only the context class loader is checked:
{code}
ClassLoader classloader = Thread.currentThread().getContextClassLoader();
if ( classloader == null ) {
classloader = ValidationProviderResolverTest.class.getClassLoader();
}
{code}
wouldn't it be enough if both the context and application class loader would be
checked?
{code}
private List<Class<?>> readBeanValidationServiceFile() {
List<Class<?>> providers = new ArrayList<Class<?>>();
// first check application classpath
ClassLoader classloader = ValidationProviderResolverTest.class.getClassLoader();
providers.addAll( getProviderListFromClassLoader( classloader ));
// then the context classpath
classloader = Thread.currentThread().getContextClassLoader();
if ( classloader != null ) {
providers.addAll( getProviderListFromClassLoader( classloader ) );
}
return providers;
}
private List<Class<?>> getProviderListFromClassLoader(ClassLoader classloader)
{
List<Class<?>> providers = new ArrayList<Class<?>>();
try {
Enumeration<URL> providerDefinitions = classloader.getResources( SERVICES_FILE );
while ( providerDefinitions.hasMoreElements() ) {
URL url = providerDefinitions.nextElement();
addProviderToList( providers, url );
}
}
catch ( Exception e ) {
throw new RuntimeException( "Unable to load service file", e );
}
return providers;
}
{code}
In case the new SPI interface gets introduced I still would have to load the specified
implementation of {{ValidatorClassLoaderProvider}} (or whatever we would call this class)
and which classloader do I use for that?
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