Sample call order:

 setProperties()::{presence-filter-enabled=false}
 setProperties()::{muc-lock-new-room=false}
 setProperties()::{history-db=memory}
 setProperties()::{message-filter-enabled=false}
 setProperties()::{presence-filter-enabled=false, muc-lock-new-room=false, history-db=memory, message-filter-enabled=false, component-id=chat@192.168.3.243, def-hostname=192.168.3.243, admins=[Ljava.lang.String;@7f60c4b0, scripts-dir=scripts/admin, command/ALL=ADMIN, max-queue-size=324, incoming-filters=tigase.server.filters.PacketCounter, outgoing-filters=tigase.server.filters.PacketCounter, ping-every-minute=false, hostnames=[Ljava.lang.String;@2a114025, muc-repo-class=derby, muc-repo-url=jdbc:derby:tigasedb, room-log-directory=./logs/, muc-allow-chat-states=false, shared-user-repo=tigase.db.UserRepositoryMDImpl@54a9387, shared-user-repo-params=null, shared-auth-repo=tigase.db.AuthRepositoryMDImpl@631b86c7, shared-auth-repo-params=null}

Bartosz, you are or you will be working on a new configuration API/framework so I am assigning this task to you. However, we won't be able to do it for 7.0 release anyway, so pushed back for next version.

Bartosz what is the status of this feature? If it is not completed yet within the new component framework but you still plan to do it, please provide work estimation.

It is integrated with Kernel-Based-TCF. WIll be merged with branch master later.

Do we really want to introduce this into 7.1.0? Maybe we should start working concurrently on version 7.2.0? I mean, we approach to closing version 7.1.0 as soon as possible but at the same time we continue on pushing all the new stuff to the version 7.2.0 and make it new official development version?

What do you think: %bmalkow , %wojtek , %andrzej.wojcik , %eric , %daniel

Two comments:

• we could utilize git-flow (v. https://projects.tigase.org/projects/tigase-server/wiki/Best_practices, especially graph, we have a slightly different naming convention as explained above image) and simply create release branch where we could work on the release, documentation and polishing of the features:

release - branch intended for the purpose of the release - frozen code to which only documentation and last-minute fixes can be commited.

This way it could allow us to continue with the regular development.

• alternatively, given that (at least to my understanding) this is a framework which can be included but not yet utilized across all component it could be merged and should not break anything - at the best only components based on TCF.

Of course it would be nice if the new TCF-Kernel-Config-etc has been documented (javadoc, asciidoc in the Developer Guide) before release/inclusion :)

(comment made private, not sure if we should discuss release related matters publicly)

Wojciech Kapcia wrote:

Two comments:

• we could utilize git-flow (v. https://projects.tigase.org/projects/tigase-server/wiki/Best_practices, especially graph, we have a slightly different naming convention as explained above image) and simply create release branch where we could work on the release, documentation and polishing of the features:

release - branch intended for the purpose of the release - frozen code to which only documentation and last-minute fixes can be commited.

This way it could allow us to continue with the regular development.

• alternatively, given that (at least to my understanding) this is a framework which can be included but not yet utilized across all component it could be merged and should not break anything - at the best only components based on TCF.

Of course it would be nice if the new TCF-Kernel-Config-etc has been documented (javadoc, asciidoc in the Developer Guide) before release/inclusion :)

(comment made private, not sure if we should discuss release related matters publicly)

I am keen on following or adopting workflow from other projects it that makes sense to us, so I have no objections in changing it, if it makes our life easier and also is easier to understand for people who use our code. And I guess adopting a workflow which is already publicly known makes it easier for our users to follow it.

I am worried about these 2 things:

1. We are delivering the server to at least 2 very important customers right now. And this is all based on the code 7.1.0 which has been already deployed. So I do not want to all of sudden introduce significant changes which may break their systems. %bmalkow what would be an impact of adding this new framework code to our version NP or Verizon? Do they use any of the components which would be affected? I guess main component which we have to consider is PubSub.

2. On the other hand I do not want to delay adding this new code to our public release. I want it as soon as possible because it adds a significant value to our feature set and I also want to start testing it ASAP.

I hope Kernel-based-TCF and converted components should works as current version. But I can't guarantee it.

Do not put such big changes to production code without tests, please!

I think we might want to push this to 7.2.0 and fully test it before release, we recently had a major issue (and will likely have more once we release 7.1.0) with the PubSub Schema changes, we should limit the number of major changes to code and operation to keep service interruption with our clients to a minimum.

Alternatively we could introduce it in a smaller 7.2.0 update and bump up the release schedule to publish it sooner.

Agreed. After Bartosz comments I am even more convinced that we should not put this new code into 7.1.0.

1. %wojtek , please make necessary changes as discussed to our workflow recommendations and git repository.

2. %bmalkow , please push the new code to 7.2.0 branch

Let's make the 7.2.0 our official development branch and 7.1.0 release branch or whatever we call it.

I will walk through all the 7.1.0 open tickets and review them once again to make sure we can finally close 7.1.0 version.

Artur Hefczyc wrote:

Agreed. After Bartosz comments I am even more convinced that we should not put this new code into 7.1.0.

%wojtek , please make necessary changes as discussed to our workflow recommendations and git repository.

%bmalkow , please push the new code to 7.2.0 branch

Let's make the 7.2.0 our official development branch and 7.1.0 release branch or whatever we call it.

I've create new branch release - in it only important fixes that should go into 7.1.0 release should be included. Regular development (i.e. Bartek's changes) goes into master as usual. When we perform the release we will do it in the release branch, then merge this branch to stable branch and back to master branch (at this point pom.xml in master branch will change as well, tho we could change the pom.xml as well in master to avoid confusion with the nightlies, but I'm not sure if that wouldn't cause conflicts when merging).

Ok, good, thank you Wojciech.

Bartek, in such a case, please merge all your recent new code and features, frameworks and APIs to the master branch, so we can start working on the new code and testing it.

I would like the code to be deployed to tigase.org and tigase.im as soon as possible.

Code of ligase-server is merged already.

What about tigase-muc and tigase-pubsub? Should %wojtek make similar branches there?

Appropriate branches created. Due to recent failed builds I've bumped tigase-server version in master to 7.2.0-SNAPSHOT (and on that version nightlies will be build), I've re-deployed from release branch latest 7.1.0-SNAPSHOT (so that version will match code that we will ship as final 7.1.0 - seems reasonable); Bartek is going to merge his changes to tigase-muc and tigase-pubsub in master branch with same premise - bumped versions with dependency on the server set to 7.2.0-SNAPSHOT and also versions of the components will be adjusted in tigase-server projects to include matching component versions in the distribution package.

Artur, one more comment - there was also potential issue with generating nightlies so I've modified the jenkins job so it will build nightly from both master and, if exists, release branch - this way it will be possible to have subsequent releases of currently-under-release version next to current regular development versions from master.

However there is still problem with javadocs of new code that would cause the build to fail, e.g.:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (attach-javadocs) on project tigase-server: MavenReportException: Error while creating archive:
[ERROR] Exit code: 1 - /var/lib/jenkins/jobs/private-TTS-tests-runner/workspace/tigase-server/src/main/java/tigase/component/exceptions/ComponentException.java:38: warning: no description for @param
…
[ERROR] /var/lib/jenkins/jobs/private-TTS-tests-runner/workspace/tigase-server/src/main/java/tigase/component/modules/AbstractModule.java:31: error: reference not found
[ERROR] * methods from {@link Module}, {@link ContextAware} and
[ERROR] ^
[ERROR] /var/lib/jenkins/jobs/private-TTS-tests-runner/workspace/tigase-server/src/main/java/tigase/component/modules/AbstractModule.java:32: error: reference not found
[ERROR] * {@link InitializingModule}.
[ERROR] ^
[ERROR] /var/lib/jenkins/jobs/private-TTS-tests-runner/workspace/tigase-server/src/main/java/tigase/component/modules/AbstractModule.java:36: error: @param name not found

Bartek, I guess the JavaDoc errors come from your code, please fix it, so we can get a clean build.

I've corrected javadocs on Friday, however there are still problems with two sets of automatic tests.

• enabling PubSub:

--comp-name-2=pubsub
--comp-class-2=tigase.pubsub.cluster.PubSubComponentClustered
pubsub/pubsub-strategy-class[S]=tigase.pubsub.cluster.ClusteredNodeStrategy

2015-10-12 04:56:24.133 [main]             ThreadExceptionHandler.uncaughtException()  SEVERE: Uncaught thread: "main" exception
java.lang.NoClassDefFoundError: tigase/component2/exceptions/ComponentException
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:2658)
        at java.lang.Class.getConstructor0(Class.java:2964)
        at java.lang.Class.newInstance(Class.java:403)
        at tigase.server.MessageRouterConfig.getMsgRcvInstance(MessageRouterConfig.java:419)
        at tigase.server.MessageRouter.setProperties(MessageRouter.java:687)
        at tigase.conf.ConfiguratorAbstract.setup(ConfiguratorAbstract.java:540)
        at tigase.conf.ConfiguratorAbstract.componentAdded(ConfiguratorAbstract.java:177)
        at tigase.conf.Configurator.componentAdded(Configurator.java:50)
        at tigase.conf.Configurator.componentAdded(Configurator.java:33)
        at tigase.server.AbstractComponentRegistrator.addComponent(AbstractComponentRegistrator.java:116)
        at tigase.server.MessageRouter.addRegistrator(MessageRouter.java:131)
        at tigase.server.MessageRouter.setConfig(MessageRouter.java:597)
        at tigase.server.XMPPServer.start(XMPPServer.java:142)
        at tigase.server.XMPPServer.main(XMPPServer.java:112)
Caused by: java.lang.ClassNotFoundException: tigase.component2.exceptions.ComponentException
        at java.net.URLClassLoader$1.run(URLClassLoader.java:372)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:2658)
        at java.lang.Class.getConstructor0(Class.java:2964)
        at java.lang.Class.newInstance(Class.java:403)
        at tigase.server.MessageRouterConfig.getMsgRcvInstance(MessageRouterConfig.java:419)
        at tigase.server.MessageRouter.setProperties(MessageRouter.java:687)
        at tigase.conf.ConfiguratorAbstract.setup(ConfiguratorAbstract.java:540)
        at tigase.conf.ConfiguratorAbstract.componentAdded(ConfiguratorAbstract.java:177)
        at tigase.conf.Configurator.componentAdded(Configurator.java:50)
        at tigase.conf.Configurator.componentAdded(Configurator.java:33)
        at tigase.server.AbstractComponentRegistrator.addComponent(AbstractComponentRegistrator.java:116)
        at tigase.server.MessageRouter.addRegistrator(MessageRouter.java:131)
        at tigase.server.MessageRouter.setConfig(MessageRouter.java:597)
        at tigase.server.XMPPServer.start(XMPPServer.java:142)
        at tigase.server.XMPPServer.main(XMPPServer.java:112)

Implementation-Build: 505/3c647feb (2015-10-12/00:53:40)
Implementation-Title: Tigase PubSub
Implementation-Version: 3.3.0-SNAPSHOT-b505/3c647feb

Then there is the case with one custom component (User Search) which uses TCF.

reported in #3611

What is progress of this?

Problems reported (in #3611) by Wojtek, ale fixed.

I implemented configuring each bean in Kernel by ad-hoc command or by init.properties file.

Unfortunatelly, I didn't changed a way in what Tigase server properties. I think it should be done during migrating to Kernel.

Ok, so it goes to version 7.2.0.