--- On Wed, 3/3/10, Paul Mossman <[email protected]> wrote: > > Since I've seen some issues raised due to replication > trigger > > and some fixes that broke other replication > functionality - > > Yes, I've noticed that this has been a problem area. > > > > A first step in this direction could be documenting > > sipXconfig replication trigger mechanism that we > already have > > in place (useful even without considering the event > engine approach) > > Agreed, can you raise a Task JIRA? It would be great > to have these > triggers captured.
I've raised http://track.sipfoundry.org/browse/XX-7834 to track this. > > As for what to implement... There have been some > discussions about how > to generalize replication. One goal would be to > eliminate the need to > trigger service restarts at all, but that's a long way > off. > > Anything done for the interim would need to be clearly > worth the effort > and risk. What kinds of effort would this be? > Quite risky for 4.2 ... A good point to start is to try to move all the replication logic across config code inside ReplicationTrigger (and to make all of them event driven - both dao & application events). Next step would be to create a declarative approach for this logic - if someone wants to add new replication logic to be able to do this by adding a rule in an xml file (or reusing an existing one). Such rule could be (at a first thought): <rule> <name>activateNatTraversal</name> <entity> <class>org.sipfoundry.sipxconfig.admin.commserver.Location</class> </entity> <onSave> <replicate>sipxRelayService</replicate> <restart>sipxProxyService, sipxBridgeService</restart> </onSave> </rule> Then if we plan to remove service restart we will only have to edit this file. George _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
