I would like to add a few comments.

Right now all beans are active by default so without explicit component configuration stating active=false it will get loaded if the binary is in the classpath

That is partially true. It will be loaded and active if there is no explicit component configuration stating active=false and if parent= is assigned to bean class which is also active, ie.

@Bean(name = "component")

will never be loaded if it will not be mentioned in configuration.

@Bean(name = "component", parent=Kernel.class)

will be loaded always (as Kernel.class is always a bean extending Kernel.class)

@Bean(name = "component", parent=MessageArchiveComponent.class)

will be loaded only if MessageArchiveComponent is configured to be loaded and active=true is in configuration (as MessageArchiveComponent is annotated with @active=false@).

Due to that, I think this is proper behaviour as you exactly know what to expect and dependent beans are automatically enabled/activated when needed. Also please not that most of beans needs to be annotated with active=true

If we would invert this behaviour then it would be a mess as you would need to enable optional component (bean) and all beans related to component bean, ie. repository pool bean, discovery module bean, ping module bean, etc.

As an alternative solution (if you decide we need to change this) I would suggest to force developer to pass explicit value to active field of an @Bean annotation.

Andrzej Wójcik wrote:

I would like to add a few comments.

Right now all beans are active by default so without explicit component configuration stating active=false it will get loaded if the binary is in the classpath

That is partially true. It will be loaded and active if there is no explicit component configuration stating active=false and if parent= is assigned to bean class which is also active, ie.

[...]

will never be loaded if it will not be mentioned in configuration.

[...]

will be loaded always (as Kernel.class is always a bean extending Kernel.class)

[...]

will be loaded only if MessageArchiveComponent is configured to be loaded and active=true is in configuration (as MessageArchiveComponent is annotated with @active=false@).

Due to that, I think this is proper behaviour as you exactly know what to expect and dependent beans are automatically enabled/activated when needed. Also please not that most of beans needs to be annotated with active=true

Comment came from a quick observation that with the really quick observation that with a relatively empty config and more-or less default distribution I ended up with a lot of components being loaded and activated (http-api and licenceserver for example). This looks a bit like a regression/change in desired behaviour in comparison to previous versions where you had to explicitly enable component to be loaded (but this would break quickly with the whole dependency injection).

If we would invert this behaviour then it would be a mess as you would need to enable optional component (bean) and all beans related to component bean, ie. repository pool bean, discovery module bean, ping module bean, etc.

Would it be possible to differentiate behaviour based on the parent class? For example Kernel.class would signify a main Tigase component (a bit of a leap and guessing here) which would be loaded only if explicitly configured in the configuration file, and other beans would load if the parent (for example discovery depends on the particular component being used) would be activated automatically when particular component is enabled? Does this make sense?

It should be feasible (and you commented during the call that injection works based on correct levels which would indicate that at some level we have a "proper component bean"), or add explicit property denoting concrete component?

As an alternative solution (if you decide we need to change this)

I think this question is more for %kobit - what defaults and default behaviour we want to have and maintain.

I would suggest to force developer to pass explicit value to active field of an @Bean annotation.

I don't think enforcing this is the best idea, but if nothing else works this may be a middle-ground solution.

Wojciech Kapcia wrote:

Andrzej Wójcik wrote:

I would like to add a few comments.

Right now all beans are active by default so without explicit component configuration stating active=false it will get loaded if the binary is in the classpath

That is partially true. It will be loaded and active if there is no explicit component configuration stating active=false and if parent= is assigned to bean class which is also active, ie.

[...]

will never be loaded if it will not be mentioned in configuration.

[...]

will be loaded always (as Kernel.class is always a bean extending Kernel.class)

[...]

will be loaded only if MessageArchiveComponent is configured to be loaded and active=true is in configuration (as MessageArchiveComponent is annotated with @active=false@).

Due to that, I think this is proper behaviour as you exactly know what to expect and dependent beans are automatically enabled/activated when needed. Also please not that most of beans needs to be annotated with active=true

Comment came from a quick observation that with the really quick observation that with a relatively empty config and more-or less default distribution I ended up with a lot of components being loaded and activated (http-api and licenceserver for example). This looks a bit like a regression/change in desired behaviour in comparison to previous versions where you had to explicitly enable component to be loaded (but this would break quickly with the whole dependency injection).

Exactly, but we are now in a point in which we already did a big change - introduction of dependency injection and Tigase Kernel. Due to that I think it may be possible to change this behavior at this point.

%kobit What do you think?

If we would invert this behaviour then it would be a mess as you would need to enable optional component (bean) and all beans related to component bean, ie. repository pool bean, discovery module bean, ping module bean, etc.

Would it be possible to differentiate behaviour based on the parent class? For example Kernel.class would signify a main Tigase component (a bit of a leap and guessing here) which would be loaded only if explicitly configured in the configuration file, and other beans would load if the parent (for example discovery depends on the particular component being used) would be activated automatically when particular component is enabled? Does this make sense?

I do not like this idea - we should keep things simple and all beans should behave in a same way. Please keep in mind that it is always possible to mark component beans with @active=false@, so what is point of enforcing it and making it more complicated (even for user)?

It should be feasible (and you commented during the call that injection works based on correct levels which would indicate that at some level we have a "proper component bean"), or add explicit property denoting concrete component?

As an alternative solution (if you decide we need to change this)

I think this question is more for %kobit - what defaults and default behaviour we want to have and maintain.

I would suggest to force developer to pass explicit value to active field of an @Bean annotation.

I don't think enforcing this is the best idea, but if nothing else works this may be a middle-ground solution.

I think this is best thing we can do.

Andrzej Wójcik wrote:

Wojciech Kapcia wrote:

Andrzej Wójcik wrote:

Comment came from a quick observation that with the really quick observation that with a relatively empty config and more-or less default distribution I ended up with a lot of components being loaded and activated (http-api and licenceserver for example). This looks a bit like a regression/change in desired behaviour in comparison to previous versions where you had to explicitly enable component to be loaded (but this would break quickly with the whole dependency injection).

Exactly, but we are now in a point in which we already did a big change - introduction of dependency injection and Tigase Kernel. Due to that I think it may be possible to change this behavior at this point.

%kobit What do you think?

The question remains whether new behaviour makes sense (opt-out) - I would say that manually enabling desired components (apart from defaults) should be maintained (in mi mind this feels like buying new laptop with LeadingOperatingSystem which loads every bit of software it came with instead of only what's needed allowing you to add what you need; keep in mind that in -dist-max we bundle a lot of components so loading everything would be rather bad idea).

%wojtek I agree with that. That's why most of components (optional components) is annotated with @Bean(active=false) which is exactly what you want to achive. (see MUC, PubSUB, Message Archiving, Unified Archive, etc.)

Only HTTP API was marked with active=false as it is required and should be active by default (at least that was why it was added to default init.properties in 7.1.0).

Also if you would look back at version 7.1.0, there is a lot of components which are enabled/active by default without any configuration being written, ie. AMP, C2S, BOSH, S2S, etc. and you need to manually turn them off, so we already had an opt-out.

Andrzej Wójcik wrote:

%wojtek I agree with that. That's why most of components (optional components) is annotated with @Bean(active=false) which is exactly what you want to achive. (see MUC, PubSUB, Message Archiving, Unified Archive, etc.)

Only HTTP API was marked with active=false as it is required and should be active by default (at least that was why it was added to default init.properties in 7.1.0).

%andrzej.wojcik

I'm aware of that - but still it was mostly intended for running a web installer and after running setup it would/should be possible to disable it (was it disable automatically? or the config was kept?). I would say that keeping it that way would be preferred as http-api component doesn't seem essential to XMPP per se.

Also if you would look back at version 7.1.0, there is a lot of components which are enabled/active by default without any configuration being written, ie. AMP, C2S, BOSH, S2S, etc. and you need to manually turn them off, so we already had an opt-out.

I know, but those looks like a "core component" and having them enabled by default makes sense (CMs enable communication, SM enable handling user sessions, etc); MUC, PubSub, MA/UA on the other hand can be considered as additional functionality. Please bare in mind, that mentioned defaults depended also on config-type property (which I think currently is completely ignored? there is also #4880 possibly related to it).

I am not sure if I follow the discussion correctly. I am (hopefully) looking at it from the end-user perspective, so my expectation (best user experience) is that:

1. Fresh, not-configured installation, should load only components, modules and plugins which are necessary for the installation time. For the web-installer we only need HTTP-API component and... anything else? If there is anything else necessary, then, yes, we should load it as well. This way, we avoid most of errors in the log files and also startup time would be much shorter.

2. Installer presents to the end-user a default configuration with some components and plugins enabled by default, which can be changed by the end-user during installation time. This default should be a reasonable configuration for a typical XMPP service and may include some components which are specific to Tigase and which we would like to "sell/advertise". I would prefer to load UA by default instead of MA component as it offers more functionality to the end-user. Components which should not be enabled by default are: Socks5 proxy, STUN.

3. Licenseserver should not be included at all in our distribution packages. This is our internal only component.

4. Of course, during normal operation time, Tigase/kernel should only load components which are specified in the configuration file.

Artur Hefczyc wrote:

Of course, during normal operation time, Tigase/kernel should only load components which are specified in the configuration file.

(I skipped the other comments as Tigase works like it currently)

That's the clue of the issue - right now (in 7.2.0) Tigase will load all beans that it will find in classpath (@jars/@) regardless of them being enabled in the configuration. It will not load a component if:

• it's explicitly disabled in the @etc/init.properties@, or

• it's explicitly set as Bean(…active = false…) in the source (if the active parameter is missing then the default for it is true which will result in loading the component.

So the proposed solution is to enforce setting this in bean configuration in the source (currently MUC and PubSub are made this way: @@Bean(name = "muc", parent = Kernel.class, active = false,…@)

Yes, this is correct behavior in my opinion. Actually, from the end-user point of view, it works exactly the same as the previous Tigase XMPP Server versions. I mean, there was a set of components and plugins which were loaded by default, unless explicitly disabled in the configuration file.

So, yes, we can continue this with the new behavior and control default set of components from the source code (as in previous versions) by setting bean active to false or true.

However, I think, now, we can load more components, than in the old version by default. It makes sense to load additional components which might not be loaded by default previously:

1. UA

2. MUC

3. PubSub

4. AMP

The only components which should not be loaded by default, which come to my mind are:

1. Workgroup Queue

2. Socks5 Proxy

3. STUN

I disagree that we should load by default other new components such as UA, MA, MUC, PubSub as they are not core server components and are not required nor expected to be active (as they weren't in previous version). I've enabled HTTP API as setup depends on this component and features like UI and Admin UI will not work without it and are expected by end user to be available by default.

As for other components - they are now very easy to enable, ie. to enable PubSub just add:

pubsub () {}

and component will be activated. No need to pass class names, etc.

Artur Hefczyc wrote:

Yes, this is correct behavior in my opinion. Actually, from the end-user point of view, it works exactly the same as the previous Tigase XMPP Server versions. I mean, there was a set of components and plugins which were loaded by default, unless explicitly disabled in the configuration file.

Yes, this is true, but there is a tiny change - for the component to be default you would have to specify it as such (lists in Configurator), currently you have to explicitly mark component (or any bean for that matter) as @active=false@.

And because not all components are, it results in loading more than desired/being obvious.

We can continue with it but I think we should make it mandatory to include active property in annotation.

I'm not so sure we should enable MUC/PubSub/UA (especially UA, as it's not standard as) - we have a webinstaller which allows selecting desired components.

So far list of default components consist of "core" components (message-router, session-manager, connection managers) which IMHO makes sense - it allows basic operation of the server.

The only components which should not be loaded by default, which come to my mind are:

Workgroup Queue

This component is not publicly available nor bundled.

As for the default set of components we have to look at it from the end-user perspective. A user who installs an application with default configuration expects all the standard functionality to be included. So, defaults we had years ago and which we had for year do not necessarily are the best right now.

Nowadays MUC and PubSub is pretty much standard and expected to be supported out of the box. AMP and MA is less obvious as the support is not so widely available yet. However, UA offers something special, I believe it is suppers solution over MA and we should promote it. One of the way to promote it would is to include it in a default list of components loaded into server. So, as long as the UA is backward compatible with MA (XEP-0136) I would like it to be loaded by default.

HTTP API should be enabled as well by default, even after the installation is complete. REST API is pretty much a standard for accessing various services and many people expect it to be available.

I agree that the active property in annotation should be mandatory. I do not like to leave anything to chance or have side-effects of something happening and rely on such side-effects. Loading or not loading components must be intentional.

Artur Hefczyc wrote:

As for the default set of components we have to look at it from the end-user perspective.

Same here.

A user who installs an application with default configuration expects all the standard functionality to be included. So, defaults we had years ago and which we had for year do not necessarily are the best right now.

There is distinction with the default installer components (which generates resulting configuration file) and default components loaded, example below.

Nowadays MUC and PubSub is pretty much standard and expected to be supported out of the box. AMP and MA is less obvious as the support is not so widely available yet.

While I agree those are considered default and has been set as such in the installer since the beginning we are switching from following (results in loading MR/SM/all CMs):

config-type=--gen-config-def
--virt-hosts = atlantiscity
--admins =admin@atlantiscity
--user-db-uri=jdbc:mysql://localhost:3306/tigasedb?user=tigase&password=tigase

to (which would load everything that is not marked as active=false - and we would have to stress that in the documentation [I for one found it a bit counter-intuitive at the very beginning]):

config-type = '--gen-config-def'
--virt-hosts = atlantiscity
admins = [ 'admin@atlantiscity' ]
dataSource {
    default {
        uri = 'jdbc:mysql://localhost:3306/tigasedb?user=tigase&password=tigase
    }
}

So with the current behaviour after someone deselects MUC and PubSub it would end-up with following config (and other not correctly annoted now) is that correct? :

config-type = '--gen-config-def'
--virt-hosts = atlantiscity
admins = [ 'admin@atlantiscity' ]
dataSource {
    default {
        uri = 'jdbc:mysql://localhost:3306/tigasedb?user=tigase&password=tigase
    }
}

pubsub (active: false) {}
muc (active: false) {}

I agree that the change is quite minute, but IMHO it feels (felt) a bit random at first.

I agree that the active property in annotation should be mandatory. I do not like to leave anything to chance or have side-effects of something happening and rely on such side-effects. Loading or not loading components must be intentional.

Again - documentation and clear explanation what this property is and what it does (including javadoc) is a must I think. And appropriately marking all our components as active=false (except for the defaults that we want, which could include the core and MUC/PubSub .

%andrzej.wojcik a question - if the component is marked as active=false it will result in it's beans not being loaded as well - correct?

%wojtek Yes, you are correct.

Wojciech Kapcia wrote:

Artur Hefczyc wrote:

So with the current behaviour after someone deselects MUC and PubSub it would end-up with following config (and other not correctly annoted now) is that correct? :

Yes, this is correct. And of course, all the components which are not correctly annotated, can be easily fixed, can they? It does not look like a complex task?

Again - documentation and clear explanation what this property is and what it does (including javadoc) is a must I think. And appropriately marking all our components as active=false (except for the defaults that we want, which could include the core and MUC/PubSub .

Yes, we need a good documentation on this topic. And in general we need a good documentation on the new kernel stuff and new API. I have to admit it is quite complex for me.

Artur Hefczyc wrote:

Wojciech Kapcia wrote:

Artur Hefczyc wrote:

So with the current behaviour after someone deselects MUC and PubSub it would end-up with following config (and other not correctly annoted now) is that correct? :

Yes, this is correct. And of course, all the components which are not correctly annotated, can be easily fixed, can they? It does not look like a complex task?

It can be fixes (or better yet, as explained above, make this annotation required).

%kobit - can you confirm list of default, desired component active by default (stated in #4888#note-10)?

Again - documentation and clear explanation what this property is and what it does (including javadoc) is a must I think. And appropriately marking all our components as active=false (except for the defaults that we want, which could include the core and MUC/PubSub .

Yes, we need a good documentation on this topic. And in general we need a good documentation on the new kernel stuff and new API. I have to admit it is quite complex for me.

%kobit

There are already #2984, #4890 and #1920

Wojciech Kapcia wrote:

%kobit - can you confirm list of default, desired component active by default (stated in #4888#note-10)?

Additional components which I would like to be loaded by default:

1. UA

2. MUC

3. PubSub

4. AMP

Andrzej, can you make changes as per discussion:

• make the annotation mandatory;

• enable by default above components and make inactive remaining?

Wojciech Kapcia wrote:

Andrzej, can you make changes as per discussion:

• make the annotation mandatory;

Sure, no problem. I will do that.

• enable by default above components and make inactive remaining?

I cannot agree to enable UA by default. Can we enable MA by default?

Artur, I know that you would prefer to enable UA as it is extension to the MA, but UA supports only databases to store data (JDBC only). So if we would enable UA by default then we would get errors if anyone would decide to use Tigase with MongoDB.

While I agree that UA has better features, I think we should active by default only components which supports all data stores supported by Tigase.

To deal with this I would like to suggest to enable MA by default and later on, when UA will get support for MongoDB we would enable if by default, do you agree?

+Note:+ Adding support for MongoDB to UA is very tricky thing as UA uses a lot of complex queries, which are difficult to implement in data store such as MongoDB.

Ok, that makes sense. Let's start with MA as a default component.

I've enabled:

1. MA (with XEP-0136 and XEP-0313)

2. MUC

3. PubSub (without PEP)

I decided not to enable PEP by default as it would increase load on a server as each presence is forwarded to PubSub component for processing.

I've not activated AMP as it was already enabled for a long time.

However after I did all of that, I have a few additional questions:

1. Should I enabled PEP in PubSub as well?

In my opinion it is expected to have PEP in latests XMPP server available.

1. I've enabled PubSub and MUC also in clustered mode as well. However it will result in server being shut down if ACS will not be enabled on this server when ACS-PubSub and ACS-MUC will be active.

I have no idea what to do in this case. Maybe PubSub and MUC should be disabled in cluster mode by default? but there will be inconsistency with PubSub and MUC being enabled in non-cluster mode.

Andrzej Wójcik wrote:

I've enabled:

MA (with XEP-0136 and XEP-0313)

MUC

PubSub (without PEP)

I decided not to enable PEP by default as it would increase load on a server as each presence is forwarded to PubSub component for processing.

I've not activated AMP as it was already enabled for a long time.

However after I did all of that, I have a few additional questions:

Should I enabled PEP in PubSub as well?

In my opinion it is expected to have PEP in latests XMPP server available.

Yes, I agree, it should be active by default. Again, another point to the performance related information/documentation.

I've enabled PubSub and MUC also in clustered mode as well. However it will result in server being shut down if ACS will not be enabled on this server when ACS-PubSub and ACS-MUC will be active.

I think majority of "default" installation installed with web installer would be for testing/development purposes in a single (non-clustered) mode. So this must work without any problems. It is not acceptable that the server shuts-down with default configuration with ACS not enabled.

I have no idea what to do in this case. Maybe PubSub and MUC should be disabled in cluster mode by default? but there will be inconsistency with PubSub and MUC being enabled in non-cluster mode.

First question which comes to my mind. How is this different from SM? Don't we have the same problem with SM?

1. Ideal solution - standard MUC/PubSub in non-clustered mode and ACS-MUC, ACS-PubSub when ACS is active. Everything is possible but how difficult/expensive is to get the ideal solution?

2. Enable ACS by default... So the Tigase would run in a cluster mode, even when it is installed on a single machine, this way we could always have ACS-MUC and ACS-PubSub activated. Maybe, this is even the best long-term solution, so Tigase would always run in a cluster mode. However, there a few serious concerns:

3. Clustered mode, even on a single server may misbehave if there are some network configuration issues. It may attempt to connect to itself, etc.... And many testing and development installations may run on not exactly well configured machine.

4. If we always enabled ACS, then people running Tigase on single server for production, would be required to have the ACS license. This has some pros/cons to consider. We could offer a free ACS license for all single-server installations. Or all single-server ACS installations could run on our trial license without any restrictions on our side. This would give us some stats in our database so we would know more about our user-base, but our database could be overloaded or these free users could start complain that we collect some data without asking for permission, etc.... However, knowing more about our users has a huge value to us. So we could give single server ACS for free (collecting stats) but to ensure users are not complaining we could include something in ACS which has practical value to our users. So they can switch ACS off and not send stats to us, but they would loose some nice features.

5. If we always run Tigase with ACS, even on a single server, then at some point we may loose the ability for Tigase to run without ACS if we too much depend on it and stop testing Tigase without ACS...

6. Run Tigase without ACS by default and by default load non-ACS MUC and PubSub, simple and would work by default.

7. By default ACS is disable and non-ACS MUC and PubSub is loaded as in point above, however, if a user selects ACS in web installer, the web installer would automatically take care of loading default components in ACS mode.

Artur Hefczyc wrote:

Andrzej Wójcik wrote:

I've enabled:

MA (with XEP-0136 and XEP-0313)

MUC

PubSub (without PEP)

I decided not to enable PEP by default as it would increase load on a server as each presence is forwarded to PubSub component for processing.

I've not activated AMP as it was already enabled for a long time.

However after I did all of that, I have a few additional questions:

Should I enabled PEP in PubSub as well?

In my opinion it is expected to have PEP in latests XMPP server available.

Yes, I agree, it should be active by default. Again, another point to the performance related information/documentation.

Ok, I will need to enable this.

I've enabled PubSub and MUC also in clustered mode as well. However it will result in server being shut down if ACS will not be enabled on this server when ACS-PubSub and ACS-MUC will be active.

I think majority of "default" installation installed with web installer would be for testing/development purposes in a single (non-clustered) mode. So this must work without any problems. It is not acceptable that the server shuts-down with default configuration with ACS not enabled.

I have no idea what to do in this case. Maybe PubSub and MUC should be disabled in cluster mode by default? but there will be inconsistency with PubSub and MUC being enabled in non-cluster mode.

I will skip rest of a comment as I think we have a misunderstanding here. Let me explain how it works now (and I think it is near to ideal):

1. In non-cluster mode - non-clustered versions of components are activated

2. In cluster mode - clustered versions of components are activated

In second case, if ACS is disabled and MUC or PubSub are enabled then Tigase will decline to start as clustered versions of MUC and PubSub require ACS to work.

So the questions here are:

1. is it correct?

2. if not then what should we do? Non-clustered versions of MUC and PubSub will also fail to properly work in cluster mode (with or without ACS)

In my opinion (after I reviewed you comment), I think we can leave it as it is. Only installer should be aware (and inform user), that for MUC and PubSub in cluster mode it requires ACS.

%kobit Please assign it later back to me, so I will be able to adjust our code.

Artur Hefczyc wrote:

I've enabled PubSub and MUC also in clustered mode as well. However it will result in server being shut down if ACS will not be enabled on this server when ACS-PubSub and ACS-MUC will be active.

I think majority of "default" installation installed with web installer would be for testing/development purposes in a single (non-clustered) mode. So this must work without any problems. It is not acceptable that the server shuts-down with default configuration with ACS not enabled.

A small comment - in such case installer asks whether enable clustering and allows enabling muc only if ACS is enable if memory serves me right.

So if the user later on would change configuration and end up with wrong configuration it would be… somewhat it's fault.

I will skip rest of a comment as I think we have a misunderstanding here. Let me explain how it works now (and I think it is near to ideal):

In non-cluster mode - non-clustered versions of components are activated

In cluster mode - clustered versions of components are activated

In second case, if ACS is disabled and MUC or PubSub are enabled then Tigase will decline to start as clustered versions of MUC and PubSub require ACS to work.

Ok, so we are talking here about clustered mode without ACS right? (Do we really want to maintain this mode....)

My question is: how can this happen? Does our web installer allow for this? If it does, then it should make sure non-ACS MUC and PubSub are loaded in such a case.

I am confused here, because we are still talking about more or less default behavior. And this is something created by our web installer without any manual intervention.

Or maybe the question is what happens with more or less empty configuration file, with some essential settings only. In my opinion an empty config file is for a non-clustered mode. If clustered mode is activated in the installer then installer takes care of correct components to be loaded. If somebody just manually activates clustered mode in the config file, than we do not have to worry about this. As Wojciech pointed out, this is "his fault".

So the questions here are:

is it correct?

if not then what should we do? Non-clustered versions of MUC and PubSub will also fail to properly work in cluster mode (with or without ACS)

If this is a result of a manual config change by a user, then this is acceptable. I would even go as far as this:

1. By default (almost empty config file with DB settings only and some essentials) Tigase runs in non-clustered mode and non-ACS MUC and PubSub is loaded

2. If somebody manually adds to the config file cluster mode (ACS or non-ACS) without any other settings, then we still should load non-ACS MUC and PubSub.

In my opinion (after I reviewed you comment), I think we can leave it as it is. Only installer should be aware (and inform user), that for MUC and PubSub in cluster mode it requires ACS.

Yes, exactly.

%kobit Please assign it later back to me, so I will be able to adjust our code.

Done.

Now PEP is enabled by default as well.

I reviewed description of default behaviour and it will work as described. We only need to work on setup module (as it will not work with DSL), but for that we have separate task #4896.