I added simplified stacktrace to the error message to make it easier to debug (this and other issues):

  =============================================================================
  ERROR! Terminating the server process.
  Problem initializing the server:
RootCause:
   -> java.lang.ClassCastException: java.util.ArrayList cannot be cast to java.lang.Boolean
      [tigase.conf.ConfigReader.process(ConfigReader.java:304)]
  Please fix the problem and start the server again.
  =============================================================================

The issue itself boiled down to using 'active' configuration name and following code:

// special use case to convert maps with active or class into bean definition
if (val != null && (val.containsKey("active") || val.containsKey("class"))) {
	AbstractBeanConfigurator.BeanDefinition bean = new AbstractBeanConfigurator.BeanDefinition();
	bean.setBeanName(holder.key);
	Object v = val.remove("class");
	if (v != null) {
		bean.setClazzName((String) v);
	}
	v = val.remove("active");
	if (v != null) {
		bean.setActive((Boolean) v);
	}
	bean.putAll(val);
	holder.value = bean;

I would imagine (as per comment) to use it in something like:

{
  active: true,
  class: some.bean.class,
  config_key: config_value
}

however… %andrzej.wojcik - do we support or need such configuration? Maybe we could remove this block for the sake of simplicity?

As for the issue at hand, as kind of workaround - I added alias phases to the configuration property (and also clarified documentation how to configure it).

We needed this features with active and class when we were using PropertiesBeanConfigurator which was able to load properties file and apply this configuration to beans. However, later on, we decided to drop support for properties at all and to use only DSL, so now we still have PropertiesBeanConfigurator but it is not used anywhere if I'm correct.

In this case we could get rid of this feature but would need to remove PropertiesBeanConfigurator as well.

%bmalkow What do you think? Are you in favor of removal of PropertiesBeanConfigurator? or are you against?

We can remove it. I cannot see ano pros to keep it.

Andrzej, could you remove relevant parts?

Done.