Project

General

Profile

Bug #4888

Kernel beans are active by default

Added by Wojciech Kapcia TigaseTeam about 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Target version:
Start date:
2017-02-08
Due date:
2017-03-07
% Done:

0%

Estimated time:
Database:
n/a
Applicable version:
git/master
Source Code Disclaimer:

Description

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. I think it should be on the opt-in basis (as it was in 7.1.0) instead on the opt-out (except for a couple of default components). Right now for example MUC is explicitly disabled:

@Bean(name = "muc", parent = Kernel.class, active = false, selectors = {BeanSelector.NonClusterMode.class})
public class MUCComponent extends AbstractKernelBasedComponent {

But any component defining only @Bean(name = "component") will get loaded.

%kobit - what do you think?


Related issues

Related to Tigase HTTP API - Feature #4880: config-type=setup implementationClosed2017-03-282017-04-28

Related to Tigase XMPP Server - Task #2984: Tigase Kernel - documentationClosed2015-04-142017-06-16

Related to Tigase XMPP Server - Bug #4991: 'Default' Data Repo Bean causes JREClosed2017-04-13

Associated revisions

Revision 2e2a9dee (diff)
Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

#4888: Updated source code after removal of default value of active property of a @Bean annotation

Revision faf553da (diff)
Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

#4888: removed default value of active property of a @Bean annotation

Revision 06c69366 (diff)
Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

#4888: Updated source code after removal of default value of active property of a @Bean annotation

Revision b64631d8 (diff)
Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

#4888: Updated source code after removal of default value of active property of a @Bean annotation

Revision 14100907 (diff)
Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

#4888: Updated source code after removal of default value of active property of a @Bean annotation

Revision 72b611f3 (diff)
Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

#4888: Updated source code after removal of default value of active property of a @Bean annotation

Revision 5232be69 (diff)
Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

#4888: activating MUC component by default

Revision debe1adb (diff)
Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

#4888: activating MA component by default

History

#1 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam about 2 years ago

  • Assignee changed from Andrzej Wójcik to Wojciech Kapcia

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.

#2 Updated by Wojciech Kapcia TigaseTeam about 2 years ago

  • Status changed from New to Feedback
  • Assignee changed from Wojciech Kapcia to Andrzej Wójcik

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.

#3 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam about 2 years ago

  • Assignee changed from Andrzej Wójcik to Wojciech Kapcia

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.

#4 Updated by Wojciech Kapcia TigaseTeam about 2 years ago

  • Due date changed from 2017-02-15 to 2017-02-17
  • Assignee changed from Wojciech Kapcia to Artur Hefczyc

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).

#5 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam about 2 years ago

%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.

#6 Updated by Wojciech Kapcia TigaseTeam about 2 years ago

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).

#7 Updated by Wojciech Kapcia TigaseTeam about 2 years ago

  • Related to Feature #4880: config-type=setup implementation added

#8 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam about 2 years ago

  • Assignee changed from Artur Hefczyc to Wojciech Kapcia

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.

#9 Updated by Wojciech Kapcia TigaseTeam about 2 years ago

  • Due date changed from 2017-02-17 to 2017-02-24
  • Assignee changed from Wojciech Kapcia to Artur Hefczyc

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,…@)

#10 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam about 2 years ago

  • Assignee changed from Artur Hefczyc to Wojciech Kapcia

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

#11 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam about 2 years ago

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.

#12 Updated by Wojciech Kapcia TigaseTeam about 2 years ago

  • Due date changed from 2017-02-24 to 2017-02-28
  • Assignee changed from Wojciech Kapcia to Artur Hefczyc

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.

#13 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam about 2 years ago

  • Assignee changed from Artur Hefczyc to Wojciech Kapcia

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.

#14 Updated by Wojciech Kapcia TigaseTeam about 2 years ago

  • Assignee changed from Wojciech Kapcia to Artur Hefczyc

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?

#15 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam about 2 years ago

%wojtek Yes, you are correct.

#16 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam about 2 years ago

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.

#17 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam about 2 years ago

  • Assignee changed from Artur Hefczyc to Wojciech Kapcia

#18 Updated by Wojciech Kapcia TigaseTeam almost 2 years ago

  • Assignee changed from Wojciech Kapcia to Artur Hefczyc

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

#19 Updated by Wojciech Kapcia TigaseTeam almost 2 years ago

  • Related to Task #2984: Tigase Kernel - documentation added

#20 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam almost 2 years ago

  • Assignee changed from Artur Hefczyc to Wojciech Kapcia

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

#21 Updated by Wojciech Kapcia TigaseTeam almost 2 years ago

  • Due date changed from 2017-02-28 to 2017-03-01
  • Assignee changed from Wojciech Kapcia to Andrzej Wójcik

Andrzej, can you make changes as per discussion:

  • make the annotation mandatory;

  • enable by default above components and make inactive remaining?

#22 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

  • Due date changed from 2017-03-01 to 2017-03-03
  • Assignee changed from Andrzej Wójcik to Artur Hefczyc

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.

#23 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam almost 2 years ago

  • Assignee changed from Artur Hefczyc to Andrzej Wójcik

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

#24 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

  • Due date changed from 2017-03-03 to 2017-03-07
  • Assignee changed from Andrzej Wójcik to Artur Hefczyc

#26 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

  • Related to Bug #4991: 'Default' Data Repo Bean causes JRE added

#28 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam almost 2 years ago

  • Assignee changed from Artur Hefczyc to Andrzej Wójcik

#29 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

  • Assignee changed from Andrzej Wójcik to Artur Hefczyc

#32 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam almost 2 years ago

  • Assignee changed from Artur Hefczyc to Andrzej Wójcik

#34 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

  • Status changed from Feedback to Resolved

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.

#35 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF