myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Lucy (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Updated] (MYFACES-4044) Flow ID Ambiguity Is Not Handled Well
Date Mon, 25 Apr 2016 21:00:15 GMT

     [ https://issues.apache.org/jira/browse/MYFACES-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bill Lucy updated MYFACES-4044:
-------------------------------
       Resolution: Fixed
         Assignee: Bill Lucy
    Fix Version/s: 2.2.10
           Status: Resolved  (was: Patch Available)

> Flow ID Ambiguity Is Not Handled Well
> -------------------------------------
>
>                 Key: MYFACES-4044
>                 URL: https://issues.apache.org/jira/browse/MYFACES-4044
>             Project: MyFaces Core
>          Issue Type: Improvement
>    Affects Versions: 2.2.9
>            Reporter: Bill Lucy
>            Assignee: Bill Lucy
>             Fix For: 2.2.10
>
>         Attachments: MYFACES-4044.patch
>
>
> 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."}}
> I think that MyFaces should emit some kind of similar warning/error in the given scenario.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message