Old Cf2016 to Lucee

dev support
1

OS: windows
Java Version: 8 currently
Tomcat Versionunknown IIS currently
Lucee Version: 5.3.7 from Cf2016

Starting an investigation into feasibility of migrating an old but robust Cf2016 suite of core applications to Lucee for a client. All rely on old frameworks that have not been upgraded for various reasons (ahem). Notably ColdSpring, Fusebox and FW1 amongst others. My question is: without rewriting/porting to newer versions of these frameworks what are the chances of getting them to run on Lucee?

Anyone with previous experience of porting these frameworks? Especially ColdSpring as that is the oldest (2005)?

I ask because my first, brief attempt running the codebase against Lucee resulted in a very odd looking dump deep within ColdSpring with an unreadable (by humans) stack trace!

I am a Lucee fan and stress this was only a first step taken after a cursory switch of the cfengine in command box. I’m fishing for opinions and any pointers at this point, trying to get a feel for an approach, as I would like to steer the client towards Lucee. Eg. would it be best to try an older stable Lucee version?

Many Thanks

2

I have 2 or 3 apps that work with ColdSpring and Lucee without problems.
For more recent applications I have used Wirebox. Porting between ColdSpring and Wirebox wasn’t difficult. It’s about writing a config file and changing some method.

3

Thanks for that input. Getting on with migrating the apps now with more success. I think issues I’m having are to do with conflicts and slight differences with Lucee component mappings rather than there being any problem with old code as such. But it is a WIP.

4

I’m not aware of any reasons why your stack won’t work, but that doesn’t mean you may not hit a few snags. I’ve converted ColdSpring apps to Lucee for customers and while I can’t recall off the top of my head if they had issues with the ColdSpring bits (the certainly had issues with the Transfer ORM bits!) it wasn’t unsurmountable.

One thing that may help is look for any cfcatches in coldspring and temporality put in a rethrow just so you know you’re seeing all the low level errors. Having an ACF version of the app up and running at the same time is helpful so you can dump/abort and compare what ACF is doing to what Lucee is doing.

There are also several companies which can help you with migration. Ortus is one of them (my company) though honestly we normally deal with projects that revolve around “box products” in some form.

5

Thanks for the useful tips and links etc. It’s heartening to hear this has all been worked through by others before. I’m sure I’ll get past the snags; it’s early days and I’ve a few ideas to try out now tomorrow. I will report back. Luckily there is no Orm involved in their stack!

6

It seems the issue I’m having is not specifically ColdSpring. It concerns a bog standard create Object call within Application.cfc (as an extension of taffy.core.api). I keep getting Stackmap frame errors as the component is simply not managing to init(). I am working through this particularly misbehaved component to find any offending code; but I am curious about these stackmap frame errors followed by a load of bytes? Not something I’ve seen in acfml. Anyone know what they ‘suggest’ is happening? If a component failed to initialise I would expect an offending line of code, rather I get this type of error. I am of course try…catching and dumping immediately and I have tried the more modern new CFC() syntax. It could well be a badly written component, but why the Stackmap frame error + byte codes?

7

I’d be interested how many lines of code are in the component we’ve seen weird errors when the size of the CFC is absolutely massive and over a threshold (I can’t remember what it is)

8

It’s not a large component at all. But, oddly it has a webservice call in the init method which makes it a bit unusual. I’m thinking if that should error and the init fails perhaps the object is non existent yet Lucee ‘expects’ it somewhere; hence failure to find it in memory? I was just curious as to what a Stackmap frame kind of error is indicative of. I am tending to think it’s ‘bad’ object, and could be better written. Other components are fine under Lucee.

9

I’ve dug a bit deeper and tracked this oddity down to one line of code like this:

local.errormesage = local.rsp?.errMsg // and local.rsp.errMsg is a valid key with a simple value

acfml doesn’t object to this and other odd things about it are:

  1. even though within a try…catch it is the application onError that catches it
  2. same code using a different scope is fine (so think it is restricted to local)
  3. Stackmap frame exception rather than null pointer or something more descriptive

Cleary there are workarounds, but would just like to undertsand what is going on with Lucee here, under the hood as it were - if anyone has any ideas?

10

Hey Bill. We had this @ EDD :wink:

The safe nav operator is flaky, and causes these errors in a few situations. solution: take out the safe nav operator. And hope Lucee fixes their bugs.

Your case is probably this one: [LDEV-3496] - Lucee or [LDEV-3020] - Lucee.

A good tactic when trying to investigate these things is looking in Jira.

11

Thanks for the heads up Adam. Good tip about having a look in Jira too. I’m looking into various options, and the odd workaround for Lucee wouldn’t be a huge issue (not like there is extensive use of safe nav operator in the code base)