You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Bernd Bohmann (JIRA)" <de...@myfaces.apache.org> on 2009/04/07 20:42:12 UTC
[jira] Created: (ORCHESTRA-40) A transaction token component
inspired by the struts transaction processor
A transaction token component inspired by the struts transaction processor
--------------------------------------------------------------------------
Key: ORCHESTRA-40
URL: https://issues.apache.org/jira/browse/ORCHESTRA-40
Project: MyFaces Orchestra
Issue Type: New Feature
Components: Conversation
Affects Versions: 1.3.1
Reporter: Bernd Bohmann
A transactionToken Component for orchestra inspired by the struts transaction processor.
The transaction token is to be used for enforcing a single request for a particular transaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component
inspired by the struts transaction processor
Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763785#action_12763785 ]
Martin Marinschek commented on ORCHESTRA-40:
--------------------------------------------
Ok, so there was a lot of action here, but not really a lot of discussion.
Let's discuss about the base first: Bernd's (and by the way also Manfred's and mine) point of view is that a JSF application should have a way to be informed of back-button clicks, forward-button clicks, refreshes, double-submits, etc.
As I see it, an interface implemented by the application should provide a hook which needs to be called in such cases.
Now for me this is highly conversation-context (=tab or window) related: a back-button is always clicked within a tab or window. If you want to indicate to the user that the back-button has been pressed you will need to store a list of tokens (one per request) and again, I think that should be stored per conversation-context (not in the session).
If it is not for this, Orchestra should provide ways to handle these problems cause a solution is desperately needed in the JSF space. AFAIK, only Spring Webflow provides something out of the box, and with Spring Webflow you are moving pretty far off the JSF standard, both from a configuration perspective and a usage perspective (however, I am not saying that Spring Webflow is bad - it is indeed a very good framework - just not very close to JSF if you take a deeper look at it).
regards,
Martin
> A transaction token component inspired by the struts transaction processor
> --------------------------------------------------------------------------
>
> Key: ORCHESTRA-40
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-40
> Project: MyFaces Orchestra
> Issue Type: New Feature
> Components: Conversation
> Affects Versions: 1.3.1
> Reporter: Bernd Bohmann
> Assignee: Simon Kitching
> Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch
>
>
> A transactionToken Component for orchestra inspired by the struts transaction processor.
> The transaction token is to be used for enforcing a single request for a particular transaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component
inspired by the struts transaction processor
Posted by "Bernd Bohmann (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705462#action_12705462 ]
Bernd Bohmann commented on ORCHESTRA-40:
----------------------------------------
Maybe this can be included as a different artifact for orchestra?
> A transaction token component inspired by the struts transaction processor
> --------------------------------------------------------------------------
>
> Key: ORCHESTRA-40
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-40
> Project: MyFaces Orchestra
> Issue Type: New Feature
> Components: Conversation
> Affects Versions: 1.3.1
> Reporter: Bernd Bohmann
> Assignee: Simon Kitching
> Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch
>
>
> A transactionToken Component for orchestra inspired by the struts transaction processor.
> The transaction token is to be used for enforcing a single request for a particular transaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component
inspired by the struts transaction processor
Posted by "Manfred Geiler (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705595#action_12705595 ]
Manfred Geiler commented on ORCHESTRA-40:
-----------------------------------------
MANAGED_BEAN_NAME = "org.apache.myfaces.orchestra.TransactionToken"
is suboptimal because dots are (officially) not allowed within a managed bean name.
Only underscores, letters and digits are allowed according to jsf spec.
> A transaction token component inspired by the struts transaction processor
> --------------------------------------------------------------------------
>
> Key: ORCHESTRA-40
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-40
> Project: MyFaces Orchestra
> Issue Type: New Feature
> Components: Conversation
> Affects Versions: 1.3.1
> Reporter: Bernd Bohmann
> Assignee: Simon Kitching
> Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch
>
>
> A transactionToken Component for orchestra inspired by the struts transaction processor.
> The transaction token is to be used for enforcing a single request for a particular transaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component
inspired by the struts transaction processor
Posted by "Mario Ivankovits (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763854#action_12763854 ]
Mario Ivankovits commented on ORCHESTRA-40:
-------------------------------------------
I think we all agree, having a decent handling for this thing is a long missing feature here in JSF land.
I also agree that it is much more a virulent problem when you use a conversation framework as it is much likely that you run into problems with the database else.
The question is if we need it strongly integrated into Orchestra. I've looked at the patch, and beside that something gets stored into the conversationContext I can not see anything which can not be solved using normal JSF phase listeners.
And for storing into the conversationContext we can create a scope which does this (instead of accessing it directly). You also gain the ability to decide on which level the tokens are kept.
If you do not use Orchestra you simply can the manager bean into the session then.
I'd say this component qualifies for its own project, e.g. within our ext (sorry, lost the name) project. On the other hand, I understand that - compared to seam and webflow - people await such functionality from Orchestra too.
If we add this to Orchestra, I'd like to see it in a separated module, e.g. orchestra-jsfext. Would this be feasible?
As for the technical aspect of this patch, I have some notes:
1) Does this solution work with ajax, or will an ajax request trigger a DOUBLE_SUBMIT_OR_RELOAD_TYPE notification? I think ajax detection needs to be added, at least to detect JSF 2.0 alike ajax requests.
2) I see you store the token in the request parameter. Probably - in the context of ajax - storing it as attribute on the UIViewRoot might be better.
If you have to deal with ajax requests you are able to update this value then with the new token.
I am also constantly thinking about moving the conversationContext paramter into the UIViewRoot - but this is another story.
3) We should also add a default TransactionTokenListener which behaves in a way we think an application should react on these events.People than can use it to jump start the system. Probably something like MyTransactionTokenListener with a faces message added so the user will get some feedback.
4) I'd like to have a way to "ignore" some requests. E.g. if you issue an jsf action which will just stream a PDF to the user (without page change), the browser stay on the page, but the token has been "used" then.
The current token needs to be added to the list of used tokens at the end of the request then. Probably an API like TransactionTokenManager.getInstance().ignoreRequest() suppress this addittion then for the current request. The token can then be used again.
Also trinidad has at least two components which open a window and just report the value back to the main window.
Probably we also need a way to ignore requests based on an URL pattern to deal with that?
Ciao,
Mario
> A transaction token component inspired by the struts transaction processor
> --------------------------------------------------------------------------
>
> Key: ORCHESTRA-40
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-40
> Project: MyFaces Orchestra
> Issue Type: New Feature
> Components: Conversation
> Affects Versions: 1.3.1
> Reporter: Bernd Bohmann
> Assignee: Simon Kitching
> Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch
>
>
> A transactionToken Component for orchestra inspired by the struts transaction processor.
> The transaction token is to be used for enforcing a single request for a particular transaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component
inspired by the struts transaction processor
Posted by "Martin Marinschek (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763940#action_12763940 ]
Martin Marinschek commented on ORCHESTRA-40:
--------------------------------------------
Hi Mario,
> I think we all agree, having a decent handling for this thing is a long missing feature here in JSF land.
yes, it really is.
> I also agree that it is much more a virulent problem when you use a conversation framework as it is much likely that you run into problems with the database else.
well, I believe it is also a problem with normal session scope, but no one should be using the session scope anyways
> The question is if we need it strongly integrated into Orchestra. I've looked at the patch, and beside that something gets stored into the
> conversationContext I can not see anything which can not be solved using normal JSF phase listeners.
> And for storing into the conversationContext we can create a scope which does this (instead of accessing it directly). You also gain the ability to
> decide on which level the tokens are kept.
> If you do not use Orchestra you simply can the manager bean into the session then.
Ok, sure, this might as well work without orchestra - but you definitely need a window/tab concept. And isn't that something orchestra also tries to solve?
> I'd say this component qualifies for its own project, e.g. within our ext (sorry, lost the name) project. On the other hand, I understand that -
> compared to seam and webflow - people await such functionality from Orchestra too.
> If we add this to Orchestra, I'd like to see it in a separated module, e.g. orchestra-jsfext. Would this be feasible?
Why jsfext? Does the solution have anything to do with JSF per se? The default implementation of the listener might have a JSF implication, but apart from that, no. Again, I think the whole thing is bound to windows and tabs, and therefore needs to reside in Orchestra or on top of Orchestra as a module of Orchestra - where exactly is not so much of an issue to me.
> As for the technical aspect of this patch, I have some notes:
> 1) Does this solution work with ajax, or will an ajax request trigger a DOUBLE_SUBMIT_OR_RELOAD_TYPE notification? I think ajax detection
>needs to be added, at least to detect JSF 2.0 alike ajax requests.
Hmm, I am not sure. Shouldn't we just make sure that the parameter gets updated like in the normal request case?
> 2) I see you store the token in the request parameter. Probably - in the context of ajax - storing it as attribute on the UIViewRoot might be better.
> If you have to deal with ajax requests you are able to update this value then with the new token.
ok, yes - then this would be somewhat automatic.
> I am also constantly thinking about moving the conversationContext paramter into the UIViewRoot - but this is another story.
sounds good to me.
> 3) We should also add a default TransactionTokenListener which behaves in a way we think an application should react on these events.People
> than can use it to jump start the system. Probably something like MyTransactionTokenListener with a faces message added so the user will get
> some feedback.
yes, and that might be JSF specific - jump to the rendering phase, and add a faces-message. Exactly.
> 4) I'd like to have a way to "ignore" some requests. E.g. if you issue an jsf action which will just stream a PDF to the user (without page change),
> the browser stay on the page, but the token has been "used" then.
> The current token needs to be added to the list of used tokens at the end of the request then. Probably an API like
> TransactionTokenManager.getInstance().ignoreRequest() suppress this addittion then for the current request. The token can then be used again.
> Also trinidad has at least two components which open a window and just report the value back to the main window.
> Probably we also need a way to ignore requests based on an URL pattern to deal with that?
Yes, there needs to be a way to cover this usecase. Isn't the target attribute the determining factor?
regards,
Martin
> A transaction token component inspired by the struts transaction processor
> --------------------------------------------------------------------------
>
> Key: ORCHESTRA-40
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-40
> Project: MyFaces Orchestra
> Issue Type: New Feature
> Components: Conversation
> Affects Versions: 1.3.1
> Reporter: Bernd Bohmann
> Assignee: Simon Kitching
> Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch
>
>
> A transactionToken Component for orchestra inspired by the struts transaction processor.
> The transaction token is to be used for enforcing a single request for a particular transaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ORCHESTRA-40) A transaction token component
inspired by the struts transaction processor
Posted by "Bernd Bohmann (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bernd Bohmann updated ORCHESTRA-40:
-----------------------------------
Status: Patch Available (was: Open)
> A transaction token component inspired by the struts transaction processor
> --------------------------------------------------------------------------
>
> Key: ORCHESTRA-40
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-40
> Project: MyFaces Orchestra
> Issue Type: New Feature
> Components: Conversation
> Affects Versions: 1.3.1
> Reporter: Bernd Bohmann
> Assignee: Simon Kitching
> Attachments: ORCHESTRA-40.patch
>
>
> A transactionToken Component for orchestra inspired by the struts transaction processor.
> The transaction token is to be used for enforcing a single request for a particular transaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component
inspired by the struts transaction processor
Posted by "Manfred Geiler (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12706086#action_12706086 ]
Manfred Geiler commented on ORCHESTRA-40:
-----------------------------------------
The LOG.error should be replaced by a LOG.debug in the TransactionTokenPhaseListener.
(looks like a debugging remainder)
> A transaction token component inspired by the struts transaction processor
> --------------------------------------------------------------------------
>
> Key: ORCHESTRA-40
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-40
> Project: MyFaces Orchestra
> Issue Type: New Feature
> Components: Conversation
> Affects Versions: 1.3.1
> Reporter: Bernd Bohmann
> Assignee: Simon Kitching
> Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch
>
>
> A transactionToken Component for orchestra inspired by the struts transaction processor.
> The transaction token is to be used for enforcing a single request for a particular transaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component
inspired by the struts transaction processor
Posted by "Bernd Bohmann (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704017#action_12704017 ]
Bernd Bohmann commented on ORCHESTRA-40:
----------------------------------------
A session based counter would not work if you allow to open more than one page.
> A transaction token component inspired by the struts transaction processor
> --------------------------------------------------------------------------
>
> Key: ORCHESTRA-40
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-40
> Project: MyFaces Orchestra
> Issue Type: New Feature
> Components: Conversation
> Affects Versions: 1.3.1
> Reporter: Bernd Bohmann
> Assignee: Simon Kitching
> Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch
>
>
> A transactionToken Component for orchestra inspired by the struts transaction processor.
> The transaction token is to be used for enforcing a single request for a particular transaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component
inspired by the struts transaction processor
Posted by "Simon Kitching (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699345#action_12699345 ]
Simon Kitching commented on ORCHESTRA-40:
-----------------------------------------
Could you describe some of the use-cases for this?
For transaction-oriented websites, back-buttons or "double clicking" of a page can be nasty; it can cause operations to be done multiple times (eg buying multiple copies of something) when the user didn't want that. The standard way to detect back-button usage or "double clicks" on a web page is to have a counter component in the page, and a matching counter in the http session. Both get incremented on each request; if at the start of a request they don't match then we have one of the above problems.
If I understand correctly, this patch adds a conversation-aware version of this, which stores the counter in "the current conversation" for the submitting page. But I'm not sure why this is useful. Why isn't a normal non-conversation-aware token implementation sufficient?
Note that the Orchestra ViewController already has features to detect when a page tries to use a conversation that does not exist (eg because it has been invalidated at end of a transaction), and can redirect to the appropriate "entry" page for the conversation.
> A transaction token component inspired by the struts transaction processor
> --------------------------------------------------------------------------
>
> Key: ORCHESTRA-40
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-40
> Project: MyFaces Orchestra
> Issue Type: New Feature
> Components: Conversation
> Affects Versions: 1.3.1
> Reporter: Bernd Bohmann
> Assignee: Simon Kitching
> Attachments: ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch
>
>
> A transactionToken Component for orchestra inspired by the struts transaction processor.
> The transaction token is to be used for enforcing a single request for a particular transaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.