Re: [infinispan-dev] Property substitution for attributes that are part of paths - ISPN-7326

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 >