Can we override an extension's @BuildStep method in our custom extension in Quarkus ?

[nitinty]

Hi Team,

Can we override a @buildstep method from an extension within our custom Quarkus extension? If so, what is the best approach to do this, and is it advisable ?

[nitinty]

@geoand plz assist.

[geoand]

You cannot.

What exactly are you trying to achieve?

[nitinty]

I was reviewing the MongoClientProcessor, where the MongoDB client name is fetched based on the MongoClientName annotation. After retrieving the client names, they are used in the generateClientBeans() method to create Mongo clients.

We aim to make this configuration-based, allowing us to define all tenants in the configuration file. This way, the Mongo client can be created for specific tenants, and by modifying the BeanUtils, it would automatically switch between Mongo clients based on the tenantId. (So that we could achieve multi-tenancy based on X-TENANT-ID receiving in request header)

    @BuildStep
    public void mongoClientNames(CombinedIndexBuildItem indexBuildItem,
            BuildProducer<MongoClientNameBuildItem> mongoClientName) {

        Set<String> values = new HashSet<>();
        IndexView indexView = indexBuildItem.getIndex();
        addMongoClientNameValues(MONGO_CLIENT_ANNOTATION, indexView, values);
        for (String value : values) {
            mongoClientName.produce(new MongoClientNameBuildItem(value));
        }
    }

Want to update it something like

    @BuildStep
    public void mongoClientNames(CombinedIndexBuildItem indexBuildItem,
            BuildProducer<MongoClientNameBuildItem> mongoClientName) {

        Set<String> values = new HashSet<>();
        //IndexView indexView = indexBuildItem.getIndex();
        //addMongoClientNameValues(MONGO_CLIENT_ANNOTATION, indexView, values);
        Optional<List<String>> optionalList = ConfigProvider.getConfig().getOptionalValues("quarkus.mongodb.supportedTenant",String.class);
        if(optionalList.isPresent() && !optionalList.get().isEmpty()){
            optionalList.get().forEach(supportedTenant -> values.add(supportedTenant));
        }

        for (String value : values) {
            mongoClientName.produce(new MongoClientNameBuildItem(value));
        }
    }

[geoand]

Thanks for writing this up. Currently there is no built-in way to handle this, so we would need one of following options:

• Have special build items for Mongo that would allow extensions to essentially override the default behavior
• Introduce a way to "turn off" specific build steps (this is where input for @dmlloyd would be nice)

[dmlloyd]

I think it's better for the build steps to introduce extensibility points and otherwise respect the principle of encapsulation. If we allow anyone to tinker with build steps in an arbitrary way, we open the door to all kinds of problems for the user.

[nitinty]

@geoand @dmlloyd

Is there any plan in the near future to consider the second point that @geoand mentioned or to introduce extensibility ? Currently, the framework feels limiting in terms of allowing modifications.

[geoand]

To be honest, I don't think point no.2 will be implemented in the immediate future.

Point no.1 is more likely for whatever cases make sense

[nitinty]

Thank you for your reply. It would be great if the second option is implemented, as it would simplify development for those looking to override or enhance specific functionality, making the framework more flexible.

Currently, it’s a bit complex to override certain functionalities.

[nitinty]

@geoand
One more thing—I'd appreciate your input on this. Currently, to override the behavior of a particular class, we are creating a custom extension and placing the Quarkus extension's specific class in the same package path, then modifying the required behavior.

Is this the correct approach, or is there a better method we should consider ?

[geoand]

What kind of class are we talking about?

[nitinty]

Considering the MongoClientProcessor class, It is possible to override the mongoClientNames() method by placing the class in the same package path within our custom extension as it exists in the MongoDB extension, and then modifying the code of that specific method.

[geoand]

I wouldn't say it's correct (as there is no correct way to do it), but if it works in all circumstances, you can probably live with it :)

[nitinty]

Until the mentioned second option is implemented :)