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
