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 <gal...@redhat.com> 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
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
