I disagree that we should fallback to any default repository implementation as we already have setup mode to start Tigase XMPP Server setup without any data source.

Adjustments to XMLRepository or DummyRepository to be able to use them for some basic tests makes sense and I adjusted XMLRepository to use newly created XMLDataSource (wrapper around XMLDB).

However main issue with usage of XMLRepository was fact that there was not implementation of MsgRepository which supported XMLRepository as a data source. I've fixed this by creation of XMLMsgReposiotry which is very simple repository which should work fine in basic usages. I've skipped implementation of MsgBroadcastRepository for XMLRepository as it is not used very often and server starts without it (only warning is generated).

But this leads to a conclusion that we need implementations of PubSubDAO@, @MessageArchiveRepository@, @MucDAO and HistoryProvider for XMLRepository if we want server to start with PubSub, MUC and Message Archive enabled (which are now enabled by default). This may require significant amount of work to implement those reposiotry interfaces for @XMLDataSource@.

Do we need this implementations? or we accept that for basic tests with XMLRepository PubSub, MUC and MA must be disabled?

To be honest I do not see much value on spending a lot of time on XMLRepository development. We should run tests over Tigase server with a real DB anyway. XMLRepository support should be really minimal what is absolutely necessary.

Maybe a better option would be to focus on Derby or similar support.

Andrzej Wójcik wrote:

Do we need this implementations? or we accept that for basic tests with XMLRepository PubSub, MUC and MA must be disabled?

I think that basic support for ad-hoc tests is enough.

Artur Hefczyc wrote:

To be honest I do not see much value on spending a lot of time on XMLRepository development. We should run tests over Tigase server with a real DB anyway. XMLRepository support should be really minimal what is absolutely necessary.

While it's true, it's kinda required for some parts of the code to have working repository and this is very handy for a unit tests (for which setting up separate database may be a hassle and it speeds up making changes without braking things); all in all this basic XMLRepository implementation is definitely handy.

Maybe a better option would be to focus on Derby or similar support.

On that note - we need Derby only for... "single machine simple deployment to show that Tigase is working" (i.e. someone wants to install it and check if/how it works). And Derby is slightly "challenging" to maintain (mostly by enforcing SP within Java code as well as difficult updates). Maybe for that end we should adopt hsqldb which while similar in principles to Apache Derby offers support for SQL user-defined stored procedures and functions so it would be more in line with other database hence less overhead to make support for Derby working.

Wojciech Kapcia wrote:

Artur Hefczyc wrote:

To be honest I do not see much value on spending a lot of time on XMLRepository development. We should run tests over Tigase server with a real DB anyway. XMLRepository support should be really minimal what is absolutely necessary.

While it's true, it's kinda required for some parts of the code to have working repository and this is very handy for a unit tests (for which setting up separate database may be a hassle and it speeds up making changes without braking things); all in all this basic XMLRepository implementation is definitely handy.

Indeed, I am only worried about 2 things:

1. Partially working repository is not good. I can see lots of potential problems coming from the fact that XMLRepository works sometimes and does not work in other cases. At least, it would be good have a mechanism which clearly shows an error with description that XMLRepository is the source of a problem.

2. Long-term maintenance might be expensive. Do we need a special support for each component, each new code? How do we maintain it in the future? I am afraid it might cost us a lot of time in the future to maintain it and keep up with code changes in other parts of our software.

Maybe a better option would be to focus on Derby or similar support.

On that note - we need Derby only for... "single machine simple deployment to show that Tigase is working" (i.e. someone wants to install it and check if/how it works). And Derby is slightly "challenging" to maintain (mostly by enforcing SP within Java code as well as difficult updates). Maybe for that end we should adopt hsqldb which while similar in principles to Apache Derby offers support for SQL user-defined stored procedures and functions so it would be more in line with other database hence less overhead to make support for Derby working.

I know about Derby issues. This is why I wrote "or similar". It would be good to have some, very simple and lightweight SQL database which could replace XMLRepository but it would not require that much effort to maintain.

Artur Hefczyc wrote:

Wojciech Kapcia wrote:

Artur Hefczyc wrote:

To be honest I do not see much value on spending a lot of time on XMLRepository development. We should run tests over Tigase server with a real DB anyway. XMLRepository support should be really minimal what is absolutely necessary.

While it's true, it's kinda required for some parts of the code to have working repository and this is very handy for a unit tests (for which setting up separate database may be a hassle and it speeds up making changes without braking things); all in all this basic XMLRepository implementation is definitely handy.

Indeed, I am only worried about 2 things:

Partially working repository is not good. I can see lots of potential problems coming from the fact that XMLRepository works sometimes and does not work in other cases. At least, it would be good have a mechanism which clearly shows an error with description that XMLRepository is the source of a problem.

IMHO this is mostly for the unit-test purposes so whoever is writing tests (and thus utilising it) will be aware of the risk.

Long-term maintenance might be expensive. Do we need a special support for each component, each new code? How do we maintain it in the future? I am afraid it might cost us a lot of time in the future to maintain it and keep up with code changes in other parts of our software.

Bringing it up-to-speed with data-source was 2,5h (and it was needed only due to data-source introduction). Dealing with Derby weird issues (vide current problems) takes waaaay more time…

Maybe a better option would be to focus on Derby or similar support.

On that note - we need Derby only for... "single machine simple deployment to show that Tigase is working" (i.e. someone wants to install it and check if/how it works). And Derby is slightly "challenging" to maintain (mostly by enforcing SP within Java code as well as difficult updates). Maybe for that end we should adopt hsqldb which while similar in principles to Apache Derby offers support for SQL user-defined stored procedures and functions so it would be more in line with other database hence less overhead to make support for Derby working.

I know about Derby issues. This is why I wrote "or similar". It would be good to have some, very simple and lightweight SQL database which could replace XMLRepository but it would not require that much effort to maintain.

Possibly mentioned hsqldb could be such solution - it offers standard SP hence possibly less problematic support.

Should we close this issue (as it's done) and create new one to investigate replacement of Derby with hsqldb?

Your explanations Wojciech make sense and I agree with them. I am closing the ticket.