GrpcDevUIProcessor#grpcAction() is problematic from a CL point of view

[gsmet]

Note

This is part of my class loader work and is going to be very problematic soon.

GrpcDevUIProcessor#grpcAction() which is a deployment bit is called from the Dev UI at runtime and actually performs some class loading from the deployment class loader, which is closed at that point (so we shouldn't load classes from it anymore).

I think the problem was somehow identified because of this comment:

 /**
  * This gets called during runtime from the Dev UI JsonRPC Service to test a grpc call
  * We go to Flow to stay in the JDK, else we have classpath issues.
  */

I'm not entirely sure how we want to fix it but I would really like us to get rid of this pattern (if we can find a better solution).

Also I'm not entirely sure it's the only problematic piece of the Dev UI (I'm pushing something to CI to try to detect these problems but it might break too many things to be meaningful). @phillip-kruger do you recall some other similar hacks?

/cc @cescoffier

[quarkus-bot]

/cc @alesj (grpc), @cescoffier (devui,grpc), @phillip-kruger (devui)

[phillip-kruger]

I am not sure, @cescoffier do you have any ideas ? What we can try is to "bypass" the issue and do the grpc test from Javascript maybe ?

[cescoffier]

Hum, I'm not sure we can find a proper way. The Dev UI has to access deployment classes once in a while. That's why we have the DevConsoleManager "hacks".

Here, we cannot invoke gRPC from Javascript (even with gRPC Web it will only be a subset).

[gsmet]

The Dev UI has to access deployment classes once in a while.

I'm not sure our test coverage of the Dev UI is enough but it's the only issue related to it I have when running the tests.

What I'm not sure I understand is why we would need to do some deployment work here? I would expect us to be able to handle gRPC calls at runtime?

And in the case of the Dev UI, I think we added some runtime components to handle the Dev UI requests.