wojciech.kapcia@tigase.net opened 8 years ago
|
|
Feature implemented as a new task install-schema. I've reused code from |
|
I think that it should handle following cases:
Problems summary:
DetailsCurrently it doesn't seem to work intuitively/following available information:
Currently it seems it's impossible to specify where you wan't to install the schema - it seems to always use the defaults. Previously you could specify where you wan't to install the schema:
|
|
Scratch that... a bit. OK, it's possible to specify all parameters but one has to use It could be also helpful to allow specifying the parameter list as well as giving information what those parameters are. Previous 3 points still applies as suggestions. |
|
Would be nice - proper list of parameters in the log:
|
|
I've improved an output of I still need to fix the output of parameters. |
|
Fixed presentation of parameters passed to SchemaLoader |
|
I've tried basic form (with supposed detection of the parameters from config file?) and with following in @etc/init.properties@:
|
|
What's more, "components" parameter is way off:
|
|
This is the same as a component list which is used by setup. I cannot guess which components have their own schema, I need to generate config with them and then check if any of loaded classes implements data source aware interface. In fact, you should pass all components which you expect to use, not only components for which you want to load schema, as a user is not aware which components have their own schema. A user should pass components which he needs and we should take care of the rest. Suggested config is OK. It applied all thing you asked it for. You wanted PubSub and MUC (which are enabled by default - skipped in config), and you have not specified that you want c2s,bosh,ws2s - as a result, those components are disabled in a config. I think that you expected this task to install schema for particular components and that's it, while it is more powerful and could be used almost as a replacement for a web based setup. In my opinion, this task works ok but should be properly described in the documentation. |
|
OK, there is a (now correctly, we discussed it previously but it slipped my mind) detailed description of the tasks:
Hence only first/third option detects configuration, and Andrzej Wójcik wrote:
The task is called
which informs, that schema will be loaded for the listed components. In addition users tends to avoid details and when faced with "Example init.properties configuration file:" they will use it resulting in confusion when server fails to operates correctly. I would say, that it would make more sense (while running from console), in case of using
At any rate, it doesn't seem to work for me:
|
|
Changes to be made:
Now if you will pass names of components, then only this components will be loaded. Instead, we should use a list of changes, ie.
To do:
|
|
I've modified behavior of |
|
The problem stems from the bad parsing of the elements and considering "-muc,-pubsbu" as next parameter instead of value. Following (different format) works:
|
|
Fixed parameters parsing issue |
|
Works good now. |
Type |
New Feature
|
Priority |
Normal
|
Assignee | |
RedmineID |
5484
|
Version |
tigase-server-8.0.0
|
Spent time |
67h 30m
|
This is a follow-up to #4941#note-23 - in addition to upgrade-schema and setting-up schema via web-up we need a way to setup schema from commandline (like DBSchemaLoader was doing) - you could probably could re-use existing, recent commandline parser