DO NOT REPLY [Bug 19421] New: - #macro name is displayed in the browser.

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19421>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19421

#macro name is displayed in the browser.

           Summary: #macro name is displayed in the browser.
           Product: Velocity
           Version: 1.3.1
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Build
        AssignedTo: velocity-dev@jakarta.apache.org
        ReportedBy: plamen@hpd.co.uk
                CC: plamen@hpd.co.uk


Hi,
I was wandering if someone has reported this problem.
This error occurs when stress-testing applications developed with Velocity.
When I test with around 25 browser instances (or more) often I get:
#menuitem#menuitem  (menuitem is the name of the macro) being displayed in the 
rendered page instead of the macro being executed.

The macro is:
=============================================================
#macro (menuItem $action $url $description)

      #if($action==-1)
        #set($actionOK=true)
      #else
        #if($debtorAccount)
          #set($actionOK=$accessControl.canPerformAction($action, $user, 
$clientAccount, $debtorAccount))
        #else
          #if($clientAccount)
            #set($actionOK=$accessControl.canPerformAction($action, $user, 
$clientAccount))
          #else
            #set($actionOK=$accessControl.canPerformAction($action, $user ))
          #end
        #end
      #end
=============================================================
I call this macro to build a menu page. The macro would call a method on an 
object (stored on a �session� level using AbstractContext). The macro is called 
like this:
#menuItem(-1 "./signOff" $lClientMenu_LogOffLit)

Could you please suggest any fixes or workaround?

Thank you in advance,
Plamen Koychev
Software Developer

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org