How to use an extension libraries' classes only and with our own custom service extension.

[hemantxpatel]

An extension in connector contains a service implementation and a service extension which registers the service implementation.

Let's take an example of this extension jetty-core.
It has JettyService class and a JettyExtension which instantiates and registers this JettyService.

    jettyService = new JettyService(jettyConfiguration, ks, monitor, portMappings);
    context.registerService(JettyService.class, jettyService);

Now assume, I want to use this extension in tractusx-edc, but I want to instantiate JettyService in a different way (e.g I want to pass a customJettyConfiguration).
For that, I can include jetty-core extension and write a custom CustomJettyExtension which instantiates the same JettyService class in a different way and registers it.
Now JettyService will be registered twice and and second registration will override the first registration. Now it all depends on the order in which extensions are loaded.

So now I have two questions

1. How can I make a deterministic order of extensions so that I can ensure CustomJettyExtension is loaded always after JettyExtension.
2. How can I use jetty-core extension in tractusx-edc so that I could use JettyService class but JettyExtension should not be loaded. Any way to disable it or remove it completely from the extension loader flow.

[wolf4ood]

Hi @hemantxpatel

there is no way to achieve that. Usually *-core modules contains extensions with default behaviour and if you include those you will also get the services injected. For reusable stuff across extensions we create modules with *-lib convention and they only exposes classes without extensions. In this case to achieve that a refactor is needed in order to extract the required classes into a jetty-lib module.

[hemantxpatel]

Thanks @wolf4ood for quick answer, that sounds good.
So, only way to achieve this is to copy the JettyService class in tractusx-edc, create a new CusotmJettyExtension and don't include this jetty-core extension as lib in tractusx-edc at all.
Do you think probably as a new feature request, we could provide a set of exclusion list of extension classes as configuration which we don't want to get loaded And ExtensionLoader can use this configuration to filter them.

[paullatzelsperger]

just to add an answer to the 2nd question: there is no explicit way to achieve deterministic ordering. the best way would be to inject a service from the extension that should be initialized first.

Personally, I am against such exclusion list "features" because it will a) only serve a very small user base, b) complicate extension loading (and its testing!) further and c) goes a bit against the principles of such core extensions.

We could possibly look at refactoring this into a *-core and *-lib extension like @wolf4ood said, but even then, I'm doubtful. If you want jetty, use jetty, or write your own.

[jimmarino]

I also agree with this. Extension ordering is a sign that something is not correct in the design. For example, hidden coupling between services.

Also, extension exclusion is already supported by the Java service loader - don't include those classes on the classpath.

[hemantxpatel]

Thanks @paullatzelsperger, that little hack might be helpful.

And just to clarify, I provided just an example of jetty-core extension but this is applicable for almost all extensions. And probably people who are building their own connectors might encounter such issue a lot.

[jimmarino]

Please see my comment above on why the need for ordering and exclusions are a sign of a design problem.

[paullatzelsperger]

for situations where you want e.g. all elements of a registry to be populated, you can always use the start() method to do whatever it is you are doing.