UDF Type Checking setting ignored in 5.3.5

In our testing, it isn’t that it changed over time, it’s just that it suddenly started being enforced even with the setting off. For example, with a “virtual” mapping pointing to our application root, myApp.model.foo.bar and model.foo.bar can both point to the same file. (This is leftover from when we used to be a Windows & ACF shop, so it’s something we’re moving away from anyway, but still have enough there to notice this.)

In 5.3.3 and 5.3.4, it made no difference if a function required model.foo.bar or myApp.model.foo.bar – we could pass in or return banana.pancakes and so long as UDF type checking was disabled, it would work. In 5.3.5 and 5.3.6, the code Micha linked to was somehow being triggered often, though not all the time, such that we had to remove about 300 instances of this sort of thing from our codebase to even be able to start our app.

We filed this one under ‘things Lucee made us do that we should have done anyway’ because as you pointed out (Brad), it’s a better practice not to specify full path names. I guess we just didn’t know that before … but we do now!

For the class name to change from myApp.model.foo.bar to model.foo.bar would appear that the CFC got recompiled at some point while the app was running and used a different mapping path to resolve the file. I've gotten in the habit of never using full CFC paths in types due to issues like this.

I had an hour to work on this today and ended up just standardizing a lot of return types to remove the leading path, which was the problem, e.g. with the mapping /myApp then the CFC model.foo.bar would throw an exception if we had

Because it couldn’t cast myApp.model.foo.bar to model.foo.bar. It would work if we just made the function:

but , and I’m not totally sure about this part, this problem only seemed to come up if it was a Hibernate entity.

We also saw the following code fail on a Hibernate entity when it had worked before:

It throws: No matching Method/Function for org.hibernate.impl.SessionFactoryImpl.getClassMetadata(string) found

Even though a dump of ORMGetSessionFactory() shows a method with that signature.

This all seems related to me but that may be because they’re all being encountered at the same time. Still, I created

also with the stacktrace i was not able to reproduce, the exception comes from here

but 2 lines above it is checked if typechecking is needed, so the only explanation for the issue, that PC return true for typechecking.

i need a testcase to reproduce, i was not able to replay.

thanks, I accepted the PR

the stacktrace is actually very helpful, should be easy now to find out what is going on and fix it!