You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@struts.apache.org by "Paul Benedict (JIRA)" <ji...@apache.org> on 2008/06/06 14:33:06 UTC

[jira] Issue Comment Edited: (STR-3151) messagesPresent should not alter ActionMessages.accessed flag

    [ https://issues.apache.org/struts/browse/STR-3151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44055#action_44055 ] 

paul4christ79 edited comment on STR-3151 at 6/6/08 5:32 AM:
------------------------------------------------------------

TJ, thank you for the issue report. Based on the conversation, it does appear you pointed out a logical flaw but, to Niall's point, will not occur in practice. If you find a better use case, let us know! It's easy to reopen this ticket and fix it.

      was (Author: paul4christ79):
    TJ, thank you for the issue report. Based on the conversation, it does appear you pointed out a logical flaw but, to Niall's point, will not occur in practice. If you find a better use, let us know! It's easy to reopen this ticket and fix it.
  
> messagesPresent should not alter ActionMessages.accessed flag
> -------------------------------------------------------------
>
>                 Key: STR-3151
>                 URL: https://issues.apache.org/struts/browse/STR-3151
>             Project: Struts 1
>          Issue Type: Bug
>          Components: Taglibs
>    Affects Versions: 1.3.8
>         Environment: n/a
>            Reporter: T.J. Hill
>            Assignee: Paul Benedict
>
> 20080603 12:53
> The html|nested:messagesPresent tags set ActionMessages.accessed flag to true when interrogating.
> Currently, MessagesPresentTag calls the methods get() and get(String) of ActionMessages to determine if any messages exist.  However, both get(...) methods in ActionMessages set the accessed field to true.  So any subsequent call to ActionMessages.isAccessed() by external code will get true, regardless if the messages were truly consumed.
> Below is the current condition method in MessagesPresentTag:
>     protected boolean condition(boolean desired)
>         throws JspException {
>         ActionMessages am = null;
>         String key = name;
>         if ((message != null) && "true".equalsIgnoreCase(message)) {
>             key = Globals.MESSAGE_KEY;
>         }
>         try {
>             am = TagUtils.getInstance().getActionMessages(pageContext, key);
>         } catch (JspException e) {
>             TagUtils.getInstance().saveException(pageContext, e);
>             throw e;
>         }
>         Iterator iterator = (property == null) ? am.get() : am.get(property); // HERE is the issue -- using get(...) methods will cause the accessed property of ActionMessages to be set to true.
>         return (iterator.hasNext() == desired);
>     }
> Perhaps the following change would be appropriate to resolve the issue.
> Modify the condition(boolean) method in MesssagesPresentTag to call the existing ActionMessages.size() [when property not specified] and the exsiting ActionMessages.size(String) method above [when property specified]:
>  
>      protected boolean condition(boolean desired)
>          throws JspException {
>          ActionMessages am = null;
>  
>          String key = name;
>  
>          if ((message != null) && "true".equalsIgnoreCase(message)) {
>              key = Globals.MESSAGE_KEY;
>          }
>  
>          try {
>              am = TagUtils.getInstance().getActionMessages(pageContext, key);
>          } catch (JspException e) {
>              TagUtils.getInstance().saveException(pageContext, e);
>              throw e;
>          }
>  
>  			// --- CURRENT ---
>          //Iterator iterator = (property == null) ? am.get() : am.get(property);
>          //return (iterator.hasNext() == desired);
>          
>          // +++ SUGGESTED +++
>          int present = (property == null) ? am.size() : am.size(property);
>          return ((present > 0) == desired);
>     }	
>     
>  Thanks - TH

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.