HV-1017 javafx detection uses TCCL but JavaFXPropertyValueUnwrapper does not #429

DavideD · 2015-09-18T09:06:21Z

https://hibernate.atlassian.net/browse/HV-1017

I don't know how to test the issue, so I just check that the TCCL is not used when looking for the JavaFX classes. Let me know if it makes sense.

gunnarmorling · 2015-09-18T09:43:16Z

An alternative would be to load the unwrapper class via the same loader used for checking its presence, i.e. reflectively.

emmanuelbernard · 2015-09-18T12:58:02Z

@DavideD asks for the user feedback (to check that the bug is indeed fixed). Let's give it some time before applying.

DavideD · 2015-09-18T13:52:51Z

@emmanuelbernard Done:

emmanuelbernard · 2015-09-18T15:09:10Z

I know you did, it was more as a marker on the PR. Also I messed up my English tenses ;)

hferentschik · 2015-09-22T07:42:48Z

engine/src/main/java/org/hibernate/validator/internal/util/privilegedactions/LoadClass.java

@@ -36,13 +36,23 @@

 	private final ClassLoader classLoader;

+	/**
+	 * when true, it will check the Thread COntext ClassLoader when the class is not found in the provided one 


hferentschik · 2015-09-22T07:53:59Z

An alternative would be to load the unwrapper class via the same loader used for checking its presence, i.e. reflectively.

I think I like this idea

gunnarmorling · 2015-09-22T10:09:18Z

I think I like this idea

Ok :) I don't have a strong preference, it would help in some cases, but I suppose the scenario is very exotic. @DavideD?

DavideD · 2015-09-22T10:23:04Z

... I suppose the scenario is very exotic.

I don't know, this kind of errors seem to happen more often lately. In particular, when people start to use OSGI or JBoss Module on WildFly.

Anyway, I can try the classloader approach.

gunnarmorling · 2015-09-22T10:28:48Z

Ok, cool.

In particular, when people start to use OSGI or JBoss Module on WildFly.

But even then, why should JavaFX classes be visible trough the TCCL but not the system class loader? It seems like a misconfiguration of that environment (OSGi runtime with incomplete system package exports). Or possibly a very old JVM which does not bring JavaFX itself but the user adds it manually. Anyways, +1 for doing the alternative approach :)

hferentschik · 2015-09-22T10:53:30Z

But even then, why should JavaFX classes be visible trough the TCCL but not the system class loader?

I guess that's my question here as well. I am not an JAvaFX expert, but I was wondering whether it would be possible to add JavaFX classes to a JVM which otherwise does not provide them. Either way, using the reflection approach seems to be the safer option in this case, covering more potential scenarios.

gunnarmorling · 2015-09-22T10:57:07Z

whether it would be possible to add JavaFX classes to a JVM which
otherwise does not provide them

Yes, that would have been the case before JFX was added to the JDK (in 1.7
Update 6).

DavideD · 2015-09-23T14:33:42Z

@gunnarmorling
I've rebased with the change you suggested. although I'm not sure if the way I did it is the one you have suggested. Could you have a look?

hferentschik · 2015-09-23T15:08:39Z

engine/src/main/java/org/hibernate/validator/internal/engine/ConfigurationImpl.java

@@ -113,8 +112,10 @@ public ConfigurationImpl(ValidationProvider<?> provider) {
 	private ConfigurationImpl() {
 		this.validationBootstrapParameters = new ValidationBootstrapParameters();
 		TypeResolutionHelper typeResolutionHelper = new TypeResolutionHelper();
-		if ( isJavaFxInClasspath() ) {
-			validatedValueHandlers.add( new JavaFXPropertyValueUnwrapper( typeResolutionHelper ) );
+		ClassLoader classLoader = getClass().getClassLoader();


I don't think the intention was to change the isJavaFxInClasspath in classpath. In my world it would e kept as is. Then, if it returns true, use the LoadClass privileged action (which is used under the hood for isJavaFxInClasspath) to load JavaFXPropertyValueUnwrapper.

DavideD · 2015-09-23T15:44:59Z

@hferentschik Updated

hferentschik · 2015-09-24T08:37:44Z

engine/src/main/java/org/hibernate/validator/internal/engine/ConfigurationImpl.java

@@ -132,6 +133,16 @@ private ConfigurationImpl() {
 		this.addConstraintDefinitionContributor( defaultConstraintDefinitionContributor );
 	}

+	private ValidatedValueUnwrapper<?> createJavaFXUnwrapperClass(TypeResolutionHelper typeResolutionHelper) {


+1 Right, that's what I had in mind

hferentschik · 2015-09-24T08:43:03Z

I would suggest to merge this in this state and deploy a SNAPSHOT the user can test. If it still fails we can re-iterate on this.

hferentschik · 2015-09-24T08:51:09Z

Rebased and merged

gunnarmorling · 2015-09-24T09:03:40Z

engine/src/main/java/org/hibernate/validator/internal/engine/ConfigurationImpl.java

+	private ValidatedValueUnwrapper<?> createJavaFXUnwrapperClass(TypeResolutionHelper typeResolutionHelper) {
+		try {
+			Class<?> jfxUnwrapperClass = run( LoadClass.action( JFX_UNWRAPPER_CLASS, getClass().getClassLoader() ) );
+			return (ValidatedValueUnwrapper<?>) ( jfxUnwrapperClass.getConstructor( TypeResolutionHelper.class ).newInstance( typeResolutionHelper ) );


Just a quick thought: If JFX_UNWRAPPER_CLASS is loaded through the TCCL, will this actually find the right constructor, passing TypeResolutionHelper obtained through this's class loader?

org.hibernate.validator itself will never be loaded via the TCCL, since it is in the org.hibernate.validator namespace. This is handled in LoadClass.

hmm, so that might not work!? hard to test really

The current code might just behave like the old code. One would need

something like a ClassFoundIn which instead of a Class as in LoadClass returns a classloader (the one which successfully loaded the class or null)

this classloader should then be used to load the unwrapper, but it needs a modified version of LoadClass to prevent the special handling of the loading of validator classes

Given 1 + 2, there might then still be the question around the TypeResoltionHelper @gunnarmorling mentioned.

org.hibernate.validator itself will never be loaded via the TCCL

LoadClass#loadClassInValidatorNameSpace() falls back to the TCCL if a class cannot be loaded through its own loader. Now whether that makes sense...

Tbh. the original fix of only loading the JavaFX unwrapper when its visible to HV's loader seems like the best solution to me. Everything else seems very complex for a tiny potential gain.

I'm thinking the same, Let's use the original fix and hear back from the person with the issue, if he still has problem we will reopen the issue.

I'll send another pull request

I'll send another pull request

+1

DavideD force-pushed the HV-1017 branch from 4cdd74e to a5babff Compare September 18, 2015 09:40

hferentschik reviewed Sep 22, 2015
View reviewed changes

DavideD force-pushed the HV-1017 branch from a5babff to a76b4f4 Compare September 23, 2015 14:32

hferentschik reviewed Sep 23, 2015
View reviewed changes

HV-1017 Make sure JFX Unwrapper is loaded with the correct classloader

e97b8b9

DavideD force-pushed the HV-1017 branch from a76b4f4 to e97b8b9 Compare September 23, 2015 15:44

hferentschik reviewed Sep 24, 2015
View reviewed changes

hferentschik closed this Sep 24, 2015

gunnarmorling reviewed Sep 24, 2015
View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

HV-1017 javafx detection uses TCCL but JavaFXPropertyValueUnwrapper does not #429

HV-1017 javafx detection uses TCCL but JavaFXPropertyValueUnwrapper does not #429

DavideD commented Sep 18, 2015

gunnarmorling commented Sep 18, 2015 via email

emmanuelbernard commented Sep 18, 2015

DavideD commented Sep 18, 2015

emmanuelbernard commented Sep 18, 2015

hferentschik Sep 22, 2015

hferentschik commented Sep 22, 2015

gunnarmorling commented Sep 22, 2015

DavideD commented Sep 22, 2015

gunnarmorling commented Sep 22, 2015 via email

hferentschik commented Sep 22, 2015

gunnarmorling commented Sep 22, 2015

DavideD commented Sep 23, 2015

hferentschik Sep 23, 2015

DavideD commented Sep 23, 2015

hferentschik Sep 24, 2015

hferentschik commented Sep 24, 2015

hferentschik commented Sep 24, 2015

gunnarmorling Sep 24, 2015

hferentschik Sep 24, 2015

hferentschik Sep 24, 2015

hferentschik Sep 24, 2015

gunnarmorling Sep 24, 2015

DavideD Sep 24, 2015

hferentschik Sep 24, 2015

HV-1017 javafx detection uses TCCL but JavaFXPropertyValueUnwrapper does not #429

HV-1017 javafx detection uses TCCL but JavaFXPropertyValueUnwrapper does not #429

Conversation

DavideD commented Sep 18, 2015

gunnarmorling commented Sep 18, 2015 via email

emmanuelbernard commented Sep 18, 2015

DavideD commented Sep 18, 2015

emmanuelbernard commented Sep 18, 2015

Choose a reason for hiding this comment

hferentschik commented Sep 22, 2015

gunnarmorling commented Sep 22, 2015

DavideD commented Sep 22, 2015

gunnarmorling commented Sep 22, 2015 via email

hferentschik commented Sep 22, 2015

gunnarmorling commented Sep 22, 2015

DavideD commented Sep 23, 2015

Choose a reason for hiding this comment

DavideD commented Sep 23, 2015

Choose a reason for hiding this comment

hferentschik commented Sep 24, 2015

hferentschik commented Sep 24, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment