Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Using "caller.thread" in custom tag corrupts the Thread scope.

Description

This is a strange one, so I am not exactly sure how to word it. It appears that using caller.thread to assign a value to the thread scope from within a custom tag corrupts the `thread` scope, moving it out of the thread context and into the variables scope. Reproducing it is quite easy.

Imagine this custom tag - MyTag.cfm:

<cfset caller.thread.setFromCustomTag = "hey there" />

All it is trying to do is assign a value to the thread scope from within the custom tag context.

Now, let’s consume this custom tag from within a thread:

<cfscript> thread name = "testingCustomTag" { thread.beforeCustomTag = "this worked"; _myTag {} thread.afterCustomTag = "this worked"; } thread action = "join"; dump( label = "Threads", var = threadData() ); dump( label = "Variables", var = variables ); </cfscript>

Notice that in our thread body we’re making two thread scope assignments, one before, one after the custom tag invocation. Now, if we run this, we get the following:

Super weird, right?!

And, If I remove the custom tag call, both thread scope assignments go back to the correct place.

Environment

None

Attachments

2
  • 28 Sept 2021, 06:07 pm
  • 25 Sept 2021, 10:01 am

Activity

Show:

Ben Nadel 29 September 2021 at 13:20

Awesome, thanks!

Pothys - MitrahSoft 29 September 2021 at 12:18
Edited

I confirmed the issue happened on lucee latest version 5.3.9.13-SNAPSHOT too. Calling customtag from inside thread and using caller.thread in custom tag page to assign value in thread scope was set the value in variables scope instead. After that declaring variable in thread scope within thread also moved to variables scope. Seems ACF works fine.

I added a testcase to this ticket
Pull Request: https://github.com/lucee/Lucee/pull/1440

Ben Nadel 28 September 2021 at 18:07

Yes, setting thread.setFromCustomTag does work in that it assigns to the right scope and allows subsequent sets to the scope to work as expected. But, if the custom-tag were more abstracted, it might not be able to do that.

For example, imagine trying to re-create CFSaveContent as a custom tag. I might have MySaveContent.cfc:

<cfscript> param name="attributes.variable" type="string"; if ( thistag.executionMode == "end" ) { setVariable( "caller.#attributes.variable#", thistag.generatedContent ); // Reset output from tag. thistag.generatedContent = ""; } </cfscript>

This tag wouldn’t know anything about the thread scope. But, I might use the thread scope in the variable attribute:

<cfscript> thread name = "testingCustomTag" { savecontent variable = "thread.cfSaveContent" { echo( "Saved using CFSaveContent" ); } _mySaveContent variable = "thread.mySaveContent" { echo( "Saved using MySaveContent" ); } } thread action = "join"; dump( label = "Threads", var = threadData() ); dump( label = "Variables", var = variables ); </cfscript>

If I output the page, we get this:

So, whatever CFSaveContent is doing internally with its variable attribute works as expected. But, my attempt to re-create that usage is not working.

Pothys - MitrahSoft 27 September 2021 at 14:55

for me, using thread.setFromCustomTag in customTag page works fine in lucee. Could you please check with that and report here back?

Ben Nadel 25 September 2021 at 10:02

I stumbled upon this because I was trying to make a version of the timer tag that would save the duration to a variable. Like:

_myTimer variable = "thread.duration" { ..... }

And then in my custom tag, I had:

setVariable( "caller.#attributes.variable#", ( getTickCount() - startedAt ) );

Details

Assignee

Reporter

Priority

Labels

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Affects versions

Created 25 September 2021 at 09:57
Updated 29 September 2021 at 13:20

Flag notifications