We’re working on a new project that will launch on CF 2018. I’ve run into some hurdles trying to get FarCry running and thought I would note them here in case others run into them.
The UUID generation library that FarCry uses relies on the Java CORBA module that, since Java 9, is no longer enabled by default. To fix this, edit your jvm.config file and find the argument --add-modules and change it from: --add-modules=java.xml.ws to --add-modules=java.xml.ws,java.corba
This allows FarCry to start. I will try to update this post if I run into any other issues running FarCry on CF 2018
Just thought I’d follow this up to say that the original PR above was merged in August last year, and the p740 branch currently has the old UUID and anything related to JavaLoader removed to move forward with Java 11 compatibility, plus we have a new mechanism for automatically adding the /jars folder inside a plugin or project to the javaSettings.loadpaths array.
If there are any other CF2018 issues outstanding that anyone has then please let us know. We can back port any fixes that make sense to p720 but otherwise the main branch of new development is currently p740.
Justin, did any of these CF2018 support changes get merged into other branches? (p720, p730)
I ask because in attempting to use branch p740, I’m running into issues of support with CF2018 because of syntax being used that isn’t supported. (I’ll submit additional bugs for these) As an example MySQLGateway.cfc has syntax like this which I’m guessing is only supported by Lucee
Was the MySQL gateway the only issue? I haven’t checked to see if it was patched, but if it isn’t then I can do it or accept a PR, I just need to know if there are any other issues that need to be followed up as well.
Yep, appears so. As soon as I took the #s from it FC740 started working. Though interested to know why MySQL gateway is being loaded when I’m using MSSQL.
The syntax error would be a compile time error; each DB gateway would get compiled when the framework starts up (all gateways found in the appropriate folder paths) so that it knows which ones are available, and then your chosen gateway is used based on the configuration in the farcryConstructor at run time.
In order to get rid of the javaLoader functionality on CF 2018, I downloaded the p740 core and replaced the 7.2.9 core with the result that FarCry does no longer start (macos, Apache 2.4.2, CF2018, MySQL 5.x, FarCry 7.2.9). Some digging into the possible causes revealed a change in the MySQLGateway.cfc in function getColumns: In the p740 branch there is a column generation_expression which does not exist in earlier versions.
The initial error message reads: Unknown column ‘generation_expression’ in ‘field list’. The error is thrown when attempting to read the table farPermission.
Any pointers of how to work around this issue (creating the column manually, …) are appreciated.
When checking the MySQL’s database schema, I discovered that the generation_expression column is missing. A side-by-side comparison with the 7.2.12 core revealed that the addition in the MySQLGateway.cfc is more recent. This means that the p740 branch as it is labeled will not work with any databases running on MySQL server 5.x. The FarCry application will break at start-up.
I haven’t tried it myself but you may be able to override the MySQLGateway CFC in your own project (most CFCs in farcry’s packages can be) and you could write your own getColumns function that doesn’t use features that 5.x doesn’t support. Just a thought. Hope you’re able to get it working.
Sean,
That’s what I did: I took the 7.2.12 version which works fine for me. However, I thought I’d share my findings in case somebody takes the p740 core and expects it to play nicely with MySQL 5.x.
I think generation_expression is a MySQL 5.7.x feature that has crept in and if you’re still on MySQL 5.6.x or older then it will be unsupported in your engine. We should make this optional so that it only tries to use the feature in the engine if it’s available.
I wonder if it is possible to wrap the query for the new MySQL and the subsequent code into a <cftry> section and the older code into the <cfcatch>? Thus, there would not be any need for fussing around, and in a few years the MySQL pre-5.7.x code can be eliminated.
It’s merged now.