Well, it was quite a few hours :( I think that the idea to simplify the API in the PR is good and definitely should be kept. Right now there is no actual use for ID in the interface and hence it should not be required. For me that field is mostly for observability and future troubleshooting purposes, and I think that some kind of extension IDs will be actually needed in WireMock itself once we have a new extension engine as proposed by @Tom. Extension ID, for better or worse, make declarative definitions easier when there is some kind of automatic discovery in place

So basically my proposal would be to keep the entry in the internal representation but not expose it in the public APIs for now. IDs could be always inferred from the JAR name and class name, for example

We can also make things better by having enum with known extensions so that we could simplify usage of extensions in Testcontainers. I think it would be all so good use case for IDs that we could eventually propagate to WireMock Core

@Nikita Karpuk so, I propose option 3 where we keep the current private Extension class which is indeed suboptimal for now but can be extended in the future. While this class right now offers a venue for collisions of jar names and extensions, this is something that could be verified easily if we want to strengthen this part of the code. My belief is that the risk of collisions won't be that high compared to class loading collisions due to bogus shading or lack of shading at all. But yes we can do some checks

I am ready to submit the extension catalog tomorrow and those refactor your pull request in my Branch to integrate changes if that's fine with you

.... So we can compare two proposals

And i like idea of extension catalog

... especially since we don't have so many extensions anyway

But yes it requires some investment which is probably too early right now.