Dynamically load class mapping using configuration on morpha 2.4.0+?

[Azn9]

I've seen that starting with 2.4.0, the configuration and mappings should be done via a configuration file.

Due to the structure of my project, I can't have a static configuration for mappings, as the load of Morphia is done by a separate library that provides "wrapper" methods to the other parts of my application. The issue is that the part that does the loading does not know which classes will be used, so I can't even generate the config file at the app's start.

Will there still be a way to register mapped classes at runtime or add new configurations to the already loaded ones?

[evanchooly]

Can you describe it a bit more? you don't need to know the classes. Just the packages so that might help. The goal for 3.0 is to do all the mapping work as part of the build and generate codecs so there's very little reflection at runtime. So a purely dynamic scenario starts to get tricky but there are options to consider while those details are getting worked. So I'd love to know bit more about how your setup works so I can do my best to not break it.

[Azn9]

(I'm on my phone now so if something isn't clear I'll edit it tomorrow when I'll be on a computer 😅)

We're working with a main project named "core" that group all the specific methods (like connecting to a database, rabbitmq etc.). These classes are then provided via dependency injection to any other class that needs to do something.
It allows us to have only one very generic class for database interaction, so we don't have to use external libraries everywhere, in case these methods get updated for instance.

A small example of this class using morphia:

// Morphia imports

@Provides
public final class MongoService {

    private Datastore datastore;

    public void initialize() {
        // ...
    }

    public void registerClass(Class<?> clazz) {
        this.datastore.getMapper().map(clazz);
    }

    public <T> T get(Class<T> tClass, Object id) {
        // ...
    }
}

=====
import core.MongoService;
// No need to import any morphia classes here, we can even don't add it's dependency

public class AClassSomewhere {

    @Inject
    private static MongoService mongoService;

    public void start() {
        mongoService.registerClass(Z.class);
        Z z = mongoService.get(Z.class, "someid");
    }
}

The "core" library is just a library that we use in many places. There is no way for it to know any class, and even any package, that we will use.
And we don't want to recreate the datastore in the other part of the app, that would go against the way we want it to work (no use and even dependency to external dependencies other than the core). Actually the initialization of the databases, connections and other stuff is done by the core on it's boot, we just hook on it when we need to use it, it's a one-way dependency.
Another "issue" with our project structure is that we could have multiple parts of the app that use the core, but are separated from the others, so re-initializing the datastore would have to be done in every part, which would just duplicate even more the code.

[evanchooly]

Just a note because you probably didn't see it, but based on feedback this transition to file based configs is getting a rethink. Ultimately, I think we'll end up with support for both since programmatic configuration turned out to be a much more important feature than anticipated. The API will like likely center around a new class for various reasons but in the end, programmatic config is almost certainly here to stay.