Unexplained behavior in Velocity Macro Rendering

[Vincent Thoulé _Alkaes_]

I am working on the Migration of my plugin for Jira 10.x and encounter a strange behavior that seems to be caused by changes in the Atlassian velocity.jar version.

Currently in Dev. environment, I am working on Jiira 10.0.0 with velocity-1.6.4-atlassian-36.jar.

The Issue can be summarized as follow ...

• Plugin have a set of Actions
• Each Action View is rendered by a Velocity template
• Each of this Velocity template contains a set of Velocity Macros, some of them have the same name in each template

Before Jira 10.x, when an action was rendered the Velocity template was using always the correct Velocity Macros.

Since Jira 10.0.0, when an action was rendered the Velocity template uses the last new cached Velocity Macros.

Imagine 3 sample actions with their Velocity templates :

<action name="com.company.myfeatures.ActionA" alias="ActionA">
	<view name="input">com/company/myplugin/myfeatureA/view/manageA.vm/view>
	<view name="success">com/company/myplugin/myfeatureA/view/manageA.vm/view>
	<view name="error">com/company/myplugin/myfeatureA/view/error.vm/view>
</action>
<action name="com.company.myfeature.ActionB" alias="ActionB">
	<view name="input">com/company/myplugin/myfeatureB/view/manageB.vm/view>
	<view name="success">com/company/myplugin/myfeatureB/view/manageB.vm/view>
	<view name="error">com/company/myplugin/myfeatureB/view/error.vm/view>
</action> 	
<action name="com.company.myfeature.ActionC" alias="ActionC">
	<view name="input">com/company/myplugin/myfeatureC/view/manageC.vm/view>
	<view name="success">com/company/myplugin/myfeatureC/view/manageC.vm/view>
	<view name="error">com/company/myplugin/myfeatureC/view/error.vm/view>
</action>

In related Velocity Templates (manageA.vm, manageB.vm, manageC.vm), we have some macros defined with same name :

• #macro showHeader()
• #macro showDetails()
• #macro showFooter()

When plugin is just deployed, if we access each Actions one time the Velocity rendering is correct.

But as soon as we access an action already accessed, the Velocity rendering uses the latest Macros cached.

In details, after enabling the plugin :

• Accessing ActionA, rendering uses manageA.vm and calls
  • manageA.vm.showHeader(),
  • manageA.vm.showDetails(),
  • manageA.vm.showFooter()
• Accessing ActionB, rendering uses manageB.vm and calls
  • manageB.vm.showHeader(),
  • manageB.vm.showDetails(),
  • manageB.vm.showFooter()
• Accessing ActionC, rendering uses manageC.vm and calls
  • manageC.vm.showHeader(),
  • manageC.vm.showDetails(),
  • manageC.vm.showFooter()
• and now when accessing ActionA and ActionB, all Macro calls are done with
  • manageC.vm.showHeader(),
  • manageC.vm.showDetails(),
  • manageC.vm.showFooter()

We disable/reenable the plugin an process the call in this other order

• Accessing ActionC, rendering uses manageC.vm and calls
  • manageC.vm.showHeader(),
  • manageC.vm.showDetails(),
  • manageC.vm.showFooter()
• Accessing ActionA, rendering uses manageA.vm and calls
  • manageA.vm.showHeader(),
  • manageA.vm.showDetails(),
  • manageA.vm.showFooter()
• Accessing ActionB, rendering uses manageB.vm and calls
  • manageB.vm.showHeader(),
  • manageB.vm.showDetails(),
  • manageB.vm.showFooter()
• and now when accessing ActionC and ActionA, all Macro calls are done with
  • manageB.vm.showHeader(),
  • manageB.vm.showDetails(),
  • manageB.vm.showFooter()

I did few quick tests by renaming this macro, and it resolved the issue.

Velocity Macros seems to be cached by using a plugin reference and an not based on Template.

I did not find reference of this behavior or changes in all you documentation.

Is it a non documented change or a bug .

V.

[Matt Doar _Adaptavist_]

Vincent, did you ever make progress on understanding why this was happening? I somehow vaguely recall there being an option disable the caching of velocity macros somewhere in Jira

Aha, this is it:

https://developer.atlassian.com/server/confluence/disable-velocity-caching/

[Vincent Thoulé _Alkaes_]

Thanks Matt,

I was aware about this, but it can be applicable for a commercial plugin.

I have finally opt for a rename of most of my Velocity Macro where it was possible.

And for the others, I have implemented a solution based on dynamic calls to Macro with #evaluate(). It was little touchy to make it operational, but it does the job.

Vincent