Retrieval mechanisms for the active ModelInstanceRepository inhibit extension patterns.

TechnologyBrewery / fermenter

In brewing, a fermenter is a vessel in which unfinished ingredients become nearly finished beer. In Model Driven Architecture, Fermenter is a project that converts functional concepts into nearly finished applications. This approach allows for the quick definition and assembly of applications with the focus on functional concepts.

MIT License

2 stars 3 forks source link

Currently, the only mechanism to retrieve the configured ModelInstanceRepository implementation instance, and thus to interrogate the underlying schemas informing generation, is to use this static method provided in the ModelInstanceRepositoryManager class:

    public static <V> V getMetamodelRepository(Class<V> type) {
        Map<String, Object> instanceMap = threadBoundInstance.get();
        return type.cast(instanceMap.get(type.toString()));
    }

Suppose a fermenter-based project Project_A provides their own ModelInstanceRepository implementation, MIR_A. Within the project's generators, they may be forced to include code such as the following:

MIR_A metamodelRepository = ModelInstanceRepositoryManager
                .getMetamodelRepository(MIR_A.class);

This will work fine for this initial project. However, if another project Project_B is created to extend Project_A, with its own ModelInstanceRepository implementation MIR_B extends MIR_A, then existing calls of the above snippet will fail with null pointer exceptions. This is due to the naive string-name lookup method found in the getMetamodelRepository method above. Extension patterns are thus inhibited.

TechnologyBrewery / fermenter

Retrieval mechanisms for the active ModelInstanceRepository inhibit extension patterns. #78