[ http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11?page=c... ] Hardy Ferentschik commented on BVTCK-11: ---------------------------------------- A possible solution discussed on the hibernate-dev irc could be to provide another Bean Validation TCK SPI. The SPI would have a method like {{getValidatorClassLoader}} which would return the class loader used to load the Validator implementation. The test would then use the this provided class loader to assert the existence of the file {{javax.validation.spi.ValidationProvider}}. It still needs to be investigated if this actually works. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11?page=c... ] Hardy Ferentschik updated BVTCK-11: ----------------------------------- Remaining Estimate: 8h Original Estimate: 8h Adding the new SPI interface, updating the Hibernate Validator test runner and the documentation -- 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

[ 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? -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11?page=c... ] Hardy Ferentschik commented on BVTCK-11: ---------------------------------------- Adding response on behalf of challenger: {quote} Checking the application classloader might help in some cases but it does not address the problem in our case. The tck deploys a war file that only contains the tests classes - the war file does not contain any validation provider implementation classes. So the tck tests will use the validation provider provided by the application server. In our case, the context classloader is the same as the application classloader but the classloader is constrained. For example, the classloader allows loading javax.validation.* classes but does not allow loading any container-specific or validation provider specific classes or resources. So the application (the tck test) can use the javax.validation api and do its work but it cannot directly see/load the actual validation provider implementation classes. There are a few spots in the TCK where the TCK expects to load the validation provider class directly using the application classloader ({{TestUtil.instantiateValidationProviderUnderTest()}}). That only works if the application classloader is unconstrained or if the application itself contains the validation provider implementation. {quote} -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11?page=c... ] Hardy Ferentschik commented on BVTCK-11: ---------------------------------------- If the classloader is constrained as described checking both (context and application) classloaders will not work. What's about the SPI approach though? In this case the class implementing the SPI interface would be part of the war file and could be loaded via the application classloader. It is then a question of returning a unconstrained classloader for the BV implementation. Could we get some feedback on the SPI approach and/or other suggestions? -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11?page=c... ] Hardy Ferentschik updated BVTCK-11: ----------------------------------- Fix Version/s: 1.0.5.GA -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11?page=c... ] Emmanuel Bernard commented on BVTCK-11: --------------------------------------- Note that the class implementing ValidationProvider must be visible to the application as an app can do {code}Validation.byProvider(XXXValidationProvider.class).configure().buildValidatorFactory(){code} -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/BVTCK-11?page=c... ] Hardy Ferentschik updated BVTCK-11: ----------------------------------- Fix Version/s: (was: 1.0.5.GA) 1.1.0 Moving this issue into the next release. -- 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