HHH-17579 fix classloader issues with JAXBContext since JDK11

[laurentschoelens]

Fixes https://hibernate.atlassian.net/browse/HHH-17579

Tested OK against the https://github.com/laurentschoelens/hibernate-orm-xml-java11 repository

[laurentschoelens]

Hi @beikov, Could you please check this PR associated with the following issue : https://hibernate.atlassian.net/browse/HHH-17579 ? Thanks 😄

[laurentschoelens]

@gavinking : sorry to point out this PR but this is waiting for long without any notice if I'm doing something wrong about this one and you were working some days ago on modified file.

Just rebased from main to get latest modifications 😄

Thanks for the help and review of this blocking issue

[gavinking]

I mean, the pull request has no test.

[laurentschoelens]

I mean, the pull request has no test.

Thanks for the reply. I've tested it against this repository by building and testing against latest build. Since it's designed to be run inside build env, I don't know pretty much how to add unit tests to it. If possible, could you guide me please so I can add it ?

[gavinking]

The tests for jpamodelgen are in: tooling/metamodel-generator/src/test. There's lots of examples, some of which use orm.xml mappings.

[laurentschoelens]

@gavinking : I've just tried to add a unit test and it's passing in both scenario. But by building main current branch and re-running the sample above, I still get the following output

[INFO] --- compiler:3.11.0:compile (default-compile) @ hibernate-orm-xml-java11 ---
[INFO] Changes detected - recompiling the module! :source
[INFO] Compiling 2 source files with javac [debug target 11] to target/classes
[INFO] Hibernate compile-time tooling 6.5.0-SNAPSHOT
[WARNING] Unable to parse /META-INF/shared/orm.xml: Unable to perform unmarshalling at line number 0 and column 0. Message: null
[WARNING] The following options were not recognized by any processor: '[ormXml]'

and the target/generated-sources/annotations directory is empty

If again I build my patched branch (with this PR), I get the following output and result is OK :

[INFO] --- compiler:3.11.0:compile (default-compile) @ hibernate-orm-xml-java11 ---
[INFO] Changes detected - recompiling the module! :source
[INFO] Compiling 2 source files with javac [debug target 11] to target/classes
[INFO] Hibernate compile-time tooling 6.5.0-SNAPSHOT
[WARNING] The following options were not recognized by any processor: '[ormXml]'

With BaseEntity_ file content as follow :

@StaticMetamodel(BaseEntity.class)
@Generated("org.hibernate.processor.HibernateProcessor")
public abstract class BaseEntity_ {

	public static volatile SingularAttribute<BaseEntity, String> lastModifiedBy;
	public static volatile SingularAttribute<BaseEntity, String> createdBy;

	public static final String LAST_MODIFIED_BY = "lastModifiedBy";
	public static final String CREATED_BY = "createdBy";

}

[laurentschoelens]

Just forced-pushed with extra unit test (but not representative of the current issue in fact since not run with same condition as actual issue)

@gavinking : the initial issue is here https://hibernate.atlassian.net/browse/HHH-12991 With good analysis of the problem and which leads me to this PR Again, thank you for your time and help 😄

[gavinking]

The following options were not recognized by any processor: '[ormXml]'

This is extremely 'sus, since HibernateProcessor certainly specifies that ormXml in @SupportedOptions.

[laurentschoelens]

The following options were not recognized by any processor: '[ormXml]'

This is extremely 'sus, since HibernateProcessor certainly specifies that ormXml in @SupportedOptions.

Yes I've never understood this warning message but it works with patched version so I've never dug more on this 😄

[gavinking]

OK, that now looks a lot more reasonable.

One more question: is the new test actually testing anything new, or is it just a dupe of tests we already have?

[laurentschoelens]

OK, that now looks a lot more reasonable.

One more question: is the new test actually testing anything new, or is it just a dupe of tests we already have?

As I said, it's passing before and after the PR (since it's not executed in the same context). That's why I didn't brought any test in the first place.

I can delete it if you think it's useless 😄 (which it is in my opinion)

[gavinking]

I can delete it if you think it's useless 😄 (which it is in my opinion)

Well, yeah, if it's not demonstrating the bug.

[laurentschoelens]

I can delete it if you think it's useless 😄 (which it is in my opinion)

Well, yeah, if it's not demonstrating the bug.

Done 😉

[laurentschoelens]

@beikov and @gavinking could you re-review please ?

[beikov]

Thanks

[laurentschoelens]

Many thanks to both of you 👍 Did this could have any chance to be backported in latest 5.x ? Users are locked on jdk8 due do this...

[beikov]

Sorry, but we only backport critical bug fixes at this point. Read more about this on the 5.6 release page or the maintenance policy page.

[laurentschoelens]

I trully understand your answer, keeping old version could be quite painful and this may be considered not critical enough for core-team but it is if using this feature and wanting to keep on javax version of hibernate but go on JDK11 or JDK17. Maybe it could have been backported to be included in the next critical-fix-release ?

[beikov]

If you are a Red Hat customer, then you can request a backport through support channels. The maintenance policy is quite clear, so if you want to stick to community releases, you will have to upgrade to the latest versions.