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

[Emmanuel Bernard (JIRA)]

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

Emmanuel Bernard commented on HV-363:
-------------------------------------

Hi Sahoo,
Realize that your request comes out of the blue, with no unit test nor any clue on how to reproduce the issue and goes against all the experience and feedback gathered over the last 9 years of Hibernate existence.
Using Class.forName has been an anti-pattern for a decade or so in containers and using Thread context CL (and falling back to Class.forName as last resort) has been constantly used in the various library projects with success. And we make sure that all of our classes are loaded that way (unless specific classloaders are passed to us as JPA does for example).

We are open to customizing the class loading mechanism (though that would become a bit of a chicken and egg issue: how do we load the new class loading implementation) but understanding and reproducing the issue is the first step before changing such sensitive piece of code.

> 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