Skip to:

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

Generated accessors keep references to old CFC when mixed into another CFC's variable's scope

Description

Generated accessors keep references to old CFC when mixed into another CFC's variable's scope. This breaks a core feature of ColdBox/WireBox called virtual inheritance were we use mixins to populate a child CFC instance at runtime with properties and methods from a superclass. When we take a reference to a generated accessor from one CFC and place it in the this scope of another CFC, it works fine, but when we place it in the variables scope of the target CFC, the generated accessor method keeps pointing to the old CFC.

Test Case:

foo.cfc

component accessors=true { property name="message"; function init() { variables.message = 'I am foo.cfc!'; } function doSomething() { return getMessage(); } }

bar.cfc

component { variables.message = 'I am bar.cfc!'; function doSomething() { return getMessage(); } }

index.cfm

<cfscript> function injectMixin( name, UDF ) { variables[ arguments.name ] = arguments.UDF; this[ arguments.name ] = arguments.UDF; } objFoo = new foo(); objBar = new bar(); objBar.injectMixin = injectMixin; objBar.injectMixin( 'getMessage', objFoo.getMessage ); // Correct: I am foo.cfc! writeDump( 'Foo externally says: ' & objFoo.getMessage() ); // Correct: I am bar.cfc! writeDump( 'Bar externally says: ' & objBar.getMessage() ); // Correct: I am foo.cfc! writeDump( 'Foo internally says: ' & objFoo.doSomething() ); // INCORRECT: I am foo.cfc! writeDump( 'Bar internally says: ' & objBar.doSomething() ); // INCORRECT: C:\path\to\foo.cfc writeDump( getMetaData( objBar.getMessage ).owner ); </cfscript>

Environment

None

Activity

Show:

Brad Wood 4 September 2018 at 19:21

Thanks for the quick fix !

Brad Wood 27 August 2018 at 18:39

I can see an argument that the owner could be the original CFC where the UDF was defined, however Luce is inconsistent in how it treats owner, which was really the point there. If you dump out the owner on the previous example, you will see that the owner is the "new" CFC. So, no matter which behavior we say is correct, there's still an issue since it's not treated the same across the board. I also assumed that the initial bug was related to the fact that the owner was being treated differently which is why I included it in the repro case as a hint.

I would expect the "owner" from a PageSource perspective to probably be the original source code location, but the "owner" from a runtime variable context perspective would be where the UDF instance lives. I'm not actually sure which of those two "owner" is meant to represent. And as Pothy's said, Adobe CF doesn't have any such owner metadata so we can't compare there.

Thanks for looking into this!

Michael Offner 27 August 2018 at 07:50

Pothys - MitrahSoft 24 August 2018 at 13:36

ACF throws an error. It doesn't support the owner attribute,

Michael Offner 24 August 2018 at 12:51

not really sure if that is true:

// INCORRECT: C:\path\to\foo.cfc writeDump( getMetaData( objBar.getMessage ).owner );

who is the owner? the CFC where the source of the UDF is or the cfc the UDF is linked to.
testcase does not cover this, how does ACF handles this?

Fixed

Details

Assignee

Reporter

Priority

Fix versions

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

Sprint

Affects versions

Created 21 August 2018 at 22:37
Updated 4 September 2018 at 19:25
Resolved 4 September 2018 at 19:07

Flag notifications