Page tree
Skip to end of metadata
Go to start of metadata

The Definitions app which is currently in the design phase aims to replace the current Config Overview app PoC. PoC revealed that one of the key features is the ability to group and filter the definitions by various properties. Another important part of the new app is going to the configuration error report. Thanks to the new Registry API it is now possible to implement both of the things, but unfortunately not without some workarounds and hacks. Here we will list several things that would fill the gaps and make the new definition app developement smoother.


Stories in JIRA
  • MAGNOLIA-6086 - Getting issue details... STATUS  
  • BL-231 - Getting issue details... STATUS
  • BL-308 - Getting issue details... STATUS

1. Configuration datasource type in metadata

(tick) Ready

MAGNOLIA-6081 - Getting issue details... STATUS  

At the moment PoC resolves the source which provides the definition via ResourceOrigin/JCR config workspace -  if a path is present in config workspace - we could assume that it is served by JCR config source, if path is present in a ResourceOrigin - then it is file based. Even though this logic works for most of the cases - still it's pretty fragile and also might be costly since such a resolution has to happen for all the definitions displayed in an app.

Instead we could enrich the DefinitionMetadata API with a ConfigSourceType property easily provided during the metadata population phase via AbstractFileResourceConfigurationSource#type().


config source type from metadata
public interface DefinitionMetadata {
    ConfigurationSourceType getConfigSourceType();

One thing  that might be a concern - what would the config source type be when it comes to definition overlaying? However, I can imagine that overlaying could be done in a form of a layered config source, so this might fit in there as well.

MAGNOLIA-6085 - Getting issue details... STATUS  

- If config source type is included into metadata then it would be really simple to add it to DefinitionQuery and then implement RegistryFacadeImpl#bySource based on it.

- In addition - RegistryFacade(?) could at least provide a list of the available ConfigSourceType's, so that the app could use them in filters.

2. Queries

(tick) Ready

(warning) For the starters AbstractRegistry.QueryPredicate takes only name and module properties into account. We need to utilise two other existing properties (DefinitionType/location) and possible additional properties in there.

3. Partial name queries

(tick) Ready

MAGNOLIA-6084 - Getting issue details... STATUS

At the moment DefinitionQuery already supports regex-search for location accepting the pattern instead of the full value. However, regex are not supported for the name property which is not user friendly at all, since one always remembers only a part of the name  => because of that in PoC app we had to  query all the definitions from RegistryFacade and and filter them with Guava capabilities.

Name matching definition query
public abstract class DefinitionQuery<T> {
 public DefinitionQuery<T> matchesName(String nameRegex) { // <= public DefinitionQuery<T> named(String defName)
        this.namePattern = Pattern.compile(nameRegex);
 		return this;

MAGNOLIA-6083 - Getting issue details... STATUS

Follow-up proposal: maybe it makes sense to provide arbitrary predicates against the definition metadata


Predicate matching definition query
public abstract class DefinitionQuery<T> {
 public DefinitionQuery<T> applies(Predicate<DefinitionMetadat> predicate) {

4. Grouped definition query results

(warning) To be further discussed

As it was mentioned before, being able to group the definitions by some trait (source type, registry type, module) is another crucial feature for comprehensive configuration UI. Would be nice to combine grouping with filtering. In order to make is simple API-wise, we could add another variant of a DefinitionQuery execution method. 

Grouping definition query results
public abstract class DefinitionQuery<T> {
 public DefinitionQuery<T> applies(Predicate<DefinitionMetadat> predicate) {
	DefinitionProvider<T> findSingle(); // exists already, yields a single-def-provider result
	DefinitionProvider<T> findMultiple(); // exists already, yields multiple def-providers
	Collection<DefinitionProvider<T>> find(); // would return a result handle, which can be further elaborated.
interface DefQueryResult {
	Collection<DefinitionProvider<T>> definitions(); // similar to findMultiple();
	// Grouped results
	Map<ConfigSourceType, Collection<DefinitionProvider<T>>> groupedBySourceType();
	Map<String, Collection<DefinitionProvider<T>>> groupedByModule();	
	Map<DefinitionType, Collection<DefinitionProvider<T>>> groupedByType()();	

However, simplest solution here would be probably to do nothing and let the consumers query the filtered query result as they wish with Guava API or similar way.

5. Conversion issues aggregation

(warning) To be further discussed

Configuration errors aggregated in UI:  

Configuration errors aggregated in UI

Currently DefinitionProvider only provides info about the issues in a form of a string list. That is not enough to build a UI like above - more meta-information about the issue would be required.

As proposed in following issues:  MAGNOLIA-6090 - Getting issue details... STATUS

a lightweight Problem class could be introduced. It would encapsulate the type of problem (inherently by its type, or by an enum attribute maybe => Severity?), and additional relevant properties (short/elaborate/formatted messages etc);

Provide list of Problem objects instead of Strings
public interface DefinitionProvider<T> {
 List<Problem> getErrorMessages();
interface Problem {
	String getType();
	String getSeverityLevel();
	String getMessage();


MAGNOLIA-6196 - Getting issue details... STATUS  
Both Map2Bean and Node2Bean should be able to track and aggregate errors during the process of conversion. For that we could introduce e.g. a special ConversionResult 
Missing property processing
interface ConversionResult<T> {
	T get();
	Collection<Problem> getProblems(); // misconfigured properties, failed conversion of sub-parts etc
public class Map2BeanTransformer {
	public <T> ConverionResult<T> toBean(Map<String, Object> map, Class<T> defaultRootType)


Provided that we have an aggregator for the conversion issues, it would be fairly simple to solve the issue since we already recognise the mis-configured properties in Map2Bean

Missing property processing
if (!targetDescription.containsKey(sourcePropertyName)) {
  // We should not just ignore this - see MAGNOLIA-6196
  log.warn("Property " + sourcePropertyName + " not found in class " + targetObj.getClass());

However, we clearly have to add the same to N2B, the exact location is to be defined.

6. Other things

  • Possibly allowing for registering the DefinitionTypes/SourceTypes
    • Not really relevant to the definitions app
  • Verify naming


  • No labels