How QuarkusTestExtension does it

[ledoyen]

Hi,

Following #3028 comment of @geoand, I have questions to narrow down the needs of Quarkus regarding a ClassLoader extension point in JUnit-Jupiter.

• What is the structure of classloaders in Quarkus ? From my tests, I see:

flowchart LR
  classDef jvm fill:#f96,color:#000;
  id1(Boot ClassLoader):::jvm
  id2(Platform ClassLoader):::jvm
  id3(App ClassLoader):::jvm
  id4(Quarkus Base Runtime\nClassLoader)
  id5(Quarkus Runtime\nClassLoader\n)
  id2 --> id1
  id3 --> id2
  id4 --> id3
  id5 --> id4

Loading

So it seems that an API such as:

interface ClassLoaderModifier {
    ClassLoader modify(ClassLoader current);
}

should be sufficient.

However

• I do not see the role of the xtream deep copy that is in place though, I may be missing something
• JUnit internals load classes from the AppClassLoader and they are subject to being injected to the testInstance (such as TestInfo). I am puzzled about the fact that it works today, as the testInstance class is loaded by the Quarkus Runtime ClassLoader and that this class should load the TestInfo class from the Quarkus Base Runtime ClassLoader but don't.

So I guess, my question is, what guaranties will need the QuarkusTestExtension from such an API ?

cc @geoand, @marcphilipp

[geoand]

Hi @ledoyen

Your diagram is indeed correct!

I do not see the role of the xtream deep copy that is in place though, I may be missing something

This is basically a hack to allow for the use test method parameters because otherwise you would get ClassCastExceptions.

[marcphilipp]

So I guess, my question is, what guaranties will need the QuarkusTestExtension from such an API ?

Would it be enough for Quarkus if such an extension would be called once for each test class it's registered on? We could even allow configuring a default via a configuration parameter so it would be called for every test class.

Does Quarkus need any kind of lifecycle management for its class loader? For example, does it have to be closed at a certain point like an URLClassLoader?

[geoand]

If the API provided a point at which to decide the ClassLoader to be used for each test class, that would be enough - provided of course that this ClassLoader is used for all of the test classes needs.

As for the lifecycle of the ClassLoader, we currently manage it ourselves and will likely continue doing so because we wan't create before the tests are run and tear it down when all tests have completed.