[ http://opensource.atlassian.com/projects/hibernate/browse/HV-363?page=com... ] Hardy Ferentschik updated HV-363: --------------------------------- Description: {{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} was: 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: 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 ); } } -- 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/HV-363?page=com... ] 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...] 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? -- 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/HV-363?page=com... ] Hardy Ferentschik commented on HV-363: -------------------------------------- One reason for using the method is to be able to wrap the class loading into a {{PrivilegedAction}}. {quote} If you are not convinced by my argument, keep doing what you are doing until someone else faces the issue. {quote} You still haven't explained _the issue_. Even if a {{Class.forName()}} would be enough, what is the issue with the current approach? {quote} Looking at the code, I don't think I have to even give a test case {quote} Why not, if you can provide a valid test case you made your point. -- 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/HV-363?page=com... ] 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. -- 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/HV-363?page=com... ] Hardy Ferentschik reopened HV-363: ---------------------------------- Even though we are not strictly violating the spec, we will address this issue with 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HV-363?page=com... ] Steve Ebersole commented on HV-363: ----------------------------------- Its not always that cut-n-dried though Sanjeeb in the general case. Often Hibernate needs to load an implementation of a given contract interface. Now that implementation class might be part of Hibernate itself or t might be provided by the user. We don't know and silly regex package name hacks aside we really cannot know. So what do we do in that case? -- 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/HV-363?page=com... ] Hardy Ferentschik resolved HV-363. ---------------------------------- Resolution: Fixed -- 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