[External] : Re: Inconsistency with service loading by layer or by class loader

[Jochen Theodorou]

On 18.12.24 16:46, Ron Pressler wrote:
[...]
> The scenario you’ve described is one that effectively disables reliable configuration. That is what everything you’ve brought up is predicated on. I don’t doubt you have your reasons for not wanting reliable configuration, but that only raises the question, why do you want to use the reliable configuration feature only to disable reliable configuration?

reliable configuration in the sense of the module system is not his
target. Wildfly had a module system since before Java had one. And "he"
is trying to emulate the old module system with the new Java system. One
reason to keep the old system surely is inertia. If this is a good idea
or not I don't know.

Clearly the goals in Wildfly modules are different compared to the goals
in Java modules. For Java you want a compile time known configuration of
modules that will not change. Severely limiting dynamic linking. And a
more static linking has advantages for native compilation, and maybe a
more stable configuration. This works... uhm.. let's say "ok" for
application (surely good for the very big majority). But Wildfly is not
a normal application, it is a application platform running x
applications. And those applications are linked in dynamic. Static would
require to restart the complete Wildfly, possibly impacting other
running applications. Of course we are then not speaking of a micro
service architecture.

And you cannot only deploy applications to Wildfly, you can also deploy
services to support applications. And they can be anything from logging
to a new channel service. This is currently done up to the point, that
part of Wildfly itself consists of such services. And of course you can
have services depending on services.

Of course you want some kind of stronger encapsulation to protect
service internals from other applications and to protect applications
from each other. You may want to be able to hide dependencies from each
other, so they do not conflict.

And maybe one application requires the jakarta namespace in
dependencies, another application maybe not.

Then you will also want some kind of meta description for the
applications and services, declaring their requirements for dependencies
and potential conflicts and so on.

Obviously this is not done with just shoving everything into a single
class loader.

The approach chosen is to have a module (or multiple) for each
application and service, have each loaded in their own layer as per
earlier recommendations. And now (after years of work) everything works
as intended bye the Wildfly system, except Service loaders. They behave
here different from what users expect or "how things used to work".

Of course this is a simplified and potentially slightly wrong picture
about Wildfly. Still I dare to ask: What is now the right architecture
in a modern Java?

bye Jochen