Lucee 5.x to 6.x upgrade - SQL driver exception accessing session object?

I’m doing some exploration on upgrading our app from Lucee 5.x to 6. I’ve done the upgrade a few different ways, but I keep running into the same error any time the app tries to access the session scope.

The app runs in a docker container. I’ve tried upgrading from 5 to 6 via the admin. I’ve also pulled the latest docker image. The issue persists either way. I’ve tried different versions of the MSSQL driver too without luck.

I did notice that removing the cfid/cftoken cookie provides temporary relief, but as soon as it is set, it throws this error again.

I tried searching for similar issues, but nothing turned up, so I was hoping somebody here could point me in the right direction. I’m not sure if this is a Lucee problem or a Java problem, or a SQL driver, or what.

Don’t forget to tell us about your stack!

OS: Linux ( 64bit
Java Version: 11.0.23 (Eclipse Adoptium) 64bit
Tomcat Version: Apache Tomcat/9.0.89
Lucee Version: Lucee

switch from application sessions to JE2 sessions. Restart your sever.

Unfortunately this is a legacy app that is set up to utilize cfid in various places. If that’s the only option than we could investigate it, but it isn’t ideal.

You could try setting the logging level for “scope” to “debug” to get more information about what Lucee is doing behind the scenes, but I suspect that the problem might be a compatibility issue between your Lucee version and your SQL driver. That could explain the ClassNotFoundException. What version of the SQL Server extension are you using?

We are currently using 12.2.0.jre11 with Lucee 5.x. I tried with that version, as well as the latest version (12.4.2.jre11).

I’ll try adjusting the logging level and see if I can find anything from that.

Update: Unfortunately the log didn’t show anything. It only shows some [info] stuff about loading existing data from cache to create the session scope.

It’s a really weird error. I can’t imagine why a SQL driver exception would be happening when looking at the session, or why switching to J2E sessions allows it to work fine. (We’re trying to avoid that route since it would increase the code changes/testing required, but it does appear to be a valid workaround.)