[hibernate-issues] [Hibernate-JIRA] Commented: (BVTCK-11) Wrong usage of context classloader to discover resources in META-INF/services

Hardy Ferentschik (JIRA) noreply at atlassian.com
Thu Sep 30 12:14:57 EDT 2010


    [ http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=38568#action_38568 ] 

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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the hibernate-issues mailing list