Most likely it is caused by the fact that beans are not loaded/initialized.

I've added support for logging configuration for inactive beans

Thanks, it looks better. However mailer bean is still not shown (and it started with it)

Wojciech Kapcia wrote:

Thanks, it looks better. However mailer bean is still not shown (and it started with it)

I've checked and Mailer bean is not annotated with parent set, so if it is not directly mentioned within config file it will not be loaded. As a result, Kernel is not aware of it (until it is configured) and this makes it impossible to be listed and presented in the config dump.

Andrzej Wójcik wrote:

I've checked and Mailer bean is not annotated with parent set, so if it is not directly mentioned within config file it will not be loaded. As a result, Kernel is not aware of it (until it is configured) and this makes it impossible to be listed and presented in the config dump.

Shouldn't it then belong to the "root"? After looking at the javadoc:

Object if bean should never be automatically registered
tigase.kernel.core.Kernel if bean should be automatically registered in the main/root kernel
class implementing RegistrarBean if bean should be loaded automatically for that class

But - it's injected in MailerMonitor so if we enable MailerMonitor shouldn't Mailer configuration be included in the dump?

With following configuration:

monitor () {
    monitor-mailer(class: tigase.server.ext.monitor.MonitorMailer) {
        'from-address' = 'sender@xx'
        'to-addresses' = 'receiver@xx'
    }
}

2017-07-10 18:32:57.402 [main]             Kernel.injectDependencies()             WARNING:  Could not initialize bean monitor-mailer (class: class tigase.server.ext.monitor.MonitorMailer), skipping injection of this bean

And we are forced to include mailer configuration:

monitor () {
    monitor-mailer(class: tigase.server.ext.monitor.MonitorMailer) {
        'from-address' = 'sender@xx'
        'to-addresses' = 'receiver@xx'
    }
    mailer(class: tigase.extras.mailer.Mailer) {
        'mailer-smtp-host' = 'mail.xx'
        'mailer-smtp-port' = '587'
        'mailer-smtp-username' = 'sender'
        'mailer-smtp-password' = 'xx'
        'mailer-from-address' = 'sender@xx'
    }
}

And the whole point of including the defaults is to have a quick and easy overview of what can and should be configured. Thinking about it - it could be useful to include in the dump options that doesn't have the default?

Wojciech Kapcia wrote:

Andrzej Wójcik wrote:

I've checked and Mailer bean is not annotated with parent set, so if it is not directly mentioned within config file it will not be loaded. As a result, Kernel is not aware of it (until it is configured) and this makes it impossible to be listed and presented in the config dump.

Shouldn't it then belong to the "root"? After looking at the javadoc:

[...] so the default it Object and this looks likes it makes sense - we don't want it automatically registered.

But - it's injected in MailerMonitor so if we enable MailerMonitor shouldn't Mailer configuration be included in the dump?

No, because it only means that MailerMonitor requires Mailer@. And if @Mailer would be an interface then which implementation should be loaded as a bean? We would not know. That is why fields annotated with @Inject only mean that something is required, but proper implementation needs to be registered within Kernel and for that @Bean annotation with parent property is.

With following configuration:

[...] we get following error:

[...]

And we are forced to include mailer configuration:

[...]

Yes, we are. As Mailer may be registered in more than one place/scope. And different beans will have different instances with a different configuration of @Mailer@.

To make it simpler, I would say that @Mailer@, in this case, is a required parameter which is not configured and do not have a default value.

And the whole point of including the defaults is to have a quick and easy overview of what can and should be configured. Thinking about it - it could be useful to include in the dump options that doesn't have the default?

Option/property always has some value, so always have a default value.

Back to Mailer "issue", it is very similar to trying to create second MUC component named muc1@. You are **required** to provide a class name as there is no default class for a bean with this name. And you will not get MUC component options until you put @muc1 (class: ..) {} in the config file.

ok, thank you.