In properties configuration format each line contained key and value with optional definition of type of stored value:
c2s/ports[i]=5222,5223
where c2s/ports was name of property, [i] defined that type of value is array of integers, and 5222,5223 was comma separated list of values.
This format worked but in fact c2s/ports was not name of property you configured but key which was later split on / char to parts which defined by names path to property which name was in last part.
From that you can see that it was domain based setting of properties.
Except from this multi-part keys we also used properties starting with -- which were global properties accessible for every part of application, i.e.: to add new component and set some properties
you needed to write:
--comp-name-1=pubsub --comp-class-1=tigase.pubsub.PubSubComponent pubsub/test[B]=true pubsub/pubsub-repo-url="jdbc:XXXX:XXXX/db_name"
This lead to mistakes like duplicated definition of name and class for same number of component or redefined property value in other place of a configuration file - especially in cases where configuration was big.
In this configuration structure it was hard to tell where is configuration for particular component or what databases this installation uses. This could be defined all over the file.
In this release we are introducing Tigase Kernel Framework, which allows to configure beans in configuration file and even define usage of new beans loaded from external jars which can modify behavior of Tigase components. This would make configuration file even more complex, difficult and less readable.
