[hibernate-issues] [Hibernate-JIRA] Commented: (HV-363) HV uses Thread's context class loader to load internal implementation classes

[Hardy Ferentschik (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HV-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=38349#action_38349 ] 

Hardy Ferentschik commented on HV-363:
--------------------------------------

AFAICS {{DefaultTraversableResolver}} calls the method {{ReflectionHelper.loadClass}}, at least in the latest version of Hibernate Validator. {{ReflectionHelper}} in turn uses [LoadClass|https://fisheye2.atlassian.com/browse/Hibernate/validator/trunk/hibernate-validator/src/main/java/org/hibernate/validator/util/privilegedactions/LoadClass.java?r=HEAD] to load the class. {{LoadClass}} will indeed use the context class loader, but will fall back to the current class loader if the class cannot be loaded from the context class loader. I think the code was always been working like this and first checking the context class loader has been a successful strategy. The context class loader is especially relevant in situations where the application is deployed in some sort of container. Often containers use the context class loader mechanism to implement their own class loading strategies.

What is your problem anyway? Do you have a concrete problem where the current approach fails?

> HV uses Thread's context class loader to load internal implementation classes
> -----------------------------------------------------------------------------
>
>                 Key: HV-363
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-363
>             Project: Hibernate Validator
>          Issue Type: Bug
>          Components: engine
>            Reporter: Sanjeeb Sahoo
>            Assignee: Hardy Ferentschik
>            Priority: Blocker
>
> {{org.hibernate.validator.engine.resolver.DefaultTraversableResolver}} uses Thread's context class loader to load {{JPA_AWARE_TRAVERSABLE_RESOLVER_CLASS_NAME}}, which is {{org.hibernate.validator.engine.resolver.JPATraversableResolver}}. Why? Since one implementation class is looking for another implementation class, should it not use {{getClass().getClassLoader()}} instead? The relevant code is given below:
> {code}
> 	private void detectJPA() {
> 		try {
> 			loadClass( PERSISTENCE_UTIL_CLASS_NAME, this.getClass() );
> 			log.debug( "Found {} on classpath.", PERSISTENCE_UTIL_CLASS_NAME );
> 		}
> 		catch ( ValidationException e ) {
> 			log.debug(
> 					"Cannot find {} on classpath. All properties will per default be traversable.",
> 					PERSISTENCE_UTIL_CLASS_NAME
> 			);
> 			return;
> 		}
> 		try {
> 			@SuppressWarnings( "unchecked" )
> 			Class<? extends TraversableResolver> jpaAwareResolverClass = (Class<? extends TraversableResolver>)
> 					loadClass(JPA_AWARE_TRAVERSABLE_RESOLVER_CLASS_NAME, this.getClass() );
> 			NewInstance<? extends TraversableResolver> newInstance = NewInstance.action( jpaAwareResolverClass, "" );
> 			if ( System.getSecurityManager() != null ) {
> 				jpaTraversableResolver = AccessController.doPrivileged( newInstance );
> 			}
> 			else {
> 				jpaTraversableResolver = newInstance.run();
> 			}
> 			log.info(
> 					"Instantiated an instance of {}.", JPA_AWARE_TRAVERSABLE_RESOLVER_CLASS_NAME
> 			);
> 		}
> 		catch ( ValidationException e ) {
> 			log.info(
> 					"Unable to load or instanciate JPA aware resolver {}. All properties will per default be traversable.",
> 					JPA_AWARE_TRAVERSABLE_RESOLVER_CLASS_NAME
> 			);
> 		}
> 	}
> {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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira