<div dir="ltr"><div>Hi Martin,</div><div><br></div>thanks for the list. Right, some of those suffer from the same problem and some seem to have an identity (not explicitly expressed since we don&#39;t have a way to do that for a member of a complex type yet but once we do it won&#39;t be a problem).<br><div class="gmail_extra"><br></div><div class="gmail_extra">Ok, I had a hope we were going to address these relatively quick (given that the issue was raised back in autumn). I don&#39;t see it happening next month neither. So for now I am going to handle these kind of config structures (i.e. lists of complex types) as atomic pieces (although potentially big). They won&#39;t be mergeable during updates but one will be replacing completely the other with the one coming in last winning.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In perspective though, I think this is going to remain a critical issue.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra">Alexey</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 26, 2018 at 2:40 PM, Martin Choma <span dir="ltr">&lt;<a href="mailto:mchoma@redhat.com" target="_blank">mchoma@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I run through Elytron subsystem and there are other &quot;suspicious&quot;<br>
resources [1]. How it is guaranteed name/id/path attributes of<br>
collections are unique identifiers? On subsystem code level? Because<br>
this information is not in the model, as far as I know.<br>
<br>
Is it possible to declare compound unique-key? I mean for example to<br>
say that for permission resource (class-name,module) tuple is unique<br>
key.<br>
<br>
[1]<br>
configurable-sasl-server-facto<wbr>ry/filters<br>
configurable-http-server-mecha<wbr>nism-factory/filters<br>
<br>
sasl-authentication-factory/me<wbr>chanism-configurations<br>
sasl-authentication-factory/me<wbr>chanism-configurations/mechani<wbr>sm-realm-configurations<br>
http-authentication-factory/me<wbr>chanism-configurations<br>
http-authentication-factory/me<wbr>chanism-configurations/mechani<wbr>sm-realm-configurations<br>
<br>
mechanism-provider-filtering-s<wbr>asl-server-factory/filters<br>
<br>
ldap-realm/identity-mapping/at<wbr>tribute-mapping<br>
jdbc-realm/principal-query<br>
jdbc-realm/principal-query/att<wbr>ribute-mapping<br>
<br>
security-domain/realms<br>
<div class="m_1576853629476600739HOEnZb"><div class="m_1576853629476600739h5"><br>
On Fri, Mar 23, 2018 at 4:55 PM, Alexey Loubyansky<br>
&lt;<a href="mailto:alexey.loubyansky@redhat.com" target="_blank">alexey.loubyansky@redhat.com</a>&gt; wrote:<br>
&gt; While this is addressed mainly to the Elytron team, it seems like we would<br>
&gt; appreciate opinions from other colleagues since we are basically stuck<br>
&gt; discussing possible ways to resolve<br>
&gt; <a href="https://issues.jboss.org/browse/WFCORE-3596" rel="noreferrer" target="_blank">https://issues.jboss.org/brows<wbr>e/WFCORE-3596</a><br>
&gt;<br>
&gt; The description in the jira is pretty brief assuming people know what that<br>
&gt; is about, since it&#39;s been raised before multiple times. Here is what it is<br>
&gt; about fundamentally.<br>
&gt;<br>
&gt; If a configuration model (of a subsystem or any other component) includes a<br>
&gt; list of configurable units (let&#39;s assume XML elements for simplicity) that<br>
&gt; don&#39;t have any identity (unique id/name/path/etc) this is a big problem for<br>
&gt; supporting patching and version updates preserving user configuration<br>
&gt; changes. Or simply customizing the default config model using a tool. By a<br>
&gt; big problem I mean it&#39;s simply not going to work reliably.<br>
&gt;<br>
&gt; As a simple exercise that demonstrates the issue, imagine you have two<br>
&gt; configs each of which includes a list of these configurable units that have<br>
&gt; no identity. Now try to identify the difference between the two lists. Or<br>
&gt; merge them with one overwriting the other. Basically components w/o an<br>
&gt; identity can not be manipulated. You can only add them but not modify or<br>
&gt; even remove (unless their index in the list is a constant value of course).<br>
&gt;<br>
&gt; I don&#39;t think I&#39;ve seen any issue of this kind in our (WF/EAP) configs<br>
&gt; except for the Elytron&#39;s permission-mapping&#39;s. (If somebody knows such<br>
&gt; components please let me know).<br>
&gt; If I misunderstand the Elytron config model or approaching this from a wrong<br>
&gt; angle, please let me know.<br>
&gt;<br>
&gt; Question for the Elytron team: is the problem I am describing clear? Do you<br>
&gt; admit it as a problem?<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Alexey<br>
&gt;<br>
</div></div><div class="m_1576853629476600739HOEnZb"><div class="m_1576853629476600739h5">&gt; ______________________________<wbr>_________________<br>
&gt; wildfly-dev mailing list<br>
&gt; <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div></div>