```var data = mockData( name: "name", age: "age", ...
# adobel
lmajano
05/14/2025, 9:43 AM Copy code
var data = mockData( name: "name", age: "age", id: "uuid" );b
BK BK
05/15/2025, 5:23 AMThe issue might have been caused by the introduction of the new flag, -Dcoldfusion.runtime.remotemethod.matchArguments.
If so, I would suggest using the JVM flag
-Dcoldfusion.runtime.remotemethod.matchArguments=falsel
lmajano
05/15/2025, 8:04 AMI am not sure this was a wise decision
lmajano
05/15/2025, 8:05 AMIt basically makes CF not act like CF when it comes to arguments.
lmajano
05/15/2025, 8:05 AMI can’t ask everyone to add this flag if they are doing mocks
lmajano
05/15/2025, 8:06 AMEven the mocking service so you can simulate APIs works like this, by relying on dynamic arguments
lmajano
05/15/2025, 8:06 AMSeems very heavy handed to do
b
BK BK
05/15/2025, 8:47 AMIs the introduction of the matchArguments flag the cause of the problem?
l
lmajano
05/15/2025, 8:48 AMyes
b
BK BK
05/15/2025, 8:48 AMAh, understood. Thanks for clarifying.
l
lmajano
05/15/2025, 9:30 AM@nimitsharma let me know if you need anything
e
Edwin Samuel Jonathan
05/21/2025, 4:54 PM@lmajano We are evaluating a few options. Currently thinking of a separate JVM flag with an allowed list of arguments that would be looked past for all remote methods. I understand the current approach seems a bit heavy handed, but unfortunately due to the security implications we do want to be selective. To protect against the scope injection issue, we unfortunately did not have any other choice. We could have changed the scope ordering, but this would have silently changed the way applications function without any error feedback
2 Views