javafx detection uses TCCL but JavaFXPropertyValueUnwrapper does not
Description
Environment
caused by
Activity
![](https://secure.gravatar.com/avatar/0bfe87cfa0b6caa8d305312d19f24eeb?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FHV-4.png)
Henno Vermeulen September 29, 2015 at 8:31 AM
I downloaded the snapshot hibernate-validator-5.3.0-20150927.062356-67.jar and I can confirm it solves the issue.
![](https://secure.gravatar.com/avatar/0bfe87cfa0b6caa8d305312d19f24eeb?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FHV-4.png)
Henno Vermeulen September 24, 2015 at 2:40 PMEdited
(EDIT: made some mistakes due to lack of time)
![](https://secure.gravatar.com/avatar/12df4da7e3351be801bc16b66caf8038?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FHF-0.png)
Hardy Ferentschik September 24, 2015 at 11:45 AM
, we merged the initial pull request. Would it be possible for you to try with 5.3.0-SNAPSHOT as a dependency? You find the SNAPSHOT in the JBoss Nexus Repo - http://repository.jboss.org/nexus/content/groups/public-jboss/org/hibernate/hibernate-validator/5.3.0-SNAPSHOT/
![](https://secure.gravatar.com/avatar/6db67528c0dfb637ac5d957a22643392?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FGM-1.png)
Gunnar Morling September 22, 2015 at 10:02 AM
Yes, right. It's included in JDK 8 and also in 7 for quite a while. We can do the reflective loading suggested in the PR, that may improve odds in a small number of cases.
![](https://secure.gravatar.com/avatar/12df4da7e3351be801bc16b66caf8038?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FHF-0.png)
Hardy Ferentschik September 22, 2015 at 7:54 AM
Yes, I suppose we should not fall back to the TCCL when detecting whether JavaFX is available or not, it's really the classloader of HV's classes which must be able to access the JavaFX types.
How so? Because you assume that the JacaFX classes are always part of the system classes?
Assignee
Reporter
![](https://secure.gravatar.com/avatar/0bfe87cfa0b6caa8d305312d19f24eeb?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FHV-4.png)
Bug Testcase Reminder (view)
Bug reports should generally be accompanied by a test case!
Bug Testcase Reminder (edit)
Bug reports should generally be accompanied by a test case!
Participants
![](https://secure.gravatar.com/avatar/6db67528c0dfb637ac5d957a22643392?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FGM-1.png)
![](https://secure.gravatar.com/avatar/12df4da7e3351be801bc16b66caf8038?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FHF-0.png)
![](https://secure.gravatar.com/avatar/0bfe87cfa0b6caa8d305312d19f24eeb?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FHV-4.png)
When bootstrapping Hibernate Validator, ConfigurationImpl's constructor is called which contains:
The classloading mechanism used to implement method
isJavaFxInClasspath()
is inconsistent with that used inJavaFXPropertyValueUnwrapper
constructor.isJavaFxInClasspath
uses theLoadClass
util to check if the classjavafx.application.Application
exists. When this util fails to load the class throughClass.forName
it falls back to the ThreadContext ClassLoader.JavaFXPropertyValueUnwrapper
is a generic class parameterized withjavafx.beans.value.ObservableValue
. Its superclass constructor inTypeResolverBasedValueUnwrapper
indirectly tries to load theObservableValue
class when resolving it's subclass type through classmate'sTypeResolver
. However, this does NOT fallback to the context class loader.I have an Eclipse-based OSGi application that worked fine with Hibernate Validator 5.0.2.Final but fails bootstrapping Hibernate Validator with 5.2.1.Final due to this. I am not using javafx which means that the normal classloader cannot load javafx classes. Somehow the TCCL that Eclipse uses can load them leading to
A workaround for me is to temporarily set the TCCL to null or to the normal classloader.
Expected behavior would be for Hibernate Validator to should either successfully create the
JavaFXPropertyValueUnwrapper
or skip it, but not throw an exception when the TCCL differs from the normal classloader.The exception I get: