[prev in list] [next in list] [prev in thread] [next in thread] 

List:       myfaces-dev
Subject:    Re: Flow ID Ambiguity
From:       Leonardo Uribe <lu4242 () gmail ! com>
Date:       2016-04-23 21:38:05
Message-ID: CABujnVcDkvCavDf7x_-fjHsZjdKwqrKhBcoo4Yx+hL-vDwJ3uA () mail ! gmail ! com
[Download RAW message or body]

Hi

It is a good idea to add a warning/error in that case. Please create an
issue in the issue tracker, so we can include the suggestion.

regards,

Leonardo

2016-04-22 13:14 GMT-05:00 Bill Lucy <wtlucy@gmail.com>:

> I've run in to an interesting scenario with the flow handling logic.  If
> we have multiple flows with the same IDs and definingDocumentIds, we won't
> behave as expected: only one flow will actually be used, but no error or
> warning to that effect is emitted.
>
> Consider if we have two apps in the same EAR, each defining flows with an
> ID of "sample-flow", like this:
>
>         final String flowId = "sample-flow";
>         flowBuilder.id("", flowId);
>
> Per the JSF spec, this creates ambiguity:
>
> 11.4.3.1
> Defining Flows
> Flows are defined using the <flow-definition> element. This element must
> have an id attribute which uniquely
> identifies the flow within the scope of the Application Configuration
> Resource file in which the element appears. To
> enable multiple flows with the same id to exist in an application, the
> <faces-config><name> element is taken to
> be the definingDocumentId of the flow. If no <name> element is specified,
> the empty string is taken as the value
> for definingDocumentId.
>
> In this case, app1 might define some kind of initializer with the flow,
> while app2 doesn't.  In that case, app2 might (incorrectly) end up trying
> to use an initializer that was intended for app1.  A developer might see
> issues resulting from the initializer being called from the wrong app, but
> it wouldn't be clear that the wrong flow had been entered (due to
> ambiguity).
>
> Mojarra has something like this:
>
> Caused by: java.lang.IllegalStateException: Flow with id \"sample-flow\"
> and definingDocumentId \"\" already exists."}}
>
> Would it be helpful for us to emit some kind of similar warning/error in
> this case?  Or do we want to keep the current behavior?
>
> Thanks,
> Bill Lucy
>

[Attachment #3 (text/html)]

<div dir="ltr"><div><div><div>Hi<br><br></div>It is a good idea to add a \
warning/error in that case. Please create an issue in the issue tracker, so we can \
include the suggestion.<br><br></div>regards,<br><br></div>Leonardo<br></div><div \
class="gmail_extra"><br><div class="gmail_quote">2016-04-22 13:14 GMT-05:00 Bill Lucy \
<span dir="ltr">&lt;<a href="mailto:wtlucy@gmail.com" \
target="_blank">wtlucy@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
dir="ltr"><div><div>I&#39;ve run in to an interesting scenario with the flow handling \
logic.   If we have multiple flows with the same IDs and definingDocumentIds, we \
won&#39;t behave as expected: only one flow will actually be used, but no error or \
warning to that effect is emitted.<br><br>Consider if we have two apps in the same \
EAR, each defining flows with an ID of &quot;sample-flow&quot;, like this:<br><br>    \
final String flowId = &quot;sample-flow&quot;;<br>               \
flowBuilder.id(&quot;&quot;, flowId);<br><br>Per the JSF spec, this creates \
ambiguity:<br><br>11.4.3.1<br>Defining Flows<br>Flows are defined using the \
&lt;flow-definition&gt; element. This element must have an id attribute which \
uniquely<br>identifies the flow within the scope of the Application Configuration \
Resource file in which the element appears. To<br>enable multiple flows with the same \
id to exist in an application, the &lt;faces-config&gt;&lt;name&gt; element is taken \
to<br>be the definingDocumentId of the flow. If no &lt;name&gt; element is specified, \
the empty string is taken as the value<br>for definingDocumentId.<br><br>In this \
case, app1 might define some kind of initializer with the flow, while app2 \
doesn&#39;t.   In that case, app2 might (incorrectly) end up trying to use an \
initializer that was intended for app1.   A developer might see issues resulting from \
the initializer being called from the wrong app, but it wouldn&#39;t be clear that \
the wrong flow had been entered (due to ambiguity).<br><br>Mojarra has something like \
this:<br><br>Caused by: java.lang.IllegalStateException: Flow with id \
\&quot;sample-flow\&quot; and definingDocumentId \&quot;\&quot; already \
exists.&quot;}}<br><br>Would it be helpful for us to emit some kind of similar \
warning/error in this case?   Or do we want to keep the current \
behavior?<br><br></div>Thanks,<br></div>Bill Lucy<br></div> \
</blockquote></div><br></div>



[prev in list] [next in list] [prev in thread] [next in thread]