Hey Paul, Re: https://issues.jboss.org/browse/ISPN-7326 I have some doubts how to achieve what I'm trying to do in ^ More specifically, backup's 'site' attribute and remote-site's name attributes are special in the sense that they're not represented as SimpleAttributeDefinition instances. Instead, it seems like they're expected to be fully resolved when the XML read since they are part of path addresses. Resolution when XML is read does not work since reading is done by the host controller and I'd want the resolution to happen when the particular server node starts up. So, what would be the best way to achieve what I'm after? One way I was thinking is maybe leaving the XML reading part as is, and only when the cache is added, do the resolution manually there. However, this does not seem to work as is, because the XML attribute is already resolved when I add the cache and it's resolved to the default value (cos process controller was not started with -D...), so I can't seem to get the original XML value. Moreover, even if this was resolved, would it be fine for the path address to have the default value for the property in it, and the actual cache configured with the name passed via system property? Doesn't sound right... Any other way? Maybe add separate SimpleAttributeDefinition instances for these XML attributes on top of their path address values? Cheers, -- Galder Zamarreño Infinispan, Red Hat

Hey Paul, Thanks for the quick answer. The motivation for ISPN-7326 is to reduce domain configuration needed to test xsite replication in the Javascript client. Without ISPN-7326 I'm having to duplicate profiles for each site where the changing values are minimal. It would be helpful to control the values I mentioned via system property to reduce the number of profiles required in the domain config. The reason I'm interested in reducing the number of changes I make the default domain config (e.g. by reducing number of profiles) is to make it easier in the future to migrate to newer domain configurations. To be more precise, domain.xml in [1] contains 3 clustered profiles: 'clustered', 'earth' and 'moon'. This makes the configuration for testing clustered and xsite capabilities quite verbose. Ideally, I'd like to have 1 clustered profile, 'clustered', and using system properties select which transport to use and provide optional site names...etc where needed. So indeed, the motivation for this is not a real environment.

Your sugggestion for 2. doesn't sound too bad. Note that a similar approach would be required for remote-site's name.

Thoughts? [1] https://github.com/galderz/js-client/blob/16c985e0957c10f332c0dc9b561997c... -- Galder Zamarreño Infinispan, Red Hat > On 9 Jan 2017, at 17:47, Paul Ferraro <paul.ferraro(a)redhat.com&gt; wrote: > > Hi Galder, > > The short answer: Attributes that are components of a resource path > address may not contain expressions. > > What is the motivation behind ISPN-7326? > > When the x-site domain model for Infinispan was originally designed, > the assumption was that a domain controller would never attempt to > manage a host residing in a remote data center. Typically a domain > controller doesn't manage hosts outside of its own network. Even an > architecture that uses multiple logical sites within the same physical > data center would still isolate each site to a separate network. > > Question aside, there are at least 2 ways we can do this: > > 1. Refactor the model. Remove the backup resource entirely. This > means that individual site configurations will no longer be > addressable. Instead, the parent resource would maintain a list of > backup objects, where "site" becomes a normal attribute that allows > expressions. > > Dealing with complex object types in the model isn't exactly a > pleasurable experience, so I would first make sure that the > requirement is legitimate/realistic and thus warrants the change. Of > course, the biggest headache will be the model transformations > required to support mixed domains (mixed domains are a reality of > upgrading), as well as translation of domain operations that reference > the legacy resources. > > 2. Decouple the logical backup name from the actual site name: > > <backups> > <backup name="remote" site="${...}" strategy="SYNC"/> > </backups> > > Here, each host has an addressable "remote" backup resource, where the > site name is an expression and resolves to a host-specific value. > Additionally, we can make this site attribute optional, and have it > default to the backup name if undefined. > > In conclusion, if this is confirmed to be a genuine feature request, I > would strongly encourage you to go with option #2. > > Paul > > On Mon, Jan 9, 2017 at 8:49 AM, Galder Zamarreño <galder(a)redhat.com&gt; wrote: >> Hey Paul, >> >> Re: https://issues.jboss.org/browse/ISPN-7326 >> >> I have some doubts how to achieve what I'm trying to do in ^ >> >> More specifically, backup's 'site' attribute and remote-site's name attributes are special in the sense that they're not represented as SimpleAttributeDefinition instances. Instead, it seems like they're expected to be fully resolved when the XML read since they are part of path addresses. >> >> Resolution when XML is read does not work since reading is done by the host controller and I'd want the resolution to happen when the particular server node starts up. >> >> So, what would be the best way to achieve what I'm after? >> >> One way I was thinking is maybe leaving the XML reading part as is, and only when the cache is added, do the resolution manually there. However, this does not seem to work as is, because the XML attribute is already resolved when I add the cache and it's resolved to the default value (cos process controller was not started with -D...), so I can't seem to get the original XML value. Moreover, even if this was resolved, would it be fine for the path address to have the default value for the property in it, and the actual cache configured with the name passed via system property? Doesn't sound right... >> >> Any other way? Maybe add separate SimpleAttributeDefinition instances for these XML attributes on top of their path address values? >> >> Cheers, >> -- >> Galder Zamarreño >> Infinispan, Red Hat >>