Xsite configuration is one of the things that will change after 5.2, so
we should add a comment to the config file, saying that this may change
in the future.
I hope that we'll come up with how the final version will look like at
our Palma meeting, where we'll have a breakout session on xsite config
(e.g. reducing 4 XML files to 1).
On 10/18/12 3:11 PM, Tristan Tarrant wrote:
Hi all,
sorry for this being a bit late (but since it is before CR1 it is not
that late :), but the XSite config looks a bit redundant and we should
improve it a bit before release
|<||global||>|
|||...|
|||<||sites| |local||=||"LON"||/>|
|||...|
|</||global||>|
Since this just provides the local logical name for this site I would
instead use
|<||global||>|
|||...|
|||<||site| |name||||=||"LON"||/>|
|||...|
|</||global||>|
In the cache declaration we have the following:
| <||sites||>|
|||<||backups| |backupSites||=||"NYC,SFO"||>|
|||<||backup| |site||=||"NYC"| |backupFailurePolicy||=||"WARN"|
|strategy||=||"SYNC"| |timeout||=||"12000"||/>|
|||<||backup| |site||=||"SFO"| |backupFailurePolicy||=||"IGNORE"|
|strategy||=||"ASYNC"||/>|
|||<||backup| |site||=||"LON"| |strategy||=||"SYNC"||/>|
|||</||backups||>|
|||</||sites||>|
Instead of dumping a list inside an XML attribute (backupSites), can't
we just skip that attribute and add an enabled attribute to each backup
element ? Also the "backup" prefix to the failure policy is redundant
and can be dropped altogether.
Also, while I understand the rationale behind giving a "home element" to
all xsite-related configurations (<sites>), I do feel it is unnecessary,
so I suggest:
|||<||backups||||>|
|||<||backup| |site||=||"NYC"| |failurePolicy||=||"WARN"|
|strategy||=||"SYNC"|
|timeout||=||"12000"||enabled="true"/>|
|||<||backup| |site||=||"SFO"| |failurePolicy||=||"IGNORE"|
|strategy||=||"ASYNC"||enabled="true"/>|
|||<||backup| |site||=||"LON"|
|strategy||=||"SYNC"||enabled="false"/>|
|||</||backups||>|
This means that <backupFor/> also moves as a direct child element of a
cache declaration.
Just my 2ยข
Tristan
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban, JGroups lead (
http://www.jgroups.org)