If i configure --tigase-config-repo-class = tigase.conf.ConfigSQLRepository in init.properties, in table tigase_configuration, there will be a key has two values, one is whick i configure in init.properties, and the other is the component default value.

e.g.

I configure http api conponent in init.properties like this:

--comp-name-3 = rest

--comp-class-3 = tigase.http.rest.RestMessageReceiver

rest/port[I] = 8888

Then the port property of rest component will be inserted into the table tigase_configuration twice with two values like this:

mysql> select * from tigase_configuration where component_name="rest" and key_name="port";             
+----------------+----------+-------+--------------+----------+---------+------------+---------------------+
| component_name | key_name | value | cluster_node | key_node | flag    | value_type | last_update         |
+----------------+----------+-------+--------------+----------+---------+------------+---------------------+
| rest           | port     | 8088  |              |          | DEFAULT | I          | 2014-11-03 12:14:20 |
| rest           | port     | 8080  | localhost    |          | DEFAULT | I          | 2014-11-03 12:16:09 |
+----------------+----------+-------+--------------+----------+---------+------------+---------------------+

The first record is the value of my configuration, The second record is the default value 8080 that hard-coded in the HttpServer.class, it cause my configuration failure.

And I found some relevant information in file logs/tigase.log.0, as follows:

2014-11-03 13:26:38.165 [main]             ConfiguratorAbstract.setup()       CONFIG:   Setting up component: rest
2014-11-03 13:26:38.173 [main]             ConfiguratorAbstract.setup()       CONFIG:   Component rest defaults: {component-id=rest@localhost, def-hostname=localhost, admins=[Ljava.lang.String;@615fd9fd, scripts-dir=scripts/admin, command/ALL=ADMIN, max-queue-size=466, scheduler-threads=1, incoming-filters=tigase.server.filters.PacketCounter, outgoing-filters=tigase.server.filters.PacketCounter, api-keys=[Ljava.lang.String;@5be0a2fc, port=8080, context=/rest, context-file-path=etc/tigase-http-context.xml, use-local-server=true, rest-scripts-dir=scripts/rest}
2014-11-03 13:26:38.173 [main]             ConfiguratorAbstract.setup()       CONFIG:   Component rest configuration: {/port=8088, /admins=[Ljava.lang.String;@78ec7d83, /api-keys=[Ljava.lang.String;@6e24617a, /component-id=rest@localhost, /context=/rest, /context-file-path=etc/tigase-http-context.xml, /def-hostname=localhost, /incoming-filters=tigase.server.filters.PacketCounter, /max-queue-size=466, /outgoing-filters=tigase.server.filters.PacketCounter, /rest-scripts-dir=scripts/rest, /scheduler-threads=1, /scripts-dir=scripts/admin, /use-local-server=true, command/ALL=ADMIN, component-id=rest@localhost, def-hostname=localhost, admins=[Ljava.lang.String;@615fd9fd, scripts-dir=scripts/admin, max-queue-size=466, scheduler-threads=1, incoming-filters=tigase.server.filters.PacketCounter, outgoing-filters=tigase.server.filters.PacketCounter, api-keys=[Ljava.lang.String;@5be0a2fc, port=8080, context=/rest, context-file-path=etc/tigase-http-context.xml, use-local-server=true, rest-scripts-dir=scripts/rest}

In Component rest configuration log, the port property appears twice, that is /port=8088 and port=8080, the former is my configuration.

Not sure if you or Andrzej worked on the code. In any case, please take a look at it. I am not sure if we still want to maintain this code.

Artur Hefczyc wrote:

In any case, please take a look at it. I am not sure if we still want to maintain this code.

I've briefly looked at the code and have a couple of comments/questions:

• the primary key is over node/component/key_node/key_name which is ok but - do we want to have a single repo for all nodes or possibility to have configuration of different nodes stored in single place (given it's old and since then we've moved to cluster autodiscovery I would say that single configuration store could be beneficial with single config);

• given that we are moving to Tigase Kernel which should also probably include changes in how configuration is handled do we want to have this fixed? (%bmalkow , can you comment on the possible impact of Kernel on this?)

Wojciech Kapcia wrote:

Artur Hefczyc wrote:

In any case, please take a look at it. I am not sure if we still want to maintain this code.

I've briefly looked at the code and have a couple of comments/questions:

• the primary key is over node/component/key_node/key_name which is ok but - do we want to have a single repo for all nodes or possibility to have configuration of different nodes stored in single place (given it's old and since then we've moved to cluster autodiscovery I would say that single configuration store could be beneficial with single config);

That's a good question. I think, the best option would be to have some kind of system-wide configuration, which applies to all cluster nodes and which is the same for all nodes, and then, each cluster node could have some config options different. I do not want to have an identical copy of the whole configuration for each cluster node because it makes it difficult to make global changes to the config. Node specific configuration should only contain a few properties which are different from the global.

• given that we are moving to Tigase Kernel which should also probably include changes in how configuration is handled do we want to have this fixed? (%bmalkow , can you comment on the possible impact of Kernel on this?)

This is another good question. Bartek, please confirm but I think we really do not want to waste time on fixing this code if you will be working on a new config framework soon.