UDF Type Checking setting ignored in 5.3.5


This is a placeholder ticket until we can get more information, but in testing an app that works in 5.3.3 and 5.3.4 on the 5.3.5 snapshots (currently, we are seeing a lot of new errors related to UDF type checking. In most cases, they're legitimate, where we are declaring a return type and then not returning that type; but with the 'UDF Type Checking' option disabled in Lucee admin, this should be allowed, yes?

In other cases, we have mappings such that a component could be foo.bar.component (the actual directory path) or ourApp.foo.bar.component (the path with the mapping) and we've been using return types based on how Lucee mapped those components previously, which was the mapped path – now we're seeing errors where it could not cast foo.bar.component to ourApp.foo.bar.component.

We can (and obviously should) fix the first case where our code is just lying about return types, but it seems that either Lucee should respect the UDF Type Checking option or remove it if there was a conscious decision made to enforce type checking.




Michael Offner
February 14, 2020, 11:17 PM

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!

Michael Offner
February 20, 2020, 1:18 PM

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.

Samuel W. Knowlton
February 22, 2020, 1:03 AM

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

Brad Wood
March 12, 2020, 3:39 AM

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.

Samuel W. Knowlton
March 12, 2020, 1:11 PM

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!




Samuel W. Knowlton





Fix versions


Affects versions